GCP IAM and Service Accounts

Google Cloud IAM is a unified access control system that allows administrators to authorize who can take what action on which resources. Before IAM, GCP used legacy access control lists (ACLs) on individual resources, which were tedious to manage and did not scale. IAM provides a consistent, fine-grained, and hierarchical permission model across all GCP services.

IAM is built on three core components: - Members: Identities such as Google accounts, Google Groups, service accounts, or G Suite/Cloud Identity domains. Members can be authenticated users (human), applications (service accounts), or even all authenticated users or the public. - Roles: A collection of permissions. A permission is a named action that can be taken on a resource (e.g., compute.instances.start). Roles can be predefined (created by Google), custom (user-defined), or basic (legacy Owner/Editor/Viewer). - Policies: Bindings that associate a list of members with a role, applied to a resource or a hierarchy node (organization, folder, project). Policies are expressed in JSON or YAML format.

When a request is made to a Google Cloud API (e.g., gcloud compute instances list), the following steps occur:

{
  "bindings": [
    {
      "role": "roles/compute.instanceAdmin.v1",
      "members": [
        "user:alice@example.com",
        "serviceAccount:my-sa@project.iam.gserviceaccount.com"
      ]
    }
  ]
}

- Members: Members are specified using prefixes: - user: for Google account emails - group: for Google Groups - serviceAccount: for service accounts - domain: for G Suite/Cloud Identity domains (e.g., domain:example.com grants access to all users in that domain) - allAuthenticatedUsers: any authenticated user (including users outside your organization) - allUsers: any user, including unauthenticated (public)

gcloud projects get-iam-policy PROJECT_ID

gcloud projects set-iam-policy PROJECT_ID policy-file.json

gcloud projects add-iam-policy-binding PROJECT_ID --member='user:alice@example.com' --role='roles/compute.instanceAdmin.v1'

gcloud projects remove-iam-policy-binding PROJECT_ID --member='user:alice@example.com' --role='roles/compute.instanceAdmin.v1'

gcloud iam simulate --project=PROJECT_ID --permissions='compute.instances.list' --principal='user:alice@example.com' --resource='//compute.googleapis.com/projects/PROJECT_ID'

gcloud iam service-accounts list

gcloud iam service-accounts create SA_NAME --display-name='My Service Account'

gcloud iam service-accounts keys create key-file.json --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com

A service account is a special type of Google account that belongs to an application or a virtual machine, not to an individual user. Service accounts are used to authenticate application-to-API calls. There are two types:

Service accounts can be used in two ways:

Service accounts are both identities and resources. As an identity, they can be granted IAM roles to access other resources (e.g., a service account can have roles/storage.objectViewer on a Cloud Storage bucket). As a resource, they can have IAM policies that control who can use them (e.g., who can iam.serviceAccounts.actAs to impersonate the service account). The roles/iam.serviceAccountUser role allows a user to impersonate a service account (e.g., to deploy resources that run as that service account). The roles/iam.serviceAccountAdmin role allows managing the service account itself (create, delete, manage keys).

A large e-commerce company runs a microservices architecture on Google Kubernetes Engine (GKE). Each microservice needs to access specific GCP resources: one service writes to Cloud Pub/Sub, another reads from Cloud SQL, and a third uploads files to Cloud Storage. The security team wants to enforce least privilege. They create a separate service account for each microservice and grant only the necessary roles. For example, the Pub/Sub writer service account gets roles/pubsub.publisher on the relevant topic. The service accounts are attached to the GKE nodes or pods using Workload Identity, which allows pods to impersonate service accounts without keys. This setup ensures that if one microservice is compromised, the attacker cannot access resources meant for other services. In production, they monitor IAM policy changes with Cloud Asset Inventory and set up alerts for any modifications to service account roles. A common misconfiguration is granting roles/owner or roles/editor to a service account, which violates least privilege and can lead to accidental deletion of resources. They use custom roles when predefined roles are too broad.

A company has multiple GCP projects: one for data ingestion (project-ingest), one for data processing (project-process), and one for data visualization (project-viz). The processing project needs to read data from the ingestion project's Cloud Storage bucket and write results to the visualization project's BigQuery dataset. They create a service account in the processing project and grant it roles/storage.objectViewer on the ingestion bucket and roles/bigquery.dataEditor on the visualization dataset. This cross-project access is configured by adding the service account as a member in the IAM policy of the target project. They must ensure that the service account is not over-permissioned; for example, they avoid granting roles/storage.admin which would allow deleting the bucket. A common pitfall is forgetting that IAM policies are evaluated at the project level, so granting a role at the project level gives access to all resources of that type in the project. To restrict access to a specific bucket, they use resource-level IAM policies. They also enable VPC Service Controls to prevent data exfiltration. Performance is not an issue because IAM decisions are cached and typically take under 100ms.

A company needs to give a third-party vendor access to a specific Cloud Storage bucket to upload log files. The vendor uses their own GCP organization. The company creates a service account in their project and shares the service account email with the vendor. However, the vendor cannot use the service account because they don't have the private key. Instead, the company uses workload identity federation: they configure an OIDC identity provider in their project that trusts the vendor's identity provider (e.g., their Okta tenant). The vendor's application obtains a token from Okta, then exchanges it for a Google Cloud access token via the STS endpoint. This allows the vendor to access the bucket without managing keys. The company grants the vendor's federated identity (e.g., principalSet://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/my-pool/attribute/email/vendor-app@vendor.com) the role roles/storage.objectCreator on the bucket. This setup is more secure than sharing service account keys, which could be leaked. Misconfiguration often occurs when the OIDC provider is not set up correctly, causing token validation failures. The company must ensure that the vendor's token includes the expected claims (e.g., sub, aud) and that the attribute mapping in the workload identity pool is accurate.