CI Integration
The Data Landing Zone (DLZ) construct offers built-in support to streamline authentication between AWS and CI/CD systems, enhancing security and simplifying setup processes.
GitHub Actions
DLZ facilitates seamless integration with GitHub Actions using OpenID Connect (OIDC). OIDC is recommended over long-lived IAM credentials due to its enhanced security and flexibility. For detailed information, refer to the official documentation from Github or AWS
We first need to configure the AWS side and then pass the generated IAM Role ARN to the GitHub Actions workflow.
1. Config AWS
The following section demonstrates how to configure OIDC integration for a sample repository. This example uses the DataChefHQ/data-landing-zone-example-typescript repository. Ensure you replace the placeholders with values specific to your setup.
The example above does not specify the filter
property, which means all environments, tags, branches and PRs can
assume the generated IAM Role to authenticate with AWS. For a complete list of filters see the
Github documentation
Some common Examples:
environment:ENVIRONMENT-NAME
- Specific environmentref:refs/heads/BRANCH-NAME
- Specific branchref:refs/tags/TAG-NAME
- Specific tagpull_request
- Only PRs
A *
can be used for most parts of the ENVIRONMENT-NAME
, BRANCH-NAME
, TAG-NAME
Manual setup deployment
The OIDC role created by the configuration above has to happen before it can be used by GitHub Actions. This creates
a “chicken and egg” problem and requires manual deployment of the management
stack. This only has to be done
manually once as setup for the OIDC integration.
After deployment, the OIDC role ARN can be found in the dlz-global
stack outputs with the name
dlz-global-git-hub-deploy-role
. It will be in this format:
2. Use within GitHub workflows
The GitHub workflow for the given repository can now be updated to use the OIDC role ARN.
It is important to set the permissions
so that aws-actions/configure-aws-credentials@v4
works correctly.
This workflow can be used to do a CDK diff when a PR is opened or synchronized. It can also be triggered manually.
This workflow can be used to do a CDK deploy when a PR is merged. It can also be triggered manually.
It is possible to split the deployment of the development
and production
workload accounts and place an approval step
in the middle. This requires knowledge of the correct CDK commands to use. The example below demonstrates this.
Click to show the Advance Deploy Workflow
Ensure that the the production
GitHub environment exists and is configured to require manual approval. See the
GitHub documentation
for more information.
This workflow first builds the CDK cloud assembly and caches the assets. It then deploys the Management and Security
Phases. Then it deploys the all the type: DlzAccountType.DEVELOP
workload stacks. The last job deploys the
type: DlzAccountType.PRODUCTION
workload stacks. But this job will not start as it has the environment: production
property set and will only start after manual Approval has been given on GitHub.
Create following composable action file in the .github/workflows
directory as it is used in the above workflow to
prevent code duplication.