LEARN. PRACTICE. GROW.Turn requirements into access paths
Start with what a person or service should be able to do, to which data and under which conditions. In this lesson’s fictional portal, every download must check the identity of an authorized employee. Write down the complete path: browser, protected ingress, backend, object read and content delivery. Add alternate paths such as a direct backend address and a link shared outside the session. This representation helps define positive and negative tests before implementation. A login on the landing page is only an observation about one point along the path. Acceptance must also consider what happens after logout, with an expired token, with an unauthorized user and through alternate ingress. For every rehearsal, identify configuration, effective principal, resource, operation and expected result. Together these form technical evidence for the agreed requirement, rather than automatic certification of compliance.
Review identity when infrastructure changes
An administrative change can alter authorization without changing code. Before moving a project between folders, compare source and destination inheritance as well as directly attached bindings. In reporting handover, RUN needs the permissions required to observe and recover the service. Avoid copying broad roles merely to make errors disappear: map approved operations and test them with the identity that will actually be used. For clusters, include the Workload Identity Federation identifier too. Two clusters in the same project can produce the same principal when they use the same namespace and ServiceAccount. Visually separate clusters do not establish isolation when calling a Google API. Document the trust boundary between teams, who can create those names and which restrictions make access specific. When the requirement is environment separation, validate that boundary in both identity architecture and workload-creation governance.
Guided exercise: find the grant that remains
Read the JSON excerpt at the end of the lesson. It is an original partial policy for interpretation, not a configuration to apply to a bucket. Version 3 can represent the condition. The RUN group appears twice with the same read role: once without a condition and once with a time limit of 22:00Z on October 8. Predict the outcome at 21:59Z, 22:00Z and 23:00Z, assuming no other blocks. At all three times, the unconditional grant remains available. The expression’s strict comparison makes the time condition false at 22:00Z, but does not cancel the other binding. For a second exercise, mentally remove the unconditional binding: within this simplified scope, the window ends at 22:00Z. In a real change, also investigate inherited grants and additional groups, preserve the etag during the update and test again after propagation. This reading exercise executes no IAM operations and does not replace those tests.
Plan the credential lifecycle
Distinguish the identity, the key and the credential presented on a request. Permission to attach a service account to a resource is not automatically permission to mint an access token through impersonation. This distinction helps resolve pipeline failures without distributing persistent keys. During an incident, the same precision prevents announcing containment before demonstrating it: disabling a key does not itself revoke short-lived tokens already issued from it. The plan should inventory workloads sharing the account, recovery capability and the decision about broader containment. In parallel, prepare encrypted-data recovery. A new KMS version does not mean old data now uses it. Keep a record of required versions, access-removal owners and recovery rehearsals. A decision to remove a cryptographic dependency should rely on that inventory and read evidence, including data that is rarely accessed. Record what the team has actually demonstrated and which paths still need investigation before closing the incident.
Keep data and metadata within intended scope
For a CMEK-protected object, trace the chain between reader, storage service and key. Missing service-agent permission is not corrected by giving the human operator more privileges. Separate object authorization from the service’s cryptographic operation and use the identity named in the error to guide investigation. Review names and metadata as well as content: avoid putting a customer’s name in an object path as if the CMEK also hid it from anyone allowed to list objects. When migrating to uniform bucket-level access, inventory consumers relying on individual ACLs. Reproducing that access with a role across the whole bucket can inadvertently broaden scope. The same reasoning applies to analytics: an authorized view omitting a column does not resolve an independent grant to read the source table. For each design, document the required read, the prohibited read and evidence for both.
Rehearse the portal through the final download
In this lesson’s case, rehearsal finds two independent problems. First, the backend accepts an email header without validating identity. The solution requires verifying the IAP JWT with a suitable library, including signature, issuer, audience and time, and restricting the path bypassing protected ingress. Second, the application issues a signed URL that works outside the session. That behavior does not meet the requirement for employee authentication on every download. Shortening validity only narrows the window; choose a path that applies the intended control while delivering content. Retest both problems after correction because resolving one does not demonstrate resolution of the other. For Cloud Run applications using Armor at the load balancer, also add the default URL to the test matrix. A load-balancer rule supplies evidence only about requests traversing it; alternate ingress requires its own treatment and dependency assessment.
Interpret results without broadening the conclusion
A data inspection should state what was actually examined. In the example of 1200 rows out of two million, zero findings applies to the sample and detection configuration. Record fields, filters, observation time and limitations before planning broader coverage. Data transformation also needs an accurate description: reversible AES-SIV tokens can still be recovered by someone holding the key and other required elements. If the test team should lack that capability, address reversal permissions explicitly. In observability, a sink exclusion decides routing for the entire entry rather than removing a sensitive field. Avoid emitting secrets while retaining attributes needed to investigate the transaction. Finally, a muted finding is not a remediated vulnerability. Review should connect resource state, approved exception, owner and next assessment date instead of relying only on the dashboard’s default view. These distinctions let a reviewer identify the next concrete action from the evidence.
Close acceptance and prepare support
The handover package should let RUN understand who has access, how to recover legitimate access and how to contain inappropriate access. Include the path matrix, negative tests, key dependencies and time-bounded exceptions. If the process includes Google personnel accessing customer data, distinguish Access Transparency records from the Access Approval workflow and confirm covered services and exclusions. Assign who responds to a request so approval is not left without an owner during an incident. A useful update for the portal committee is: “The normal login path works, but two download paths do not meet the agreed identity requirement. Acceptance is pending correction and a repeat rehearsal.” Connect that conclusion to owners and dates, and present partial-delivery alternatives when useful to the business. Summarize the lesson by checking four elements: effective identity, alternate paths, credential dependencies and the precise reach of the evidence.
{
"version": 3,
"bindings": [
{
"role": "roles/storage.objectViewer",
"members": [
"group:run@example.invalid"
]
},
{
"role": "roles/storage.objectViewer",
"members": [
"group:run@example.invalid"
],
"condition": {
"title": "release-window",
"expression": "request.time < timestamp('2026-10-08T22:00:00Z')"
}
}
]
}
A successful login does not establish identity on every download when the backend accepts unvalidated headers and documents are delivered through forwardable URLs.
Common pitfalls
Confusing a time-bound grant with global revocation, rotation with re-encryption, filtering with remediation, signed URLs with holder identity and zero sample findings with absence of sensitive data.
Related topics: Effective policies and audit evidence · Data migration and reconciliation · Change acceptance and RUN autonomy
Validate each path and identity, preserve evidence of denied access and limit conclusions to what was actually observed.
Reference: Move a project · Current linked standard guide; edition date unconfirmed (2026-09-30 inspection)