Role-Based Access for Pipeline Stages
Each pipeline stage should have minimal IAM permissions. Use separate IAM roles for source, build, test, and deploy stages.
{
"RoleName": "CodeDeployServiceRole",
"AssumeRolePolicyDocument": {
"Statement": [{
"Effect": "Allow",
"Principal": { "Service": "codedeploy.amazonaws.com" },
"Action": "sts:AssumeRole"
}]
},
"Policies": [{
"PolicyName": "DeployToECS",
"PolicyDocument": {
"Statement": [{
"Effect": "Allow",
"Action": ["ecs:UpdateService", "ecs:DescribeServices"],
"Resource": "arn:aws:ecs:us-east-1:123456789012:service/prod/api-service"
}]
}
}]
}
Separation of duties: developers can push code but not deploy to production. Operations can approve deployments but not modify build configurations. Security can audit but not change infrastructure.
Pipeline-level policies control who can view, edit, or execute pipelines. Use IAM conditions to restrict pipeline executions to specific branches or tags.
Secret Management: Secrets Manager and Parameter Store
Never hardcode secrets in pipeline configurations, buildspec files, or source code.
AWS Secrets Manager stores and rotates secrets automatically:
aws secretsmanager create-secret \
--name prod/api/database-password \
--secret-string 'MySecurePassword123!'
Reference secrets in CodeBuild:
# buildspec.yml
env:
secrets-manager:
DB_PASSWORD: prod/api/database-password:password
Parameter Store stores configuration data and secrets. Use SecureString type for sensitive values:
aws ssm put-parameter \
--name /prod/api/db-password \
--value MySecurePassword123! \
--type SecureString \
--key-id alias/aws/ssm
Pipeline environment variables reference secrets from Secrets Manager or Parameter Store. CodeBuild decrypts them at build time. Never log secrets to build output.
OIDC for pipeline authentication: Use OpenID Connect to authenticate pipelines with AWS without long-lived credentials. GitHub Actions and CodePipeline support OIDC federation.
Artifact Encryption and Vulnerability Scanning
Pipeline artifacts (build outputs, deployment packages) must be encrypted at rest and in transit.
S3 bucket encryption: Enable SSE-KMS or SSE-S3 encryption on artifact buckets:
ArtifactBucket:
Type: AWS::S3::Bucket
Properties:
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: aws:kms
KMSMasterKeyID: !Ref ArtifactKMSKey
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
Vulnerability scanning in builds: Integrate security scanning into the build phase:
- Container scanning: ECR image scanning, Trivy, Snyk Container
- Dependency scanning: npm audit, Snyk, Dependabot
- SAST: SonarQube, CodeQL, Semgrep
- IaC scanning: Checkov, tfsec, cfn-nag
# buildspec.yml
phases:
build:
commands:
- npm audit --production
- trivy image myapp:latest --severity HIGH,CRITICAL
- checkov -d ./infrastructure
Fail the build on critical vulnerabilities. Use quality gates to enforce security thresholds.
Audit Logging, Approval Gates, and Compliance
Comprehensive audit logging tracks all pipeline activities for compliance and forensics.
CloudTrail logs all API calls: who triggered the pipeline, what changes were deployed, who approved deployments.
CloudWatch Logs store build logs, test results, and deployment output. Set retention policies for compliance (7 years for financial, 3 years for general).
Approval gates enforce human review before critical deployments:
ApprovalAction:
ActionTypeId:
Category: Approval
Owner: AWS
Provider: Manual
Version: '1'
Configuration:
CustomData: 'Review deployment to production'
NotificationArn: !Ref ApprovalSNSTopic
Compliance controls:
- Branch protection: require PR reviews before merge
- Signed commits: verify code authorship
- Deployment windows: restrict deployments to business hours
- Change management: link deployments to tickets
- Rollback procedures: document and test rollback steps
Pipeline monitoring: Use CloudWatch dashboards to track pipeline health, deployment frequency, success rates, and mean time to recovery.
Quiz
1. Why should each pipeline stage have a separate IAM role?
2. How should you store database passwords used in CI/CD pipelines?
3. What is the purpose of vulnerability scanning in the build phase?
Flashcards
Question
Why use separate IAM roles per pipeline stage?
Click to reveal answer
Answer
Least privilege: limits what each stage can access. If one stage is compromised, the blast radius is contained.
Question
What is the purpose of Secrets Manager in pipelines?
Click to reveal answer
Answer
Securely stores and auto-rotates secrets, referenced by pipelines without exposing values in configuration.
Question
What security scans should run in CI/CD?
Click to reveal answer
Answer
Container scanning (Trivy), dependency scanning (npm audit), SAST (CodeQL), and IaC scanning (Checkov).
Question
What is an approval gate?
Click to reveal answer
Answer
A manual review step in the pipeline that requires human approval before proceeding to the next stage.
Revision Notes
Key Takeaways
- 1. Separate IAM roles per stage enforce least privilege
- 2. Use Secrets Manager or Parameter Store for credential management
- 3. Encrypt artifacts at rest and scan for vulnerabilities in builds
- 4. Audit logs, approval gates, and compliance controls protect production
Interview Tips
- • Design a pipeline security architecture for a regulated industry
- • Explain how you would implement OIDC for pipeline authentication
- • Describe vulnerability scanning integration in a CI/CD pipeline
- • Discuss compliance requirements for pipeline audit logging
Cheat Sheet
RBAC: separate roles per stage, least privilege. Secrets: Secrets Manager, Parameter Store SecureString, never hardcode. Scanning: Trivy (containers), npm audit (deps), CodeQL (SAST), Checkov (IaC). Compliance: CloudTrail (API logs), approval gates, branch protection, deployment windows.