SaaS at your own risk
in recent years, DevOps practices have increasingly become popular among organizations looking to move fast, and improve their SDLC process. With Continuous integration and Continuous deployment (CI/CD) being the most popular of these practices, CI/CD tool selection has become increasingly difficult. Security has also become a growing concern in the software supply chain.
When putting together a CI/CD stack, secret management should be at the core of this decision. Not compromising on other features like proper event triggers, available building blocks, the possibility to declare pipeline as code, pipeline reusability, proper UI for visualization, etc.
The recent CircleCi and Travis-Ci hacks further drive home the importance of CI/CD secret management. Selecting a 3rd party SaaS CI/CD service provider and managing secrets on their platform, pose a very high threat level to the security of your infrastructure. Although, there are interesting SaaS solutions like Buildkite that support dedicated secrets management systems like AWS Secrets Manager, GCP Secret Manager, or Hashicorp Vault.
GitHub actions vs Gitlab Ci
This leaves us with SCM specific CI/CD tools, like GitHub actions and Gitlab Ci. GitHub's marketplace for actions provides a host of external integrations, making integrating with external solutions easier. Using officially verified actions created by AWS, GCP, and Hashicorps gives GitHub an edge over Gitlab in our use case.
A secure pipeline
As earlier established, we don't want to Jam secrets into the GitHub UI. Secrets remain in the AWS secrets manager or AWS Systems Manager Parameter Store, AWS CodeBuild is used as the main build agent, and GitHub actions the main pipeline orchestrator.
Using AWS CodeBuild with GitHub Actions and Secret Manager offers several benefits, including:
Rich event trigger from GitHub actions
GitHub needs only codebuild:StartBuild, codebuild:BatchGetBuilds, logs:GetLogEvents permissions.
Large ephemeral AWS Codebuild managed containers.
Codebuild project in a private subnet with access to resources within the VPC e.g RDS instance.
Secrets management in AWS secrets manager or AWS Systems Manager Parameter Store.
Possibility to audit secret access in AWS CloudTrail.
Implementation
To implement this solution create:
An AWS Codebuild project with the appropriate configuration, and IAM role.
Prepare a buildspec.yml file. This file contains the steps and stages to be run in the AWS Codebuild container.
A sample buildspec.yml file:
version: 0.2
env:
parameter-store:
key: "value"
key: "value"
secrets-manager:
key: secret-id:json-key:version-stage:version-id
phases:
build:
commands:
- echo "build stage"
deploy:
commands:
- echo "deploy stage"
A sample GitHub actions yaml file:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-2
- name: Run CodeBuild
uses: aws-actions/aws-codebuild-run-build@v1
with:
project-name: CodeBuildProjectName
buildspec-override: path/to/buildspec.yaml
compute-type-override: compute-type
environment-type-override: environment-type
image-override: ecr-image-uri
env-vars-for-codebuild: |
custom,
requester,
event-name
env:
custom: my environment variable
requester: ${{ github.actor }}
event-name: ${{ github.event_name }}
Sample codes to create the necessary resources can be found on my GitHub.
This architecture combines the benefits of cloud providers while minimizing security risks.
