Prepare and test your skills
Prepare and test your skills
Identity Federation and Keyless Authentication lets workloads outside Google Cloud call Google Cloud APIs without storing long-lived service account keys. Workload Identity Federation (opens in a new tab) creates a short-lived trust relationship between Google Cloud and an external identity provider (IdP). The workload exchanges its outside credential for a short-lived Google token only when needed, so there is no downloadable key to store, rotate, or revoke.
Replacing service account keys with federation removes long-lived, copyable credentials from applications. Service account keys are powerful credentials that can be leaked and misused if they are not stored and rotated correctly. With federation, the application reuses the ambient credential its own platform already provides, and Google Cloud verifies that credential on each exchange before issuing a token that expires quickly.
Applications that already have ambient credentials are the best fit for federation. Ambient credentials are credentials a workload can obtain without extra login:
If the ambient credential is an OIDC token, SAML assertion, or AWS credential, it can be exchanged directly. If it uses another format such as Kerberos, an extra exchange through Active Directory Federation Services (AD FS) can first convert it to a JWT, which is then exchanged for a Google credential.
A workload identity pool (opens in a new tab) lets administrators manage external identities for Google Cloud Identity and Access Management (IAM). The pool does not contain user accounts like a directory; it provides a view that surfaces identities from external IdPs so they can be used as IAM principals. Create a separate pool for each non-Google Cloud environment that needs access, such as development, staging, or production.
A workload identity pool provider describes the trust relationship between Google Cloud and one external IdP. The provider stores the issuer URL, verification keys, attribute mappings, and conditions that define which outside tokens are accepted. Supported providers include AWS, Microsoft Entra ID, GitHub, GitLab, Kubernetes clusters, Okta, on-premises AD FS, and Terraform.
Exam tip: When federating with GitHub or Terraform Cloud, always add an attribute condition for the trusted organization, because those platforms share one issuer URL across all tenants and issuer verification alone cannot prove the tenant.
Token exchange is how a workload turns an external credential into a short-lived Google credential. Security Token Service (STS) (opens in a new tab) is the Google service that verifies the outside credential and issues the federated token, following the OAuth 2.0 token exchange specification.
google.subject and group or custom attributes, and checks any attribute condition.For data residency needs, the workload can send the exchange to a regional STS endpoint such as https://sts.REGION.rep.googleapis.com instead of the global https://sts.googleapis.com endpoint.
Attribute mappings define how claims in the external token become attributes in the Google STS token. The mapping format is TARGET_ATTRIBUTE=SOURCE_EXPRESSION, where the source expression uses Common Expression Language (CEL) to read claims from the outside token.
google.subject is required, uniquely identifies the workload, appears in IAM bindings and Cloud Logging, and cannot exceed 127 characters.google.groups is optional and carries group memberships used in principalSet:// bindings for granting access to all members of a group.attribute.NAME is optional, supports up to 50 custom attributes, and is used in principalSet:// bindings to grant access to identities sharing an attribute.An attribute condition is an additional CEL check that restricts which tokens can complete the exchange. Conditions are essential for multi-tenant IdPs where one issuer serves many customers, and for X.509 federation (opens in a new tab) where a condition such as assertion.san.uri=="spiffe://example/path" limits exchange to one SPIFFE ID. Choose immutable and non-reusable claims for mappings, such as workload IDs or tenant IDs that cannot be reassigned, and avoid display names or emails that can change.
Access for federated identities is granted with IAM roles using either direct resource access or service account impersonation. Direct access grants roles to the federated principal itself, while impersonation lets the federated principal act as a Google service account that already has access.
| Access model | What receives the IAM role | Choose when |
|---|---|---|
| Direct resource access | Federated principal such as principal:// or principalSet:// | The workload needs access to specific resources and audit logs should show the external identity directly |
| Service account impersonation | Google service account, with the federated principal granted permission to impersonate it | Existing applications already use service accounts, or many workloads should share one managed identity |
Harden access by using a dedicated service account for each application and keeping that service account in the same project as the resources it accesses. Do not grant roles to all members of a pool with a wildcard principalSet:// identifier for workload pools, because every identity the IdP can authenticate would gain access and growth of the IdP would cause over-permissioning.
Hardening the trust relationship protects the pool and provider configuration from spoofing, privilege escalation, and loss of traceability. A workload identity pool is an organization-level trust anchor, so its configuration controls which external identities can become IAM principals across projects.
google.subject.Secret Management and Lifecycle Automation is the practice of storing sensitive configuration data centrally and controlling how it is accessed, distributed, and replaced. Secret Manager (opens in a new tab) serves as the central certificate store where certificates and credentials are centrally managed, versioned through add, update, and delete operations, and accessed through the Secret Manager API. MQTT brokers depend on that central store for certificate-based authentication, so changes in Secret Manager must be synchronized to the broker store and securely distributed to edge devices.
Central storage and access control in Secret Manager keeps root certificates, client certificates, and credentials for IoT workloads in one managed store. Access to the store is governed by access policies that define who can read, update, or invalidate device credentials, and backend workloads use Secret Manager API access to retrieve secrets. For device access, the system can generate short-lived access tokens that grant restricted, temporary access to specific certificates. Automated rotation with finite validity periods then limits how long an exposed certificate can be abused.
Synchronization keeps the central certificate store and the MQTT broker certificate store consistent so brokers can authenticate clients. The MQTT broker certificate store may be MySQL, PostgresDB, or Java Key Store, and every add, update, and delete in the central store must be reflected there. The flow depends on two processes: a monitoring process that watches the central store and notifies listeners of changes, and a synchronization process that applies those changes to the broker store. When Secret Manager is the central store, event notifications act as the monitoring process and a listener implements the synchronization process.
Secure distribution moves certificates from the central store to edge devices without interception. Secure distribution uses a certificate store, a distribution coordinator, and an on-device update handler:
Distribution uses a direct path from the IoT backend to the device during provisioning and an indirect path where devices request and download certificates during rotation. During provisioning, the provisioner pushes certificates directly over encrypted channels such as SSH using tools such as SCP because the devices are not yet in operation. During rotation, the MQTT broker carries coordination messages while downloads use other channels, and the connection between edge devices and the MQTT broker is encrypted to prevent exposure in transit.
For in-operation devices, indirect distribution minimizes disruption through an ordered handoff:
Automatic rotation replaces certificates before they expire so devices never lose valid credentials and stop functioning. Certificates are issued with a finite valid period, and large-scale deployments rely on automation to update devices consistently. Rotation requires bidirectional connectivity so edge devices can both send messages to the MQTT broker and receive messages from it.
Three components cooperate during rotation:
The IoT solution completes rotation in order:
To protect rotation traffic, the system uses dedicated MQTT topics limited to only the rotation job and the edge device and enables persistence for changes and progress to survive runtime failures.
Exam tip: Invalidate the old certificate in the central store only after the device has established a new connection and sent a completed message, not immediately after distributing the new certificate.
Cryptographic key management in Google Cloud is the practice of controlling the keys that protect data at rest through Cloud Key Management Service (Cloud KMS) (opens in a new tab). Envelope encryption is the pattern where a symmetric key encryption key (KEK) stored in Cloud KMS protects the data, and Cloud KMS performs the encrypt and decrypt operations on behalf of the integrated service. With customer-managed encryption keys (CMEK) (opens in a new tab), you own and manage that KEK instead of Google.
Google default encryption compared with customer-managed keys differs in who owns the KEK and what controls are available, while day-to-day access to the data stays similar. Google default encryption means Google owns and manages the symmetric KEKs that protect your data with no action from you. CMEK means you create the key ring and key in Cloud KMS and the CMEK-integrated service calls Cloud KMS to protect data at rest.
CMEK gives you control over protection level, location, rotation schedule, usage and access permissions, cryptographic boundaries, audit logs, and key lifecycle. Knowledge Catalog uses one CMEK per location for all resources in that location, configured at the organization level, and the key location must match the resource location.
| Option | Key owner | Control and visibility |
|---|---|---|
| Google default encryption | Google owns and manages the KEK | No key setup; access works automatically |
| Customer-managed encryption keys (CMEK) | You own and manage the KEK in Cloud KMS | You control rotation, permissions, boundaries, audit logs, and lifecycle; service use requires IAM on the key |
After you configure CMEK, access to the protected resources feels the same as Google default encryption because the service handles calls to Cloud KMS for you.
Envelope encryption with Cloud KMS keeps the KEK inside Cloud KMS while protected data lives in the integrated service. Data flows from the service to Cloud KMS for encrypt and decrypt operations, and the KEK never leaves Cloud KMS ownership when you use CMEK. The service depends on a Google-managed service account to reach the key, so you must grant that service account the Cloud KMS CryptoKey Encrypter/Decrypter role (roles/cloudkms.cryptoKeyEncrypterDecrypter) on the specific key.
Enabling CMEK follows an ordered dependency:
roles/cloudkms.cryptoKeyEncrypterDecrypter.Services do not call Cloud KMS on every data request; some maintain a poller that checks the key periodically, and those checks appear in Cloud Logging as Encrypt and Decrypt audit entries. If the service account loses permission, requests fail with permission-denied errors, and if KMS quotas are exceeded, operations fail until quota is increased.
The lifecycle of customer-managed encryption keys controls whether protected data remains accessible, and rotation is the safe update path. Rotation creates a new key version in Cloud KMS, and the service automatically uses the new version for encryption while existing data is also protected with the new version. Switching to CMEK is irreversible in services such as Knowledge Catalog, and after a key is configured it cannot be updated or changed to a different key.
Key states move in order from enabled to disabled to scheduled for destruction to destroyed, with different consequences:
Exam tip: Disabling a key causes immediate inaccessibility but can be re-enabled, while destroying a key causes permanent data loss — if the key stays unavailable for more than 30 days, the service automatically deletes the encrypted data.
Short KMS outages are handled on a best-effort basis for up to one hour, after which data becomes temporarily inaccessible as a protective measure. Backups created after CMEK is enabled are encrypted with the CMEK key, while pre-CMEK backups remain under Google default encryption for a maximum of 15 days.
Enforcing CMEK with IAM and organization policy decides which service can use which key and whether CMEK is required. IAM applies to the key, where the key administrator grants roles/cloudkms.cryptoKeyEncrypterDecrypter to the service account and to the administrator configuring encryption. The trust boundary sits at the key: the service project holds the data, the key project holds the KEK, and no decrypt can occur across that boundary without the IAM grant.
Organization policy applies above individual resources to enforce compliance:
constraints/gcp.restrictNonCmekServices set to Deny for a service requires CMEK protection, so resource creation without a key fails.constraints/gcp.restrictCmekCryptoKeyProjects set to Allow limits which projects, folders, or organizations can supply the KEK, so keys from disallowed hierarchies fail validation.Choose Deny on the first constraint when regulation requires customer control of all keys, and choose Allow lists on the second constraint when keys must stay in central security projects.
Google default encryption means Google owns and manages the symmetric key encryption keys that protect data with no action from you, while customer-managed encryption keys (CMEK) means you own and manage the key encryption key in Cloud Key Management Service (Cloud KMS). CMEK gives you control over protection level, location, rotation schedule, usage and access permissions, cryptographic boundaries, audit logs, and key lifecycle, while access to protected resources feels the same because the integrated service handles calls to Cloud KMS for you.
Use direct resource access when the workload needs access to specific resources and audit logs should show the external identity directly, because the IAM role is granted to the federated principal such as principal:// or principalSet://. Use service account impersonation when existing applications already use service accounts or many workloads should share one managed identity, because the federated principal is granted permission to impersonate a Google service account that already has access.
The workload obtains its ambient credential from its own platform and sends it to Security Token Service (STS) along with the workload identity pool provider identifier. Security Token Service (STS) verifies the token signature and issuer, applies attribute mappings and checks any attribute condition, then returns a short-lived federated token that the workload uses for direct resource access or to impersonate a service account and call Google Cloud APIs.
Last updated