---
title: "Cloud foundation and identity"
chapter: "04"
---

# 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.