GCP

Bad Practice: Service Account Keys

Service account keys, even when stored securely, provide persistent access, which becomes a security risk if the keys are exposed. They are valid for extended periods, requiring manual intervention for rotation or revocation.

 from google.cloud import storage
                  

                  import os
                  

                  

                  # Long-lived service account key loaded securely
                  

                  service_account_key =
                  os.getenv('GCP_SERVICE_ACCOUNT_KEY_PATH')  # Loaded from
                  secure path
                  

                  

                  client =
                  storage.Client.from_service_account_json(service_account_key)
                  

                  

                  # List buckets in GCP
                  

                  buckets = list(client.list_buckets())
                  

                  print("Buckets:", buckets)

Good Practice: Workload Identity Federation

Workload Identity Federation eliminates the need for long-lived service account keys, using short-lived tokens that are automatically managed.

By using Workload Identity Federation, the credentials are ephemeral, automatically rotated, and valid only for short durations. This eliminates the need for long-lived service account keys and significantly reduces the risk of long-term exposure.

How to Use a Workload Identity Role in GCP

To convert a service account key to a role-based authentication in Google Cloud Platform (GCP), you begin by creating a new IAM role with the necessary permissions that match the original service account's access level.

Next, update the applications or services that rely on the key to use Workload Identity Federation or the Application Default Credentials to assume the role and obtain temporary credentials without using long-term keys.

Once the applications are updated to use these secure methods for authentication, you can disable and delete the old service account key, improving security by leveraging short-lived, dynamically generated credentials instead of static keys.

from google.cloud import storage
                

                

                # Use ephemeral credentials via Workload Identity Federation
                

                client = storage.Client()  # Credentials automatically
                picked up from environment
                

                

                # List buckets in GCP
                

                buckets = list(client.list_buckets())
                

                print("Buckets:", buckets)

How it Works

When an Azure resource (e.g., a VM or Azure Function) with a managed identity needs to access another Azure service (such as a Key Vault, Storage Account, or Azure SQL Database), it authenticates using Azure AD. This process does not require any manual management of credentials, as Azure manages the lifecycle of the identity and authentication behind the scenes.

Service Accounts in GCP
In GCP, Service Accounts are identities used by applications, virtual machines, and services (such as Google Compute Engine, App Engine, and Cloud Functions) to access resources securely. Service accounts are analogous to IAM users or managed identities in AWS and Azure.
There are two types of service accounts:
- Google-managed service accounts: Created and managed by Google for specific GCP services, such as Compute Engine default service accounts.
- User-managed service accounts: Created by users for custom applications or services that need to authenticate and access GCP resources.
Authentication via OAuth 2.0 Tokens
When a service or application in GCP needs to access another resource, such as Google Cloud Storage, Cloud Pub/Sub, or BigQuery, it does so by using a service account to request an OAuth 2.0 token.
The steps involved in this process are:
1. Obtaining a token
  - When an application or service (such as a virtual machine or function) wants to access a GCP resource, it uses a service account to request a JWT (JSON Web Token) from the Google OAuth 2.0 token service.
  - The service account signs the JWT using its private key (which is stored securely in GCP or a managed environment like Google Secret Manager).
  - The JWT is sent to Google's Identity Token Service (ITS) or STS, which validates the request and issues a short-lived OAuth 2.0 access token.
2. Token Token Issuance
  - Similar to AWS STS and Azure OAuth tokens, Google’s STS issues a temporary access token (OAuth 2.0 format), typically valid for 1 hour.
  - This token is scoped to a particular set of permissions based on the roles assigned to the service account in IAM. The token is only valid for accessing specific resources for the defined time period.
3. Using the Token for API Requests
  - The service or application uses the issued OAuth 2.0 token to access GCP services and resources. This token is passed in the Authorization header of API requests as a Bearer token.

Example of an Authenticated API Request

GET https://storage.googleapis.com/storage/v1/b/my-bucket Authorization: Bearer <OAuth-Token>

This token-based authentication mechanism ensures that the service account is authenticated securely without needing long-lived credentials

Role-Based Access Control (RBAC) in GCP
Similar to AWS IAM and Azure RBAC, GCP uses Identity and Access Management (IAM) to manage access control. IAM in GCP determines what actions a service account (or any identity) can perform on a specific resource.
- IAM Roles: Permissions in GCP are managed through roles, which are collections of permissions that can be assigned to a service account or other identities (e.g., users, groups). For example, a service account might be given the Storage Object Viewer role to allow read-only access to Cloud Storage objects.

IAM Policy: Resources in GCP (such as Cloud Storage buckets, BigQuery datasets, or Compute Engine instances) have associated IAM policies that specify who can access the resource and what actions they can perform. These policies define which identities (service accounts, users, or groups) can access the resource and what roles they have.
Example of an IAM policy:
json

{

                   "bindings": [

                    {

                     "role": "roles/storage.objectViewer",

                     "members": [

                      "serviceAccount:my-service-account@my-project.iam.gserviceaccount.com"

                     ]

                    }

                   ]

                  }

This policy grants the service account the ability to view objects in a specific Cloud Storage bucket.

Identity Federation and Workload Identity Federation
In some cases, GCP allows identity federation where external identities (such as AWS or on-premises services) can assume a role in GCP via an STS trust relationship.
- Workload Identity Federation allows external identities, such as those from AWS, Azure, or an on-premises identity provider, to authenticate and access GCP services without needing a GCP service account key.
- Instead of managing service account keys, external services exchange short-lived OAuth 2.0 tokens with GCP’s STS using a trust relationship. This mechanism is particularly useful in hybrid or multi-cloud environments.
Using Short-Lived Credentials
Just like in AWS and Azure, the tokens issued to service accounts in GCP are short-lived (usually one hour). Once the token expires, the application or service must request a new token from the Google token service to continue accessing resources.
The short-lived nature of these tokens provides additional security benefits, as tokens are only valid for a limited period, reducing the risk of long-term credential exposure.

Example in Pictures

You can just assign a service account to a resource (In this case a Compute Engine instance) instead of using the creds within it.