Secure AWS Credentials in GitLab CI/CD Using HashiCorp Vault
As organizations shift towards DevSecOps and adopt cloud-native CI/CD pipelines, securing cloud credentials becomes a top priority. This guide walks you through the best practices for securely managing and injecting AWS credentials into GitLab CI/CD pipelines using HashiCorp Vault.
Why Secure AWS Credentials?
Storing AWS credentials in plain text within .gitlab-ci.yml or GitLab’s project-level secrets can pose security risks. If these credentials are leaked or misused, attackers could:
Launch unauthorized cloud resources
Steal sensitive data from S3.
Terminate or modify production workloads.
Using HashiCorp Vault, a secrets management tool, ensures credentials are dynamically generated, time-limited, and auditable.
Prerequisites
Before you begin:
An active GitLab project with a working CI/CD pipeline
HashiCorp Vault is installed and running (either locally, via HCP, or self-hosted)
An IAM role and policy in AWS that Vault can assume to generate credentials
A Vault AWS secrets engine is configured.
Step-by-Step: Secure AWS Access via Vault
1. Configure Vault’s AWS Secrets Engine
Enable and configure the AWS secrets engine:
vault secrets enable -path=aws aws
Set your AWS credentials (used by Vault to generate temporary credentials):
vault write aws/config/root \
access_key=YOUR_ACCESS_KEY \
secret_key=YOUR_SECRET_KEY \
region=us-east-1
Define a Vault role:
vault write aws/roles/gitlab-role \
credential_type=iam_user \
policy_document=-<<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:*"],
"Resource": "*"
}
]
}
EOF
2. Enable Vault AppRole Authentication
To allow GitLab runners to authenticate securely, use AppRole:
vault auth enable approle
Create a Vault policy for GitLab:
# policy.hcl
path "aws/creds/gitlab-role" {
capabilities = ["read"]
}
Apply the policy:
vault policy write gitlab-policy policy.hcl
Create an AppRole:
vault write auth/approle/role/gitlab-role \
token_policies="gitlab-policy" \
secret_id_ttl=60m \
token_ttl=60m \
token_max_ttl=120m
Fetch the Role ID and Secret ID:
vault read auth/approle/role/gitlab-role/role-id
vault write -f auth/approle/role/gitlab-role/secret-id
3. Securely Inject AWS Credentials in GitLab CI
Store the Vault Role ID and Secret ID securely in GitLab CI/CD Variables (Settings > CI/CD > Variables):
VAULT_ROLE_ID
VAULT_SECRET_ID
Define the .gitlab-ci.yml:
stages:
- deploy
deploy:
stage: deploy
image: hashicorp/vault:latest
script:
- export VAULT_ADDR=https://vault.example.com
- export AWS_CREDS=$(vault write -field=data aws/creds/gitlab-role \
-address=$VAULT_ADDR \
-method=approle \
role_id=$VAULT_ROLE_ID \
secret_id=$VAULT_SECRET_ID)
- export AWS_ACCESS_KEY_ID=$(echo $AWS_CREDS | jq -r .access_key)
- export AWS_SECRET_ACCESS_KEY=$(echo $AWS_CREDS | jq -r .secret_key)
- export AWS_SESSION_TOKEN=$(echo $AWS_CREDS | jq -r .security_token)
- aws s3 ls
Benefits of This Approach
Enhanced Security: Credentials are not stored in GitLab or code.
Temporary Credentials: Time-limited AWS credentials reduce risk.
Auditability: All secret requests are logged in Vault.
Dynamic Rotation: Credentials can be revoked or rotated automatically.
Security Best Practices
Use least privilege IAM policies for Vault-generated credentials.
Rotate Vault secrets and AppRole credentials regularly.
Set strict TTLs on all credentials.
Monitor Vault access logs for anomalies.
Conclusion
Integrating HashiCorp Vault with GitLab CI/CD protects AWS credentials with strong access control, secret rotation, and detailed audit logging. This setup lays the foundation for secure, scalable DevSecOps pipelines in the cloud.

Comments
Post a Comment