LEARN. PRACTICE. GROW.1. Draw the release authorization path
A fictional production team receives a pipeline that builds a batch processing application, publishes its image and prepares installation. The design includes people, repositories, triggers, execution accounts and runtime identities. Draw each transition with one question: who can make this action cause the next one? Restricted console read access does not necessarily prevent a user from starting an execution that uses a more privileged account. The review must include control over code, configuration, triggers and identities, alongside direct resource access. For a technical manager, this diagram supports concrete assignments. Development controls source and review; the platform team configures identities; APS confirms delivery and investigation procedures. Record which relationships were checked and which depend on configuration not yet observed. Avoid concluding that a temporary credential makes every path safe. Its lifetime limits the usage window, but the credential may still represent an overly broad origin or an account with excessive permissions. Acceptance should identify the capability granted and why it is needed.
2. Restrict a federated identity’s origin
A shared GitHub issuer does not identify the authorized organization by itself. The provider condition must limit claims to the intended origin. In this lesson’s example, organization ID is 73190, repository ID is 845210 and the allowed branch is refs/heads/main. These three conditions are cumulative. A token from another repository in the same organization does not pass merely because it comes from main. A token from the correct repository on another branch also fails the rule. Attribute mapping and conditions must match claims actually issued by the provider. Use stable IDs to distinguish entities when names can be reused. A repository display-name change should not be confused with creation of a new entity using the old name. Before changing configuration, compare positive and negative cases: approved origin, wrong owner, wrong repository and wrong branch. Signature, issuer, audience and token lifetime validation remain necessary. An expression over claims does not replace them. The numbers used here are fictional and represent no real accounts or repositories.
3. Separate impersonation, access and execution
Obtaining a token through impersonation demonstrates a relationship between the federated identity and service account. It does not prove that the account can read a bucket or modify a service. If impersonation works but a resource permission is missing, investigate that layer. Broadening access to the entire pool does not fix the read and may admit additional origins. Define the staging account and resources it genuinely needs; document how production differs. Dedicated pipeline accounts help separate privileges and reconstruct actions. The path continues through the identity attached to the resource. If a pipeline can deploy arbitrary code and attach runtime-prod, that code can operate with the account’s permissions. Lack of direct author read access does not eliminate indirect access. The review must combine code control with iam.serviceAccounts.actAs and runtime privileges. In Cloud Build, a trigger using the legacy service account can execute a step that accesses a secret authorized for that account. Recording the initiator helps auditing but does not itself reduce the capability granted to the build.
4. Distinguish build and runtime secrets
A token used to download a dependency during construction has a different lifecycle from the credential the application uses after startup. For BuildKit, use the appropriate secret-mount mechanism and avoid carrying the secret value in build arguments. There is a less obvious consequence: rotating secret contents does not invalidate that step’s cache. If the objective is to repeat a download, control caching explicitly or use a suitable nonsecret marker. Do not put the new value in an argument merely to trigger another execution. In Cloud Run, distinguish environment-variable consumption from volume consumption. The former resolves the value at instance startup. A volume read can fail during execution if the secret is inaccessible. Successful startup does not guarantee future availability. Combine investigation of secret version, access and state with the application’s error handling. In this exercise, no values need to be printed to diagnose these relationships. Record version identifiers and authorized access outcomes while keeping secrets out of logs and operational reports.
5. Plan rotation through to consumers
A SECRET_ROTATE notification tells a process that the scheduled time has arrived; it does not itself change an external system’s password. Identify the consumer that performs rotation, its required authorization and how the outcome is confirmed. The process may need to create a new credential at the source system, store a new version, update consumers and retire the previous version. The actual order depends on support for overlapping credentials and the system’s recovery conditions. Do not impose a universal sequence unsupported by the product. In a fictional operational window, the main application changes version while a weekly batch process keeps using the old credential. The team discovers this only after retiring it. Use this risk to prepare a consumer inventory and trials covering infrequent tasks. Define who confirms adoption, when overlap ends and how failure is handled. A received notification, created version and updated consumer are different pieces of evidence. The report should identify which exists without declaring rotation complete merely because a message reached its topic.
6. Verify artifact origin and currency
Provenance must be authenticated and bound to the artifact being examined. Then compare approved expectations: builder, canonical source and relevant build parameters. A valid signature from a trusted builder may honestly describe a build from an unauthorized fork. In that case, evidence is authentic but fails package policy. Changing a tag does not correct the source. The SLSA reference used in this lesson is v1.2 verification guidance, with its scope recorded in the sources. Vulnerability analysis answers a different question and depends on current data. A recovery image stored for weeks can retain identical bytes while new dependency risks become known. In Artifact Analysis, updates stop for images without pulls in the last 30 days. Pulling an image with stale metadata reactivates analysis, but refresh may take up to 24 hours. Confirm the result before presenting it as current. If you replace the artifact to resolve its source, collect evidence for the new digest; the previous report does not automatically cover that replacement.
7. Guided evidence-reading exercise
The displayed JSON record is a fictional teaching inventory, not an IAM policy, attestation or deployable service file. Signature and digest fields represent assumed observations for the exercise; writing true does not verify cryptography. Case A has authentic provenance but a source mismatch. Case B satisfies source requirements and has current analysis, but its admission rule uses dry-run. Case C has evidence consistent with the listed conditions. Decide the specific problem in each case before consulting the answers. For A, request a build matching the approved source and bind evidence again to the resulting artifact. For B, successful installation does not demonstrate that an unsuitable image would be blocked: dry-run permits observing violations. For C, proceed to the next operational review, but this inventory demonstrates neither functional tests nor recovery capability or external approvals. Justify each conclusion in one English sentence. Then change a single field and explain which evidence needs collecting again. The objective is to locate a concrete gap, avoiding turning a collection of positive fields into universal approval.
8. Manage exceptions and return the service to RUN
During an incident, an authorized emergency procedure may permit an exception. Distinguish that decision from normal promotion. In GKE, breakglass use generates an audit event even if the image satisfies policy. If internal procedure requires exception review, image compliance does not erase use of that path. Record the rationale, owner, available evidence and action for returning to normal operation. Do not remove the entire policy to hide an exception or simplify its follow-up. In the final case, the recovery image comes from an unauthorized fork and its analysis is old. Normal promotion requires resolving both gaps. If an emergency prevents waiting, the decision must follow the authorized process with explicit risks, without claiming controls passed. At handover, provide APS with instructions for locating provenance, confirming analysis, investigating secret access and recognizing exceptions. Summarize the lesson through four relationships: identity origin, execution privileges, secret consumption and artifact evidence. Each relationship needs an owner and a verifiable way to demonstrate the outcome.
{
"kind": "fictional-evidence-inventory",
"notAProviderConfiguration": true,
"cryptographicVerificationPerformed": false,
"expectedSource": "central/app",
"cases": [
{
"id": "A",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "sandbox/app-fork",
"scanFresh": true,
"enforcement": "ENFORCED_BLOCK_AND_AUDIT_LOG",
"decision": "hold-source-mismatch"
},
{
"id": "B",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "central/app",
"scanFresh": true,
"enforcement": "DRYRUN_AUDIT_LOG_ONLY",
"decision": "blocking-not-demonstrated"
},
{
"id": "C",
"signatureAssumedValid": true,
"digestAssumedMatched": true,
"source": "central/app",
"scanFresh": true,
"enforcement": "ENFORCED_BLOCK_AND_AUDIT_LOG",
"decision": "continue-operational-review"
}
]
}A recovery image has authentic provenance but an unauthorized source and old vulnerability analysis.
Common pitfalls
Trusting only the issuer, confusing impersonation with resource access, treating notification as completed rotation and a signature as universal approval.
Related topics: IAM and identity federation · Change management and incident response · Provenance, scanning and operational acceptance
Delivery needs an authorized origin, scoped privileges and current evidence bound to the artifact that will actually be installed.
Reference: Configure Workload Identity Federation with deployment pipelines · Current linked guide; edition date unconfirmed (2026-09-30 inspection)