Skip to main content

Conveyor security on AWS

Minimal role CloudFormation stack​

During the setup of Conveyor you might have noticed that an AWS CloudFormation stack is installed to give the Conveyor product access to your AWS account in order to install the data-plane setup in your AWS account. The template for the CloudFormation stack is available on S3.

This CloudFormation stack consists of two parts:

  • An AWS role (called minimal installation role) that allows the Conveyor product to install the data-plane in your AWS account
  • A set of AWS policies that are needed for the multiple pieces of Conveyor to function

Minimal installation role​

The minimal installation role is what allows the Conveyor product to install the data-plane in your AWS account. When creating this role we took AWS best practices into account. The AWS role has the following properties:

  • Minimal access rights, we only give it the access rights needed to install and maintain the product.
  • We added an external ID in the assume role policy, this is to make sure we are not vulnerable to the confused deputy problem.
  • We added a mandatory role session name in the assume role policy, this allows you to easily audit what was done with this role.
  • We explicitly did not give the role access to create IAM policies in any form. The role is only allowed to create IAM roles, and attach the predefined policies. This is to make sure the role can not gain more access rights.

AWS Policies​

These AWS policies are predefined policies containing the minimal rights required by the Conveyor components to do their work.

There is one policy to look out for and to decide if you want to use it or not, called the EksAgentIAMPermissivePolicy. This policy is used by a legacy feature called resources and allows users to include the creation of IAM roles when deploying a project on Conveyor. If you do not want to use this feature, the policy can be replaced by the EksAgentIAMRestrictedPolicy which does not allow the creation of IAM roles nor IAM policies. Contact the Conveyor team for help if you want to disable the resources feature.

Auditing Conveyor access​

AWS Account auditing​

AWS offers a service called AWS CloudTrail for operational auditing. This is a managed service that allows you to record all interactions with the AWS API. You can use this log to audit what happens inside your AWS account.

The minimal installation role (mentioned above) will always use the StsSessionName that was provided in the CloudFormation stack to install it. It typically has the following format: conveyor-TENANTID, where TENANTID is unique to your installation. You can use this Session Name to easily figure out what actions the role has performed in your account.

AWS EKS auditing​

AWS EKS also has an auditing log that can be enabled, when this is enabled every interaction with the EKS API will be logged into cloudwatch and can be used to audit access to the EKS api. The username in EKS that is attached to the minimal installation role is called installer, and can thus be queried in the cloudwatch logs of the EKS audit log.

Control plane security​

The control-plane of Conveyor does not run in your AWS account but is running on an AWS account of Conveyor. This is the AWS account from which the minimal role is assumed. We have implemented security best practices on this account.

We use AWS Security Hub, and have implemented and actively monitor the results of the Center for internet Security (CIS) AWS Foundations Benchmark and the AWS Foundational Security Best Practices (FSBP) standard. We currently have 97% compliance in total for these benchmarks.

For access to our Conveyor control-plane AWS account we use the latest best practices regarding SSO, and only the minimal amount of people that need access have access.

Updating and patching Conveyor components​

We use many open-source components and make sure that we keep up to date with recent versions. We update our libraries and open-source components to fix issues as well as potential vulnerabilities. In order to automate this process as much as possible, we use dependabot. Dependabot detects updates as well as checks for vulnerabilities in our third-party libraries. This allows us to automatically include these fixes with every new release, which is typically done weekly.

In case a critical CVE is discovered, we create a new release from the moment we have a fix or a way to remediate the vulnerability.

AWS GuardDuty agent​

It is possible to install the AWS GuardDuty agent on the Conveyor EKS cluster.

By default, GuardDuty is not installed, and we explicitly opt out of automatic GuardDuty installation via the tag GuardDutyManaged=false. The reason is we need to take the CPU/Memory overhead of GuardDuty agent into account when calculating the CPU/Memory over your scheduled pods. If you want it installed just let us know via our standard support channels.