Cloud foundation and identity

The safest cluster is still unsafe if the organization and identity foundation is weak.

Resource hierarchy

Google Cloud resources sit under organization, folders, and projects. Use folders for policy and ownership. Use projects as strong boundaries for IAM, billing, quotas, APIs, and failure. Separate production from non-production and consider dedicated networking, security, logging, and platform projects.

Two permission systems

Google Cloud IAM controls access to projects, GKE APIs, and Google Cloud resources. Kubernetes RBAC controls actions inside a cluster. A user may have permission to discover a cluster but not edit workloads—or the reverse through poor configuration. Design both paths together.

Workload identity

Use Workload Identity Federation for GKE so Pods obtain short-lived identities for Google Cloud APIs. Do not distribute service-account key files inside images or Kubernetes Secrets.

Boundaries

Give people group-based access, not individual permanent grants.
Use least-privilege IAM and namespace-scoped RBAC.
Separate platform administrators from application deployers.
Protect powerful Kubernetes groups such as system:masters.
Apply Organization Policy constraints and audit changes.
Centralize Cloud Audit Logs in a protected logging project.

Namespace warning

A namespace is useful for names, quota, RBAC, and policy, but it is not always a hard hostile-tenant boundary. Strongly untrusted tenants may require separate clusters or projects, depending on the threat model.