GitLab流水线中Azure Tenant ID、Client ID及Client Secret的安全存储与注入方案咨询

Hey there! Let's walk through the best options for securely storing your Azure AD credentials (Tenant ID, Client ID, Client Secret) and injecting them into your GitLab pipeline, since you’ve already got AWS, Azure, and HashiCorp Vault in your tech stack. Here’s a breakdown of each approach, along with recommendations:

1. HashiCorp Vault (Top Pick for Your Existing OIDC Workflow) #

Since you’re already building an OIDC integration between Azure AD and Vault, this is the most seamless choice—you’ll keep all credential management within your existing security toolchain.

How to implement: #

• Store credentials: Enable Vault’s kv (key-value) secrets engine, then create a secret path (e.g., secret/azure/ad-creds) to store your three credentials as key-value pairs.
• GitLab pipeline integration: Use GitLab’s native OIDC support to authenticate with Vault without hardcoding tokens:
  1. Configure Vault to trust GitLab as an OIDC identity provider.
  2. Create a Vault policy that grants read access only to the secret/azure/ad-creds path for your pipeline’s OIDC role.
  3. In your GitLab CI/CD config, log into Vault using the pipeline’s JWT token:

     vault login -method=oidc role=gitlab-azure-ad-role
     

  4. Fetch credentials and inject them as environment variables for Terraform:

     export ARM_TENANT_ID=$(vault kv get -format=json secret/azure/ad-creds | jq -r '.data.data.tenant_id')
     export ARM_CLIENT_ID=$(vault kv get -format=json secret/azure/ad-creds | jq -r '.data.data.client_id')
     export ARM_CLIENT_SECRET=$(vault kv get -format=json secret/azure/ad-creds | jq -r '.data.data.client_secret')
     

Pros: #

• Ties directly into your existing Vault + Azure AD OIDC architecture—no new tools to manage.
• Built-in features like credential rotation, audit logging, and granular access policies.
• Eliminates hardcoded secrets in your pipeline config entirely.

2. Azure Key Vault (Native Azure Ecosystem Fit) #

If you prefer staying within Azure’s native tooling, Azure Key Vault is a solid option, especially since your credentials are for Azure AD.

How to implement: #

• Store credentials: Create secrets in Azure Key Vault for each credential (e.g., azure-ad-tenant-id, azure-ad-client-id, azure-ad-client-secret).
• GitLab pipeline integration: Use GitLab’s OIDC integration with Azure to authenticate without storing service principal secrets:
  1. Set up an Azure AD application and configure it to trust GitLab’s OIDC provider.
  2. Assign an Azure role to the app that allows reading secrets from your Key Vault.
  3. In your pipeline, authenticate to Azure using the pipeline’s JWT token:

     az login --service-principal --tenant $AZURE_TENANT_ID --federated-token $CI_JOB_JWT_V2
     

  4. Fetch secrets and inject them into Terraform:

     export ARM_TENANT_ID=$(az keyvault secret show --vault-name your-vault-name --name azure-ad-tenant-id --query value -o tsv)
     export ARM_CLIENT_ID=$(az keyvault secret show --vault-name your-vault-name --name azure-ad-client-id --query value -o tsv)
     export ARM_CLIENT_SECRET=$(az keyvault secret show --vault-name your-vault-name --name azure-ad-client-secret --query value -o tsv)
     

Pros: #

• Native integration with Azure AD—supports automatic secret rotation for your Azure AD client secret.
• Seamless fit if your team is heavily invested in Azure tooling.

Cons: #

• Adds a separate credential management system if you’re already using Vault.

3. AWS Secrets Manager (Cross-Cloud Option) #

If your team relies heavily on AWS services, this is a viable cross-cloud choice, but it’s less aligned with your existing Vault + Azure workflow.

How to implement: #

• Store credentials: Create a secret in AWS Secrets Manager (e.g., azure/ad-creds) with key-value pairs for your three credentials.
• GitLab pipeline integration: Use GitLab’s OIDC integration with AWS to assume an IAM role:
  1. Create an AWS IAM role that trusts GitLab’s OIDC provider and has permissions to read the secret.
  2. In your pipeline, assume the role using the pipeline’s JWT token:

     aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789012:role/gitlab-azure-creds-role --role-session-name gitlab-pipeline --web-identity-token $CI_JOB_JWT_V2
     

  3. Fetch secrets and inject them into Terraform:

     export AZURE_CREDS=$(aws secretsmanager get-secret-value --secret-id azure/ad-creds --query SecretString --output text)
     export ARM_TENANT_ID=$(echo $AZURE_CREDS | jq -r '.tenant_id')
     export ARM_CLIENT_ID=$(echo $AZURE_CREDS | jq -r '.client_id')
     export ARM_CLIENT_SECRET=$(echo $AZURE_CREDS | jq -r '.client_secret')
     

Pros: #

• Leverages AWS’s built-in secret rotation and auditing features.
• Fits well if your team already uses AWS Secrets Manager for other credentials.

Cons: #

• Cross-cloud setup adds complexity compared to using Vault or Azure Key Vault.
• Less integrated with your existing Vault + Azure AD OIDC workflow.

Final Recommendation #

Go with HashiCorp Vault first—it aligns perfectly with your ongoing OIDC integration project, keeps all credential management centralized, and lets you use Vault’s robust security features without adding new tools. If your team strongly prefers staying within Azure’s ecosystem, Azure Key Vault is the next best choice. AWS Secrets Manager only makes sense if your AWS tooling is the primary part of your tech stack.

内容的提问来源于stack exchange，提问作者hitman126