AWS CI Account Setup

This repository contains a setup for provisioning an AWS sub-account for Continuous Integration (CI) testing.

Features

As shown in the picture the repository consists of two parts: cleanup-stack and ci-user-stack. The cleanup-stack is only required once per account. The ci-user-stack for each project that you want to test.

The cleanup stack deletes all resources in the AWS account except:

• Some resources prefixed with protected-: These are the resources of the ci-isolation itself. For example the code-build jobs that deletes everything. The ci-users are not allowed to create such resources.
• S3 buckets and prefixed with persistent-. You can create such buckets to store data that is not deleted. For example for long-term-caching.

Usage

First deploy the ci-user-stack from this repository:

cdk --profile <AWS-PROFILE> deploy --parameters exaOwner=<YOUR E-MAIL>

Adding a CI-User for a new Project

Now you can add a ci user for the project you want to test:

• In the project repository create a new CDK stack:

  cdk init app --language=java

• Now remove the autogenerated stack (for example rm src/main/java/com/myorg/TestStack.java. The exact stack name depends on the folder name).

• Add this project as a maven dependency.

• Add a policy document to the resources of the CDK project (see next section)

• In the App add:

  final CiUserStack stack = new CiUserStack(app, CiUserStack.CiUserStackProps.builder().projectName("<YOUR PROJECT_NAME>")
                  .addRequiredPermissions(new PolicyReader().readPolicyFromResources("<YOUR POLICY DOCUMENT>")).build());

• Deploy the stack

Update Minimal Permissions

In order to keep the impact of a hacking attack low, we want to only grant the required permissions to the CI user. In this section we describe an approach for detecting the required permissions of your CI build.

Determining the minimal set of permissions by hand is quite a lot of work. To make our lives easier we use the tool iamlive. This tool spies on the local AWS CLI and Terraform, and reports the used permissions. These permissions are not complete in case Terraform uses CloudFormation under the hood, but it's a lot better than having nothing.

To extract the minimal permissions do the following steps:

• Set your AWS credential environment variables for a user with broader permissions (usually using . aws_get_session_token).

• Run iamlive:

  ./iamlive --set-ini --mode proxy --force-wildcard-resource

• In another terminal run:

  export HTTP_PROXY=http://127.0.0.1:10080
  export HTTPS_PROXY=http://127.0.0.1:10080

• Run everything your CI runs in the 2nd terminal. Typically:

  • Create infrastructure (e.g. using Terraform)
  • Run tests
  • Destroy infrastructure

• Copy the last output from the iamlive command to a file. Now you can use this file as permissions in the setup.

Exasol Cloud Formation Template

The Exasol database is usually created using a CloudFormation template. The steps from this template are not recorded by iamlive since the CloudFormation template is evaluated in the cloud and by that, the request don't pass the proxy.

So we have to find out the required permissions by hand. Luckily Exasol offers a policy for running an Exasol cluster. We simply downloaded this one and added it as resource. In the future it might be required to update this resource.

Additional Tasks for Setting up a CI Account

• Visit https://aws.amazon.com/marketplace/pp?sku=ctqmztsepbuk7e9f2ks9nlwj1 and accept license (subscribe)
• Configure account alias
  • Open AWS Console
  • Go to IAM / Dashboard
  • On the top of the page edit the alias

Testing

This repository contains the integration tests (PermissionBoundaryIT) that tests that the CI user only has the expected privileges.

In order to use this test you need an AWS user with admin privileges. For that reason we do not run this in the CI. To run it locally create a file named test_config.yaml in this directory:

owner: <your e-mail; used as exa:owner tag>
profile: <the aws-profile for the admin user>

Before running the tests, deploy the stack using the CDK.

Additional Information

• Dependencies
• Changelog