Security Governance: How to Manage It Effectively on Google Cloud Platform

Security and authentication questions are crucial for any platform — Google Cloud Platform is no exception. How can you manage security governance well and access Google resources from external environments such as GitLab via CI/CD, without having to handle long-term credentials? We answer these questions in this article…

JSON Key Generation Is Not Enough

The usual way to authenticate with Google Cloud APIs is to generate JSON keys, which act like passwords for a service account, and store them somewhere “safe.”

From my experience, no place is truly safe… especially when one morning you get an email saying, “Urgent Meeting: A service account password has been compromised.” Securing, storing, distributing, rotating, and monitoring these keys can be tedious — which is why this method is not recommended.

Instead, Google recommends a better way to authenticate: Workload Identity Federation. I’ll explain what I consider the safest method to improve security and simplify access management to Google Cloud resources. We’ll also walk you through GitLab CI’s OpenID Connect (OIDC) integration. I’ll show you how to secure interactions between GitLab CI/CD pipelines and Google’s Workload Identity Federation resources — avoiding the need to store Google Cloud service account keys in GitLab CI variables.

Embracing Authentication with Workload Identity Federation

Let’s start by implementing a GitLab CI/CD pipeline with Google Cloud using Workload Identity Federation to access cloud resources.

This is aimed at anyone managing application versions in Git or deploying infrastructure (IaC) via Terraform on Google Cloud.

What You’ll Learn:

• An explanation of the Workload Identity Federation concept and how GCP components interact with external applications.
• How to configure Workload Identity Federation to access GCP resources.
• How to create a GitLab CI pipeline that lists all Cloud Storage buckets.

1.Workload Identity Concepts

Workload Identity is a mechanism offered by Google to improve security. It allows authentication with other services like GitLab/GitHub/Cloud. This enables access to Google services using Identity and Access Management (IAM).

Key benefits:

• No need for long-term credentials (e.g., traditional keys stored in variables).
• Improved security by borrowing identities via service accounts.
• Fine-grained scoping: External applications can map specific token attributes to permissions.
• Short-lived credentials: Tokens expire automatically after one hour.
• Minimal management overhead: No secrets to store or manage.

Workload Identity Pools and Providers

• Workload Identity Pool: A container linked to specific GCP projects, grouping service accounts and external identities.
• Workload Identity Provider: An identity provider (like GitLab, GitHub, or AWS) that establishes a trust relationship between external user identities and GCP service accounts — allowing access control.

In other words, the Workload Identity Provider is an Identity Provider (IDP) for a Google Workload Identity Pool, designed to integrate external applications with Google Cloud.

• Security Token Service: A service that generates short-lived tokens to access Google Cloud resources in exchange for Google credentials.
• Service Account: A special account, identified by a unique email address, used by applications or workloads (such as a Compute Engine instance). Rather than using a personal user account, it’s best practice to use a service account.
• Google Cloud Resources: A set of components such as computers, hard drives, and virtual resources like virtual machines (VMs). Google Cloud resources include projects, keyrings, storage, tools, and more.

• The workload is assessed by your Identity Provider.
• The Identity Provider sends the account credentials.
• The workload forwards the credentials to Google’s Security Token Service.
• The credentials are validated against the Workload Identity Pool.
• A response is returned indicating whether the credentials are valid.
• A short-lived token is issued to access Google services, allowing the workload to impersonate a service account.
• The identity of a service account is assumed using the temporary token.
• Access to Google Cloud resources is then granted.

Configuration Workload Identity Federation

Step1 : Creation Workload Identity Pool

Workload Identity Federation allows you to organize and manage external identities.

A single GCP project can have multiple identity pools, each enabling integration with various external Identity Providers. This lets you create a collection of identities and maintain control at the project level.

gcloud iam workload-identity-pools create \
–project=”” \
–location=”global” \
–display-name=”Workload identity pool for GitLab project ID”

• <your_google_cloud_project_id>: The ID of your Google Cloud project. To enhance security, it’s recommended to use a dedicated project for identity management, separate from your resource and CI/CD projects.
• <your_identity_pool_id>: The ID to use for the identity pool.

Step 2 : Pool Providers Creation

Providers: A provider is an entity that defines the relationship between Google Cloud and your Identity Provider. For example, GitLab serves as the IDP (Identity Provider) for a Workload Identity Pool. To integrate it with Google Cloud, the provider must be configured on the Google side — specifically through attribute mapping — to grant the necessary IAM permissions for deploying your workloads to Google Cloud.

gcloud iam workload-identity-pools providers create-oidc \
–workload-identity-pool=\
–issuer-uri= \ # example “https://gitlab.com” \
–project=”
–location=”global” \
–display-name=”My OIDC Provider” \
–attribute-mapping=”google.subject=assertion.sub”

Attribute Mapping: This allows you to map authentication attributes transmitted by the Identity Provider to Google Cloud. It defines the rules for how attributes are matched.

google.subject is the standard attribute used by Google Cloud, and assertion.sub refers to the corresponding attribute provided by the Identity Provider

Service Account

Creation of a service account, role assignment, and permission definition to access the desired resources.
Create a service account:

bashCopierModifiergcloud iam service-accounts create "my-service-account" \
--project="MY_PROJECT"
We will then assign the Storage Admin role (roles/storage.admin), which is required for our GitLab CI/CD demonstration:

bashCopierModifiergcloud projects add-iam-policy-binding "MY_PROJECT" \
--member="serviceAccount:my-service-account@MY_PROJECT.iam.gserviceaccount.com" \
--role="roles/storage.admin"

Finally, we will enable workload identity impersonation for the service account to authorize the workload to access Google resources — a more secure approach than using a service account key:

bashCopierModifiergcloud iam service-accounts add-iam-policy-binding "my-service-account@MY_PROJECT.iam.gserviceaccount.com" \
--project="MY_PROJECT" \
--role="roles/iam.workloadIdentityUser" \
--member="principalSet://iam.googleapis.com/projects/MY_PROJECT_number/locations/global/workloadIdentityPools/MY_POOL/*"

Example: Creating a CI Pipeline in GitLab Running Outside of Google Cloud

Some developers want to execute and deploy Terraform code to create resources on Google Cloud. Others may only need to perform specific gcloud configurations. Both approaches use Google Cloud APIs, which require proper authentication and authorization.

This pipeline allows the integration of infrastructure projects and the deployment of resources or data projects for industrialization.

In our demonstration, we chose to use the gcloud CLI to display information about an existing bucket in Google Cloud using the gsutil ls command, triggered through a GitLab CI/CD pipeline.

In the previous steps, we configured our Workload Identity Federation with:

• Workload Identity Pools
• Workload Identity Pool Providers
• A Service Account with the necessary roles

---

Step 1: Create a new GitLab project or use an existing one.

Step 2: Create a .gitlab.yml file.

Information about your Google environment:

Add id_tokens to your Pipeline :

Obtain temporary credentials using an identity token:

You can then use the resulting federated token to impersonate the service account created in the previous section:

Then, you can access Google Cloud resources using the gcloud storage ls command to view the buckets in Cloud Storage:

The result after executing our pipeline:

Google Workload Identity Federation is therefore a recommended and secure solution. It helps reduce operational workload and mitigates the security risks associated with JSON keys, which are one of the main sources of cyberattacks in the cloud.

By integrating Workload Identity Federation, I achieved better security governance. Most importantly, I was able to deploy a robust, secure, and scalable deployment strategy. This applies to the entire deployment process and also ensures consistency and reliability across different environments.