iam-temp-delegation-review

Overview

This skill reviews IAM temporary delegation policy bundles (templates + boundaries) through a multi-stage pipeline. Stages are strictly gated — later stages do NOT run if earlier stages find critical issues.

Gotchas

• Pattern-matching a missing condition key is not enough to emit a finding. You MUST reason about whether the attack path is actually achievable with the permissions granted in this bundle. If the threat requires an action not present in the bundle, the finding is noise — not a vulnerability.
• Do NOT infer bundle metadata (partner domain, template name) from policy file content. These are registration-specific values — always ask the user.
• sar_context.json is the single source of truth for condition key support. IAM silently ignores unsupported condition keys — they parse but never enforce. Never recommend a key not listed in SAR data.
• Permission boundaries are pre-registered static policies. They do NOT support @{...} parameterization. Only delegation templates support placeholders.
• iam:TagRole does NOT support the iam:PermissionsBoundary condition key, even though it seems logical. The reviewer will suggest it — the verifier must catch it.
• Permission-only actions (empty resource_types in SAR) cannot be resource-scoped. Resource: "*" is correct and cannot be narrowed.
• aws:RequestTag only applies during creation/tagging. Using it on describe/modify actions always fails silently.
• The run_checks.py script prints registry artifact paths. Steps 4+ must use those paths, not the original input paths.
• Partners do NOT need iam:CreatePolicy for boundaries — IAM provisions them automatically. Flag it as a design error.
• Allow-overlap (Pattern 2) requires service-awareness. A boundary with * in the account field only creates exploitable overlap for cross-account-capable services (S3, Lambda layers, KMS via grants, STS). For account-local services (CloudFormation, CloudWatch, EC2, DynamoDB, RDS, Secrets Manager, CodeBuild), the API physically cannot reach resources in another account — * account scope is cosmetic, not a vulnerability. Flag account-local overlaps as low hygiene findings, not medium/high security findings.
• ArnEquals does NOT support wildcards — it treats * as a literal character. If a condition value contains * as a prefix/suffix pattern (e.g., arn:aws:iam::*:policy/Splunk*), the operator MUST be ArnLike. ArnEquals with wildcards silently never matches — a functional bug, not a security bug. The condition parses correctly but never evaluates to true, making the statement dead code.
• SAR lists aws:RequestTag/${TagKey} and aws:TagKeys for any action whose resource type supports tags — even if that specific API call has no tagging parameter in its request schema. A RequestTag condition on such an action is valid IAM syntax (the policy parses and deploys) but evaluates to null at runtime — creating a silent deny. When verifying whether an action can meaningfully be conditioned on aws:RequestTag, confirm the API actually accepts tag input (e.g., TagSpecification, Tags, TagList parameter). SAR answers "is this condition key valid in a policy for this action?" — not "will this condition key ever match at runtime?" The distinction matters for placement decisions (taggable vs. untaggable statement grouping) and for recommending RequestTag conditions on actions.
• Cross-artifact resource name alignment: For each named resource pattern in the boundary, determine its provenance — (1) created by this template, (2) pre-existing customer resource, or (3) created by another mechanism. If the boundary references resources that appear to be created by this template but the template's create scope doesn't cover the name pattern, flag as medium (design mismatch). If provenance is unclear, emit an info finding asking the author to clarify intent.