iam

GCP: listing IAM roles for user, group, and service account in project and organization

When GCP operations fail due to permissions issues, checking the IAM roles assigned to a user, group, or service account becomes a necessity. When hierarchical projects and organizations are involved it becomes even more complex.  This article will show you how to use gcloud at the project and organization level to pull IAM policies for GCP: listing IAM roles for user, group, and service account in project and organization

GCP: running a container on a GKE cluster using Workload Identity

With Workload Identity enabled on a GKE cluster, your container can access Google Cloud API services (Compute Engine, Storage, etc.) using a Kubernetes Service Account (KSA). This is done by having the container run as the KSA, where the KSA has been bound to the Google Service Account (GSA).  This is the recommended way of GCP: running a container on a GKE cluster using Workload Identity

Terraform: Using non-authoritative resources to avoid IAM membership dependency web

One of the most challenging aspects of using Terraform is dealing with external changes and sprawl of dependent objects that may originate outside your control.  Terraform wants to be a system of record and have everything documented in its state as resource/data, however keeping your state in sync when other groups may be doing automation Terraform: Using non-authoritative resources to avoid IAM membership dependency web

GCP: Analyzing members of IAM role using gcloud filtering and jq

Although  the GCP console provides a nice interface for displaying which user/service account is in which IAM security role (IAM & Admin > IAM), it can be difficult to analyze using gcloud get-iam-policy because of the inner array of ‘members’ returned. However, if you use the flattening ability of gcloud, it becomes much easier to GCP: Analyzing members of IAM role using gcloud filtering and jq