Configuring access

Cloud Identity and the identity foundation

Cloud Identity (Free or Premium) is the identity service that creates the users and groups Google Cloud sees. Google Workspace includes it. Every organization resource is tied to a Cloud Identity or Workspace domain, and the first verified domain creates the organization node.

Design rules that get tested:

• Users that exist only in the IdP must exist in Cloud Identity too. SSO authenticates, it does not create accounts. GCDS or SCIM does the creating.
• Suspend, don’t delete, on offboarding if you need to keep data and ownership. Deleting a user removes their data after a grace period. Transfer ownership first.
• Consumer (unmanaged) accounts with your corporate email addresses are a risk. Cloud Identity lets you find them and ask users to migrate them (transfer tool) so the organization controls them.
• Sync groups, not just users, and grant roles to groups. A leaver loses everything when removed from the group.

Super administrator accounts

The super admin can do anything in the Cloud Identity tenant and is the account of last resort. Practices to remember:

• Keep two to five, no more, as named dedicated accounts (not the same person’s daily mailbox).
• Use them only for tasks that need them. Daily admin work uses delegated admin roles.
• Protect with security keys (FIDO2) as the enforced 2-step verification method. Keep a break-glass procedure with credentials stored offline, and alert on every super admin sign-in with Cloud Identity audit logs.
• Super admins are normally kept out of SSO redirection so they can still sign in if the IdP is down. Give them Google credentials plus security keys.
• Super admins are not automatically Organization Administrators in IAM. The Google Cloud org policy and IAM layer is separate. Grant roles/resourcemanager.organizationAdmin deliberately and keep it small.

Workforce Identity Federation

Workforce Identity Federation lets employees, contractors and partners use their external identity (OIDC or SAML) to reach Google Cloud without creating Cloud Identity accounts. It is the answer when users must not be synchronised or when you need to federate many external IdPs.

• Create a workforce identity pool at the organization level, then add a provider (OIDC or SAML, with attribute mapping).
• Attribute mapping (CEL) maps assertion claims to google.subject, google.groups and custom attribute.* values. An attribute condition rejects tokens that do not match (for example a hosted domain).
• Grant IAM roles to principal://iam.googleapis.com/locations/global/workforcePools/POOL/subject/SUBJECT for one person or principalSet://.../group/GROUP or .../attribute.NAME/VALUE for many.
• Sign in to the console through the pool’s federated sign-in page. For the CLI, gcloud iam workforce-pools create-login-config and gcloud auth login --login-config. Sessions last 1 hour by default and can be set up to 12 hours.
• Not every product supports workforce principals, so check the product’s support list for odd cases.

Service accounts

A service account is an identity for software. It is both a principal (you grant it roles) and a resource (others get roles on it). Know which questions need one: a VM, Cloud Run service or pipeline that calls Google APIs. A person should never use a service account to sign in.

Types and defaults

Hardening default service accounts:

• Turn on the org policy iam.automaticIamGrantsForDefaultServiceAccounts so new default accounts do not receive Editor.
• Replace the Editor grant with narrow roles, and create dedicated service accounts for workloads. Don’t attach the default one.
• iam.disableServiceAccountCreation can lock down creation where a central team makes them.

Lifecycle and authorisation

• Create one per workload, descriptive name, in the project that owns the workload (or a dedicated identity project).
• Disable to stop a suspected compromise without losing the identity. Delete is reversible only for about 30 days (undelete), and role bindings referencing a deleted SA show as deleted:.
• Attach a service account to a VM, Cloud Run service, Cloud Function or GKE workload instead of using keys.
• Two permissions are distinct and heavily tested: iam.serviceAccounts.actAs (in roles/iam.serviceAccountUser) lets a principal attach the SA to a resource or run as it. Token Creator (roles/iam.serviceAccountTokenCreator) lets a principal mint tokens or sign blobs as the SA (impersonation). Granting either on a high-privilege SA is privilege escalation, so grant it on the specific service account, not the project.
• Roles on a service account (as a resource): serviceAccountAdmin, serviceAccountKeyAdmin, serviceAccountUser, serviceAccountTokenCreator, serviceAccountViewer.

Service account keys

Keys are long-lived credentials (a JSON file) that can be copied, leaked and never expire by default. The preferred order:

1. Attached service account (metadata server), no key.
2. Workload Identity Federation for non-Google workloads, no key.
3. Impersonation to produce short-lived tokens.
4. A key, only if nothing else works.

Controls to know:

