https://github.com/exasol/ci-isolation-aws
AWS account setup for isolating CI builds
https://github.com/exasol/ci-isolation-aws
aws exasol-integration integration-testing
Last synced: about 1 year ago
JSON representation
AWS account setup for isolating CI builds
- Host: GitHub
- URL: https://github.com/exasol/ci-isolation-aws
- Owner: exasol
- License: mit
- Created: 2021-06-17T06:27:47.000Z (about 5 years ago)
- Default Branch: main
- Last Pushed: 2025-03-06T11:53:36.000Z (over 1 year ago)
- Last Synced: 2025-03-24T11:38:24.029Z (about 1 year ago)
- Topics: aws, exasol-integration, integration-testing
- Language: Java
- Homepage:
- Size: 126 KB
- Stars: 2
- Watchers: 7
- Forks: 2
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Security: SECURITY.md
Awesome Lists containing this project
README
# AWS CI Account Setup
[](https://github.com/exasol/ci-isolation-aws/actions/workflows/ci-build.yml)
[](https://search.maven.org/artifact/com.exasol/ci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
[](https://sonarcloud.io/dashboard?id=com.exasol%3Aci-isolation-aws)
This repository contains a setup for provisioning an AWS sub-account for Continuous Integration (CI) testing.
[Features](doc/features.md)
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:
```shell
cdk --profile deploy --parameters exaOwner=
```
### 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:
```shell
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:
```java
final CiUserStack stack = new CiUserStack(app, CiUserStack.CiUserStackProps.builder().projectName("")
.addRequiredPermissions(new PolicyReader().readPolicyFromResources("")).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](https://github.com/iann0036/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`:
```shell
./iamlive --set-ini --mode proxy --force-wildcard-resource
```
* In another terminal run:
```shell
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](https://s3.eu-central-1.amazonaws.com/cloudtools.exasol.com/iam_policy.json). 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:
```yaml
owner:
profile:
```
Before running the tests, deploy the stack using the CDK.
## Additional Information
* [Dependencies](dependencies.md)
* [Changelog](doc/changes/changelog.md)