LEARN. PRACTICE. GROW.Follow identity through to effect
In a fictional reporting platform, a pipeline creates a function and chooses its execution role. The pipeline cannot directly read sensitive data, but the role it can pass has that access. Reviewing only the creator’s direct actions misses privileges delegated to runtime. Draw source identities, trust relationships, the operation receiving the role, and resulting service actions. For each link, ask who can change it and what evidence demonstrates use. The objective is to understand the authorization path without concluding that one isolated policy represents every effective permission in the system.
Apply limits in the correct scope
An SCP defines organizational limits; it does not grant access to a role lacking applicable grants. An applicable Deny is not overridden by additional identity Allow. Scope matters: SCPs do not affect management-account identities and do not restrict service-linked roles. A delegated-administrator member account remains within SCP scope. Do not generalize the exception to every role used by a service. Tests should use representative identities from affected accounts and consider inherited policies. In change review, distinguish business need, existing authorization, and a request to change the limit. An access failure does not justify indiscriminately removing the organizational restriction.
Bound delegation through PassRole
PassRole allows a role to be passed to a service; it is not the same as directly assuming it. Limit approved execution roles and, where applicable, the recipient through iam:PassedToService. Also confirm that those roles’ permissions match runtime work and trust accepts the correct service. The local exercise compares a proposal with an approved list of role-and-service pairs. It reviews intent rather than simulating IAM: it does not evaluate real policies, conditions, or grants. For audit, inspect the operation creating or modifying the resource, such as CreateFunction. PassRole is a permission and does not produce a separate API call with that name.
Preserve trust without relying on names
Trust directly referencing a role is associated with that role’s unique identity. Deleting and recreating it with the same name can leave an old principal ID in the policy. Confirm the new identity and update bounded trust instead of broadening Principal to meet a deadline. In OIDC-federated pipelines, check claims representing authorized origin. For GitHub, aud identifies the recipient and sub can restrict organization, repository, and branch in the format being used. If the workflow uses environments, their protections also belong in the design. A chosen session name does not replace verification of token origin and trust conditions.
Plan sessions and time limits
A session policy can reduce role permissions on the identity-policy path but cannot add actions the role does not allow. Exercises excluding resource grants use the stated intersection; do not carry that simplification into every direct session grant. Plan duration and renewal too. A session using AssumeRole to obtain another session through role chaining has a one-hour API limit even if the target role permits twelve. A long-running job needs a supported renewal mechanism or another authorized design. Test expiry during a controlled phase and retain identity and correlation across subsequent operations.
Relate authorization and cryptographic context
In KMS, the key-policy statement delegating to the account enables IAM to grant access; it does not distribute Decrypt automatically to every role. Check key policy, relevant grants, and actual identity before changing permissions. Encryption context is nonsecret metadata cryptographically associated with ciphertext and can appear in plaintext logs. Do not put passwords or sensitive data there. To decrypt data requiring context, supply the corresponding context; broad permissions do not correct a mismatch. The review summary should state who assumes, who delegates, which service acts, what data is in scope, and where operation evidence is retained.
# Original intention-review exercise, not an IAM policy evaluator.
approved = {("report-reader", "lambda.amazonaws.com"),
("batch-writer", "ecs-tasks.amazonaws.com")}
def review_delegation(role, service):
if (role, service) in approved:
return "within approved design; live authorization still requires validation"
return "outside approved design"
assert review_delegation("report-reader", "lambda.amazonaws.com").startswith("within")
assert review_delegation("administrator", "lambda.amazonaws.com").startswith("outside")
assert review_delegation("report-reader", "ecs-tasks.amazonaws.com").startswith("outside")
assert review_delegation("batch-writer", "ecs-tasks.amazonaws.com").startswith("within")
The pipeline only creates reporting resources but can choose an administrative role. Review follows privileges into the function and restricts approved role-and-service pairs.
Common pitfalls
SCP as a grant; delegated administrator as an exemption; role name as identity; PassRole as AssumeRole; encryption context as a secret store.
Related topics: Secrets, keys, and audit evidence
Access review must follow delegation, scope, and effective identity. One Allow or a familiar name does not establish correct authorization.
Reference: Organizations service control policies · DOP-C02