Managing pipeline configuration and secrets

Managing Pipeline Configuration and Secrets

Key Management (e.g., Cloud Key Management Service)

Cloud Key Management Service (KMS) provides a centralized way to create, store, and manage cryptographic keys used to protect data in Google Cloud. The service stores keys in a key ring that lives in a specific region, and each key has multiple key versions so that old versions can be rotated out while keeping older data readable. When a pipeline needs to encrypt or decrypt data, it calls the KMS API, which performs the operation and returns the result without exposing the raw key material outside Google's secure hardware. Keys can be set to automatically rotate on a schedule, which means a new version is created while the old one remains available for decrypting previously encrypted data, and the pipeline automatically uses the latest version for new operations.

Configuration and Secret Management (e.g., Secret Manager, Certificate Manager, Parameter Manager, Workload Identity Federation)

Secret Manager stores sensitive values such as API keys, passwords, and tokens in a secure vault that pipelines can access at runtime. Each secret has multiple versions, and the service returns the enabled version by default unless a specific version is requested. Pipelines authenticate to Secret Manager using a service account that has been granted the Secret Accessor role for the specific secrets they need, which follows the principle of least privilege by limiting what each pipeline can read. Certificate Manager handles SSL and TLS certificates, automating renewal so that expired certificates do not cause outages, and pipelines can reference certificates when configuring load balancers or ingress. Parameter Manager stores non-secret configuration values such as feature flags, environment names, or thresholds that different pipeline stages need to share. Workload Identity Federation allows pipelines running outside Google Cloud (such as in another cloud provider or an on-premises system) to impersonate a service account without downloading a service account key, which reduces the risk of credential leakage. The relationship between these services is that Secret Manager holds the sensitive values, Certificate Manager handles the certificates needed for secure communication, Parameter Manager holds the non-sensitive configuration, and Workload Identity Federation provides the authentication mechanism for accessing all of them from external environments.

Build Versus Runtime Secret Injection

Secrets can be injected into a pipeline at two different times: during the build phase or during the runtime phase. Build-time injection places secrets into the container image or build artifact before it is deployed, which means the secret is baked into the image and travels with it wherever that image is deployed. This approach is simpler but less secure because anyone with access to the image can extract the secret, and rotating the secret requires rebuilding the entire image. Runtime injection pulls secrets from Secret Manager or another secret store when the application container actually starts or when it first needs the secret, keeping the secret out of the image entirely. The pipeline uses a sidecar pattern or an initialization container to fetch the secret and make it available to the application through a secure channel such as a mounted volume or an environment variable that exists only in memory. Choosing between build-time and runtime injection depends on the threat model: runtime injection is preferred when the build pipeline is shared or when secrets must be rotated frequently without redeploying code, while build-time injection may be acceptable for short-lived, hermetically sealed builds where the image never leaves the secure build environment.