If a key leaks: disable then delete the key, rotate, and review audit logs for usage. Google also scans public repositories (via the Cloud Platform Terms) for exposed keys and notifies you.

Short-lived credentials and impersonation

• Access tokens from the Service Account Credentials API (generateAccessToken) last 1 hour by default; up to 12 hours with the iam.allowServiceAccountCredentialLifetimeExtension policy listing the SA.
• ID tokens (generateIdToken) authenticate to Cloud Run, IAP or other OIDC audiences.
• signBlob and signJwt let a caller sign with the service account’s system-managed key without holding a key.
• Impersonation: a developer with Token Creator on the SA runs gcloud ... --impersonate-service-account=SA or sets it in Terraform. The developer’s own identity is logged, and the SA’s permissions are used. This replaces downloaded keys for CI and local work.
• Delegation chains let SA A impersonate SA B through intermediate accounts, each needing Token Creator on the next.

Workload Identity Federation

Workload Identity Federation lets a workload outside Google Cloud (AWS, Azure, GitHub Actions, GitLab, on-premises with OIDC, SAML, X.509 certificates) exchange its own credential for a short-lived Google token through the Security Token Service.

• Create a workload identity pool and a provider per external IdP. The provider type (AWS, OIDC, SAML) and attribute mapping set the identity.
• Attribute condition restricts who may exchange tokens, for example assertion.repository == 'org/repo' for GitHub. Without a condition, any workload in that IdP could try.
• Two access modes: direct resource access (grant roles straight to principal:// or principalSet:// identities of the pool) or impersonate a service account (grant workloadIdentityUser on the SA to the principal). Direct access is simpler; impersonation is needed for APIs that don’t accept federated principals.
• You generate a credential configuration file (not a secret) that client libraries use, instead of a key file.
• Org policies iam.workloadIdentityPoolProviders and iam.workloadIdentityPoolAwsAccounts restrict which external IdPs and AWS accounts may be trusted.
• Workload Identity Federation for GKE is the same idea for Pods. A Kubernetes service account maps to a principal .../PROJECT.svc.id.goog/subject/ns/NAMESPACE/sa/KSA that you grant roles to directly (or bind to a Google service account).

Managing authentication

Password and session policies are set in the Admin console for the Cloud Identity tenant:

• Password length (minimum 8, up to 100), strength enforcement, reuse prevention, expiration, and the option not to expire when 2-step verification is enforced. If SSO is used the IdP owns password policy.
• Session length for Google Cloud (reauthentication policy): require users to reauthenticate to the console and gcloud every N hours (1 to 24). Default is 16 hours. A “reauth” with a security key is possible. Service accounts are exempt, and so are apps with exemptions you configure.
• Google web session control is a separate setting for Workspace apps.

2-step verification (2SV):

• Enforce per organizational unit or group, with a new-user enrollment period (grace period).
• Choose allowed methods. The strongest is security keys only (FIDO2/passkeys, phishing-resistant). Phone prompts, authenticator apps and backup codes are weaker.
• Use Context-Aware Access to apply extra conditions on user sign-in (device, location).
• If SSO is in place, the IdP enforces its own MFA. You can still enforce Google 2SV for super admins and non-SSO users.

SAML and OAuth:

• SAML is for SSO into Google from an IdP (browser flows). Set up a SAML profile in Cloud Identity with the IdP’s sign-in URL and certificate, and assign it to OUs or groups.
• OAuth 2.0 is delegated authorisation for apps. Understand scopes, consent, and the OAuth consent screen (Internal limits an app to your organization). In Admin console API controls you mark third-party apps trusted, limited or blocked, and restrict which Google services unconfigured apps may access. Domain-wide delegation is high risk: it lets a service account impersonate any user for listed scopes, so limit scopes tightly and audit.

Authorization controls

Roles and separation of duties

Separation of duties examples: the person who administers keys (cloudkms.admin, cannot encrypt or decrypt) differs from the one who uses them (cryptoKeyEncrypterDecrypter). Network admin versus security admin versus log viewer. Billing admin versus project creator. Don’t give Organization Administrator and Security Admin to the same account when separation is required.

Allow policies, ACLs and conditions

• An IAM allow policy is a list of bindings (role, members, optional condition) attached to an organization, folder, project or resource. Limits include 1,500 principals per policy and 250 Google groups in a policy.
• Cloud Storage ACLs are the older object-level model. Enable uniform bucket-level access so only IAM applies, and turn on public access prevention. Fine-grained ACLs per object are for legacy cases only.
• IAM Conditions use CEL: time windows (request.time), resource name or type, resource tags, and request attributes such as access levels. Conditions need policy version 3. Not every role/service supports conditions, so check the list.
• Temporary access pattern: a conditional binding with request.time < timestamp("2026-12-01T00:00:00Z").

Deny policies

IAM deny policies block principals from specific permissions, regardless of any allow. Deny is evaluated first.

• Attached at the organization, folder or project, in a separate policy kind (iam.googleapis.com/.../denypolicies).
• Rules list denied principals, denied permissions (in the form service.googleapis.com/resource.verb), optional exception principals and optional denial condition (CEL, for instance on a resource tag).
• Use them for guardrails that must hold even if someone is granted a role by mistake, such as “nobody except the security team can delete log buckets or change IAM”. Evaluation order is: deny policies, then allow, and organization policies are a separate check.

Hierarchy-based access

Grant at the lowest level that works. Allow policies are additive and inherited downward (union of all levels). A child cannot remove a role inherited from the parent. Only a deny policy can. Grant roles to groups, and manage group membership as code. Use Google Groups as the unit and tag them with security labels for the groups you can use in IAM.

Access Context Manager

Access Context Manager defines access levels from attributes of a request. Basic levels combine conditions (IP ranges, regions, device policy, members) with AND/OR. Custom levels use CEL. An access policy (one per organization, or scoped to folders/projects) holds levels and perimeters.

Access levels are used by:

• VPC Service Controls ingress rules and perimeters.
• IAM conditions (request.auth.access_levels), for context-aware allow.
• Identity-Aware Proxy and Context-Aware Access for apps and the Cloud console.

Device attributes come from Endpoint Verification or Chrome Enterprise.

Policy Intelligence

Always simulate before enforcing a deny or removal.

Privileged Access Manager (PAM)

PAM provides just-in-time, time-bound, audited elevated access, a replacement for standing admin roles.

• An admin creates an entitlement: eligible requesters, the roles to grant, the maximum duration, whether justification is required, and who approves (or none).
• A user requests a grant with a justification. After approval, PAM adds a temporary IAM binding to the entitlement’s resource (organization, folder or project) and removes it at expiry.
• Notifications go to approvers; every request, approval, grant and revocation is audit logged.
• Use cases: break-glass for production, on-call engineers, contractors, any “no standing privileged access” requirement. It differs from a plain IAM condition because it adds approvals and workflow.

Resource hierarchy and organization policies

Organization, folders, projects, then resources. Projects are the trust and billing boundary. Folders group projects by team, environment or regulation and carry policies for everything below.

Managing at scale:

• Create projects through automation (Terraform, Project Factory, Infrastructure Manager), with the roles resourcemanager.projectCreator and folderAdmin granted to a small team or pipeline.
• Use folders per environment/business unit, a few levels deep, to apply policies once.
• Protect critical projects with liens. A deleted project is recoverable for 30 days.
• Skip the default network with compute.skipDefaultNetworkCreation so projects do not start with the permissive default VPC.

Organization Policy Service

Organization policies are constraints on configuration, regardless of IAM. IAM says who can act. Org policy says what can be configured.

Frequently tested constraints:

• gcp.resourceLocations: where resources may be created.
• iam.allowedPolicyMemberDomains: only identities from approved domains in policies (stops granting to personal Gmail).
• compute.vmExternalIpAccess: which VMs may have external IPs. compute.requireShieldedVm, compute.requireOsLogin, compute.disableSerialPortAccess.
• storage.publicAccessPrevention, sql.restrictPublicIp.
• gcp.restrictNonCmekServices and gcp.restrictCmekCryptoKeyProjects: force and constrain CMEK.
• iam.disableServiceAccountKeyCreation, compute.trustedImageProjects, gcp.restrictServiceUsage.

The Organization Policy Administrator role (orgpolicy.policyAdmin) is separate from Organization Administrator. Org policy does not change existing resources retroactively. It blocks creation or change going forward, so audit existing ones too (Security Command Center or Cloud Asset Inventory).

Choosing between controls

Common traps

• A service account key is almost never the right answer. Look for attached SA, impersonation or federation.
• Granting serviceAccountUser or Token Creator at the project level lets the user act as every SA in it.
• Org policy does not grant anything and IAM does not block configuration. Pair them.
• Allow policies cannot subtract inherited access. Deny policies do.
• GCDS is one-way and does not provide SSO. SAML SSO does not provision users.
• Workforce federation is for people and Workload federation for software.