6. CI/CD Identity
6. CI/CD Identity
← Previous: Kubernetes Workloads | Index | Next: GitOps Identity →
6.1 OIDC Federation Patterns
6.1.1 The Problem with Static Credentials
Traditional CI/CD secrets management:
| Problem | Impact |
|---|---|
| Secrets in pipeline config | Visible to anyone with repo access |
| Long-lived credentials | Compromised credential usable indefinitely |
| Shared credentials | No per-job accountability |
| Manual rotation | Operational burden, often skipped |
6.1.2 OIDC Federation Solution
OIDC federation provides:
| Benefit | Mechanism |
|---|---|
| No stored secrets | JWT obtained at runtime |
| Short-lived | Token valid for minutes |
| Auditable | Claims identify exact pipeline run |
| Automatic | No rotation needed |
6.1.3 OIDC Token Flow
6.2 GitHub Actions Integration
6.2.1 GitHub OIDC Overview
GitHub Actions provides OIDC tokens with rich claims:
| Claim | Example | Purpose |
|---|---|---|
iss | https://token.actions.githubusercontent.com | Issuer |
sub | repo:org/repo:ref:refs/heads/main | Subject (repo + ref) |
repository | org/repo | Repository name |
ref | refs/heads/main | Git reference |
workflow | deploy.yml | Workflow file |
job_workflow_ref | org/repo/.github/workflows/deploy.yml@refs/heads/main | Exact workflow version |
actor | username | User who triggered |
event_name | push | Trigger event |
6.2.2 AWS Integration
Configure AWS to trust GitHub OIDC:
GitHub Actions workflow:
6.2.3 Vault Integration
Configure Vault to trust GitHub OIDC:
GitHub Actions workflow with Vault:
6.2.4 Claim-Based Authorization
Use claims for fine-grained access control:
| Claim Pattern | Access |
|---|---|
repository: myorg/* | Any repo in org |
repository: myorg/myrepo, ref: refs/heads/main | Only main branch |
workflow: deploy.yml | Only deploy workflow |
environment: production | Only production environment |
6.3 GitLab CI Integration
6.3.1 GitLab OIDC Overview
GitLab CI provides OIDC tokens with claims:
| Claim | Example | Purpose |
|---|---|---|
iss | https://gitlab.com | Issuer |
sub | project_path:myorg/myrepo:ref_type:branch:ref:main | Subject |
project_path | myorg/myrepo | Project path |
ref | main | Git reference |
ref_type | branch | Reference type |
pipeline_id | 12345 | Pipeline ID |
job_id | 67890 | Job ID |
6.3.2 Vault Integration
Configure Vault for GitLab:
GitLab CI pipeline:
6.4 Tekton Pipeline Identity
6.4.1 Tekton in Kubernetes
Tekton runs as Kubernetes pods, so it uses Kubernetes-native identity:
| Method | Use Case |
|---|---|
| ServiceAccount | Kubernetes API access |
| Vault Kubernetes auth | Secret access |
| SPIRE | Service mesh identity |
6.4.2 Pipeline ServiceAccount
Each pipeline should have a dedicated ServiceAccount:
6.4.3 Vault Integration
6.5 Legacy: Vault AppRole
6.5.1 When AppRole is Needed
AppRole is a fallback for systems that cannot use OIDC:
| Scenario | Use AppRole |
|---|---|
| Legacy CI/CD (Jenkins without OIDC) | Yes |
| Self-hosted runners without OIDC | Yes |
| GitHub/GitLab with OIDC | No (use OIDC) |
| Tekton | No (use Kubernetes auth) |
6.5.2 AppRole Configuration
6.5.3 AppRole Limitations
| Limitation | Mitigation |
|---|---|
| Secret ID is a secret | Single-use, short TTL |
| Less traceable than OIDC | Include custom metadata |
| Manual rotation | Automation for Secret ID generation |
6.6 CI/CD Security Controls
6.6.1 Branch Protection
Restrict credential access by branch:
| Branch | Access |
|---|---|
main | Production credentials |
develop | Staging credentials |
feature/* | Development credentials only |
dependabot/* | No credentials (build only) |
6.6.2 Environment Protection
Use GitHub/GitLab environments for deployment gates:
6.6.3 Claim Validation Matrix
| System | Required Claims | Optional Claims |
|---|---|---|
| AWS IAM | sub (repo:ref) | repository, ref |
| Vault | repository, ref | workflow, environment |
| GCP WI | sub (attribute mapping) | Custom attributes |
6.7 Compliance Mapping
6.7.1 Invariant Enforcement
| Invariant | CI/CD Implementation |
|---|---|
| INV-2 | OIDC tokens are short-lived (minutes) |
| INV-5 | OIDC federation required |
| INV-10 | Pipeline runs logged with full context |
6.7.2 Audit Trail
Each CI/CD run produces audit events:
| Event | Source | Contains |
|---|---|---|
| OIDC token request | CI provider | repo, ref, workflow, actor |
| Cloud STS assume | Cloud provider | role, session, source token |
| Vault login | Vault audit | JWT claims, policies granted |
| Secret access | Vault audit | path, operation, actor |
Document Navigation
| Previous | Index | Next |
|---|---|---|
| ← 5. Kubernetes Workloads | Table of Contents | 7. GitOps Identity → |
End of Section 6