How do I connect CI/CD to cloud infrastructure provisioning and secrets management?

A good way to connect CI/CD with cloud provisioning and secrets management is to treat them as one pipeline with clear boundaries:

1) Put infrastructure in code

Use Infrastructure as Code (IaC) so your cloud resources are versioned and reviewable.

Common tools:

• Terraform / OpenTofu
• CloudFormation / CDK (AWS)
• Bicep / ARM (Azure)
• Pulumi

Store IaC in git alongside your app or in a separate infra repo.

2) Separate pipeline stages

Typical CI/CD flow:

1. Commit / PR

   • Run linting, formatting, static checks
   • Validate IaC (terraform validate, plan, etc.)
   • Run app tests, security scans

2. Merge to main

   • Deploy to dev/test environment
   • Provision/update cloud resources
   • Run integration tests

3. Promote

   • Manual approval or automated policy gate
   • Deploy to staging/prod
   • Apply controlled infrastructure changes

3) Use CI/CD to provision cloud resources safely

Your pipeline can run IaC commands, but avoid giving it full cloud admin access.

Recommended pattern:

• CI runner authenticates to cloud via short-lived credentials
• Pipeline runs:
  • init
  • plan
  • policy checks / approval
  • apply

Best practices:

• Use separate environments/accounts/subscriptions for dev/staging/prod
• Require manual approval before prod applies
• Use remote state and locking
• Tag resources consistently
• Use policy-as-code (e.g., OPA/Conftest, Sentinel, Azure Policy, AWS SCPs)

4) Handle secrets outside the repo

Never put secrets in git or hardcode them in CI variables unless unavoidable.

Use a secrets manager:

• HashiCorp Vault
• AWS Secrets Manager / SSM Parameter Store
• Azure Key Vault
• GCP Secret Manager
• Or CI-native secret stores for limited cases

How CI/CD should access secrets

Use one of these patterns:

• OIDC / workload identity: CI platform exchanges a signed identity token for cloud auth
• CI retrieves secrets at runtime from the secrets manager
• Inject secrets only into the job that needs them
• Rotate secrets automatically

Avoid:

• Long-lived cloud access keys in CI
• Writing secrets into build artifacts/logs
• Storing prod secrets in plaintext pipeline variables

5) Choose the right secret flow

There are two common types of secrets:

a) CI/CD credentials to cloud

Use OIDC federation instead of static keys:

• GitHub Actions → AWS IAM role via OIDC
• GitLab CI / Azure DevOps / Jenkins can do similar patterns

This gives:

• Short-lived tokens
• No secret to rotate in the CI platform
• Better auditing

b) Application runtime secrets

Inject secrets at deploy time from the secrets manager:

• App gets database password/API key at startup
• Or fetches secrets dynamically at runtime
• Prefer managed identity / IAM role over embedded secrets

6) Use environment-specific configuration

Keep environment values separate from secrets:

• Dev/staging/prod settings in config files, variables, or overlays
• Secrets stored only in secret manager
• Example: Terraform workspaces, separate var files, Helm values overlays, Kustomize bases/patches

7) Add governance and auditability

Track:

• Who changed IaC
• What plan was approved
• What secrets were accessed
• What got deployed and when

Enable:

• Cloud audit logs
• CI pipeline logs with secret masking
• Approval records
• Drift detection

8) Example end-to-end flow

A common setup:

1. Developer opens PR
2. CI runs tests and terraform plan
3. Plan is posted to PR for review
4. Merge triggers deploy pipeline
5. Pipeline authenticates to cloud using OIDC
6. Pipeline applies infra changes
7. Pipeline deploys app
8. App reads runtime secrets from Vault/Secrets Manager using its managed identity

9) Simple reference architecture

• Git repo: app + IaC
• CI system: GitHub Actions / GitLab CI / Jenkins
• Cloud auth: OIDC federation
• Provisioning: Terraform/OpenTofu
• Secrets: Vault / cloud secrets manager
• Runtime identity: IAM role / managed identity
• Policy: OPA / cloud-native policies

10) Key rules of thumb

• Use CI/CD to orchestrate provisioning, not to store secrets
• Use short-lived identities
• Keep infra changes reviewed
• Separate config from secret material
• Prefer managed identity + secrets manager over static credentials

If you want, I can also give you:

1. a GitHub Actions + Terraform + AWS Secrets Manager example, or
2. a generic reference pipeline diagram for your cloud/provider.