Setting Up OIDC to Get Credentials from Google Cloud

Summary

This video demonstrates how to securely retrieve Google Cloud credentials within a GitLab CI/CD pipeline using OpenID Connect (OIDC). The process involves creating a Google Cloud workload identity pool, configuring a service account, setting up the necessary CI/CD variables in GitLab, and writing a script to fetch an access token. The final result is a simple pipeline that prints out the credentials, enabling the pipeline to interact with Google Cloud resources securely. It's a comprehensive guide to integrating Google Cloud credentials management in a CI/CD environment.

Takeaways

• 😀 OpenID Connect (OIDC) allows secure credential retrieval from Google Cloud within a CI pipeline.
• 😀 OIDC provides a secure way to generate and access credentials needed for Google Cloud operations (e.g., creating or destroying servers, accessing storage).
• 😀 The process involves three key steps: creating a workload identity pool, creating a service account, and creating the CI pipeline in GitLab.
• 😀 First, create a Google Cloud workload identity pool and provider by selecting OIDC and configuring issuer URLs with specific audience settings.
• 😀 After setting up the identity provider, you must map Google Cloud attributes to GitLab attributes (e.g., google.subject maps to assertion.sub).
• 😀 The service account created in Google Cloud must have the right permissions, specifically the 'Service Account Token Creator' permission to impersonate itself and generate OAuth 2.0 tokens.
• 😀 When creating a service account, ensure it can impersonate itself by assigning the correct roles and permissions for token creation.
• 😀 In GitLab, create a project to store and configure the necessary CI/CD variables (e.g., project number, pool ID, provider ID, service account email).
• 😀 A simple bash script (`get_credentials.sh`) is created to generate the Google Cloud credentials, using curl and JQ to interact with Google Cloud APIs and output an access token.
• 😀 The pipeline configuration in GitLab uses a Docker image with `curl` and `jq` preinstalled, then runs the bash script to generate and print the access token as part of the CI process.
• 😀 Once the pipeline runs, the generated access token can be used to interact with Google Cloud resources securely, ensuring seamless integration with GitLab CI/CD.

Q & A

What is OIDC and why is it used in a CI pipeline for Google Cloud?

OIDC (OpenID Connect) is a protocol used to authenticate users and provide identity services. In a CI pipeline for Google Cloud, OIDC is used to retrieve credentials securely, allowing the pipeline to interact with Google Cloud services, such as creating or destroying servers, accessing storage, and more, without hard-coding credentials.

What is the purpose of creating a workload identity pool and provider in Google Cloud?

The purpose of creating a workload identity pool and provider is to enable federated authentication between an external identity provider (like GitLab) and Google Cloud. This allows your CI pipeline to securely authenticate and interact with Google Cloud resources without requiring service account keys.

How do you set up a workload identity provider in Google Cloud?

To set up a workload identity provider, you first create a workload identity pool in Google Cloud, then configure the provider by selecting OIDC, specifying the issuer URL (e.g., GitLab.com), and mapping attributes between Google Cloud and GitLab to establish proper identity mapping.

Why is it important to map attributes between Google Cloud and GitLab?

Mapping attributes ensures that the information associated with the identity in Google Cloud (such as user roles) can be correctly translated into equivalent attributes in GitLab. This helps maintain consistency and proper access control when the CI pipeline interacts with Google Cloud.

What is the role of the service account in this process?

The service account in this process acts as the identity that the CI pipeline will impersonate to perform operations in Google Cloud. It must have appropriate permissions, such as 'Service Account Token Creator', to allow the pipeline to authenticate and generate OAuth 2.0 tokens for access.

How do you grant impersonation permissions to a service account?

To grant impersonation permissions, you need to assign the 'Service Account Token Creator' role to the service account. This allows it to generate OAuth tokens and impersonate other accounts or perform operations as specified in the CI pipeline.

What are CI/CD variables, and why are they necessary for this setup?

CI/CD variables in GitLab are used to store sensitive or configurable information, such as project IDs, pool IDs, and service account emails, securely. These variables are referenced in the script during pipeline execution to avoid hardcoding sensitive information directly into the pipeline configuration.

How do you configure CI/CD variables in GitLab?

CI/CD variables are configured in the GitLab project settings under the 'CI / CD' section. Variables such as project number, pool ID, provider ID, and service account email are created to be used within the pipeline script, ensuring the pipeline is able to interact with Google Cloud securely.

What does the GitLab CI/CD pipeline do after setting up the credentials script?

Once the credentials script is set up, the pipeline runs and executes the script to generate a federated token, use that token to get an access token, and finally output the access token. This token is used to authenticate and perform actions within Google Cloud.

What is the purpose of the 'chmod +x' command in the pipeline script?

The 'chmod +x' command is used to give execution permissions to the script (get_credentials.sh). Without this step, the script wouldn't be executable, and the pipeline would fail to run it.