ESH Security
Like the large organizations ESH is best suited to serving, ESH takes security seriously. Whether you are using our SaaS offering or our Self Install product, we take great care to ensure there is no leakage between organizations, Tenants or Targets.
Data Security
Data in ESH is secured in a number of ways. All data is encrypted at rest and in transit.
SaaS
All organizations have their own database, we do not use Row Level Security (RLS) as we strongly believe in total data segregation. RLS can be turned off, separate databases mitigates this risk.
All organizations have their own Cognito User Pool thus ensuring SSO has its own separate database of users and groups.
Self Install
Organizations that choose our Self Install option into their AWS account benefit from total isolation of their environment. ESH runs it it's own private VPC and only requires outbound internet connectivity for license reporting and optional proactive support offering which encompasses sending live error events to our central event store where we analyse errors and proactively investigate.
Target Security
ESH Targets are the connection between ESH and your target environments. As such they require credentials. Any credentials ESH stores are encrpted in AWS Secrets Manager but we generally recommend not using secrets based authentication, OIDC and roles based access is recommended.
AWS
There are two types of Target authentication available for AWS, roles based and credentials based. We recommend roles based as it is more secure because no credentials are stored in the ESH environment.
Roles Based Authentication
Each Organization has it's own principle execution role that the Deployment engine runs as in order to assume roles in the Target account. There are 2 types of roles based autentication.
- Default Role
ESH offers a Service Catalog product that will create a default administrative role in each of your organizations accounts. This role can only be assumed by the engines principle execution role that you specify when you run the Service Catalog product. This is a great way to get started, the product can even target a subset of your accounts to faciliate ESH setup and testing before wider rollout.
- Custom Role
If you would prefer to create your own role as you already have mechanisms to roll these out, this is entirely possinle. The custom role is specified for each Target and the ESH engine assumes this role to undertake actions in the Target account. Just as for Default role, you limit access to this role to your organizations deployment engines principle role.
It is also possible however to define roles per Template in order to lock down a deployment runs permissions to the very permissions the Template requires to operate. This is an advanced use and comes with administrative overhead.
Azure and GCP
These Targets use OIDC for authentication, the client secret is stored in AWS Secrets Manager.
Template Security
Templates are secured in a variety of ways.
TFSec Reports
When a Template is downloaded, it is scanned by TFSec. TFSec reports are presented to Template developers so they can refine their offerings prior to certification for use. An visual cue is provided to developers so they can see the security posture of their Templates at a glance.
Learn More About TFSec Reporting
Open Policy Agent Policy Checks and Reports
ESH also supports Open Policy Agent scanning of every Deployent plan. Policies for each Target type are managed in the Security console, and there are a variety of settings that control their usage.