Keyless Multi-Environment CI/CD on GCP

Project Overview

This project standardised how application artifacts move from the main branch into development, staging, and production on Google Cloud Platform.

It combined three related improvements:

1. Build once and promote the same versioned artifact between environments.
2. Manage Kubernetes configuration through reusable Kustomize bases and overlays.
3. Replace long-lived CI/CD and workload credentials with Workload Identity Federation.

The resulting delivery model supports Kubernetes, Cloud Run, and Firebase while keeping environment differences explicit and reducing the number of static credentials that need to be stored and rotated.

The Delivery Problem

Building separately for each environment can introduce drift: development, staging, and production may nominally reference the same source revision but run artifacts created at different times or under different conditions.

Kubernetes configuration can also drift when every service and environment maintains a copied set of manifests. Small fixes must then be repeated across many files, and it becomes difficult to distinguish intentional differences from accidental ones.

Finally, service-account JSON keys create an avoidable security and operational burden. Keys stored in CI/CD or mounted into containers are long-lived credentials that must be distributed, protected, audited, and rotated.

Build Once, Deploy Many

The pipeline uses a main-branch build as the source of a versioned container artifact:

1. GitHub Actions checks out and validates the main branch.
2. The pipeline builds a versioned container image once.
3. The image is published to a shared Artifact Registry.
4. Development, staging, and production reference that same artifact version.
5. Runtime-specific jobs deploy to Kubernetes, Cloud Run, or Firebase as required.

Promoting an immutable artifact means production runs the same build that was already exercised in earlier environments. It also creates a clearer audit trail between a source revision, artifact version, and deployment.

Kubernetes Configuration with Kustomize

Kubernetes manifests were organised into composable Kustomize layers:

• A base contains common resources, labels, probes, ports, and configuration structure.
• Service overlays apply changes that belong to an individual service.
• Environment overlays apply development, staging, or production differences.
• CI renders the selected composition into standard Kubernetes manifests before deployment.

This approach keeps common configuration in one place and makes every override visible in source control. Rendered output can be reviewed or validated before it reaches the cluster.

Keyless GitHub Actions Authentication

GitHub Actions authenticates to GCP through Workload Identity Federation.

Instead of storing a service-account JSON key in GitHub secrets, the workflow presents its GitHub OIDC identity and receives short-lived GCP credentials. IAM conditions and roles restrict which repository, branch, and workflow can assume the deployment identity and what that identity can do.

The federated credentials support authorised operations such as:

• Publishing container images to Artifact Registry
• Reading deployment configuration
• Deploying to the intended GCP runtime
• Accessing only the projects and environments assigned to the workflow

This removes a high-value static credential from CI/CD and reduces key-rotation work.

Workload Identity Federation for GKE

Runtime services were also moved away from mounted service-account key files.

With Workload Identity Federation for GKE, a Kubernetes service account is associated with an authorised GCP identity. The workload obtains short-lived credentials at runtime and can access only the GCP resources allowed by its IAM roles.

This allows each service to have a dedicated, least-privilege identity without copying private key files into pods. Application code uses standard GCP authentication rather than knowing where a credential file has been mounted.

Artifact Access

Artifact Registry and Kubernetes access follow the same identity-first principle: platform identities and short-lived credentials are preferred over manually distributed keys.

The pipeline publishes versioned images under an authorised deployment identity, and the Kubernetes environment retrieves approved artifacts through its configured GCP identity path.

Results

Delivery consistency

• Established a shared Artifact Registry as the source of deployable images
• Promoted the same versioned artifact through development, staging, and production
• Supported Kubernetes, Cloud Run, and Firebase delivery paths
• Made deployments easier to trace back to source and artifact versions

Maintainability

• Reduced duplicated Kubernetes YAML
• Centralised common configuration in Kustomize bases
• Kept service and environment differences explicit in overlays
• Rendered standard manifests for validation and deployment

Security

• Replaced static GitHub-to-GCP credentials with short-lived federated access
• Removed mounted service-account key files from GKE workloads
• Applied workload-specific identities and least-privilege IAM
• Reduced credential distribution and rotation responsibilities

Skills Demonstrated

• Multi-environment CI/CD architecture
• Immutable artifact creation and promotion
• GitHub Actions and Artifact Registry
• Kubernetes configuration management with Kustomize
• GCP IAM and Workload Identity Federation
• Keyless workload authentication
• GKE, Cloud Run, and Firebase delivery