Epic: IAM effective-access — conditions, SCPs, boundaries, cross-account chains, fleet-wide reverse (v1.3)

[gnana997]

Summary

v1.1 surfaces show identity-side IAM grants: which pods inherit which roles, what those roles' policies grant, which workloads can perform action X. v1.3 turns the inventory into effective access: after SCPs, permission boundaries, conditions, and cross-account sts:AssumeRole chains. Closes the limits the v1.1 launch announcement named.

Why this is its own release

The launch announcement for v1.1 (discussion #70's successor, v1.1.0) named seven specific things v1.1 doesn't do: condition evaluation, SCPs + boundaries, cross-account chain walking, resource-based policies, fleet-wide reverse lookup, real-time IAM updates, OIDC trust validation. Of those, the five with the biggest operator-value-per-engineering-effort land here.

Sub-tasks (filed when work begins)

Anticipated breakdown — sub-task issues file ~2-3 weeks before each lands:

• aws-access — backend: condition evaluator (aws:RequestTag / aws:PrincipalTag / aws:SourceVpc / aws:SourceArn). The AWS Access tab gets a "condition: applies" / "condition: does not apply" badge per statement instead of just "condition not evaluated."
• aws-access — backend: SCP + permission-boundary retrieval from AWS Organizations (organizations:ListPolicies + organizations:DescribePolicy + per-role boundary read).
• aws-access — backend: effective-access composition (identity grants ∩ SCP ∩ boundary ∩ conditions) — the engine that says "policy grants X · SCP denies X · effective: denied".
• aws-access — backend: cross-account sts:AssumeRole chain walker with recursion guard + per-target-account credentials.
• aws-access — backend: fleet-wide reverse lookup endpoint (parallel per-cluster, partial-result UX when some clusters time out).
• aws-access — backend: CloudTrail-driven cache invalidation (subscribe to CloudTrail EventBridge → invalidate the IAM policy cache on Update*/Put*/Attach*/Detach* events).
• aws-access — frontend: AWS Access tab v2 (effective-access badges, condition-evaluated chip strip).
• aws-access — frontend: reverse-lookup v2 (per-cluster checkbox filter, "matches unconditionally" toggle, fleet-wide mode).
• aws-access — docs: usage/aws-access.md v2 + the v1.2 → v1.3 migration story.

Out of scope (v1.4 or later)

• Resource-based policy evaluation (S3 bucket policies, KMS key policies)
• OIDC trust policy validation ("IRSA configured but the provider broken" case)
• Custom condition operators or non-AWS-standard condition keys

Good places to start (when sub-tasks file)

• The condition evaluator is the foundation; everything else stacks on it. Start with a pure-Go condition matcher (input: condition map + request context; output: boolean + reasoning) that has zero AWS SDK dependencies. Then wire it into the engine.
• The SCP + boundary retrieval is bounded I/O work; good "first issue" for someone comfortable with AWS Organizations API.

References

• v1.1 IAM engine: internal/awseks/iam/ — read this first
• v1.1 launch post: https://periscopehq.dev/blog/v1-1-aws-access (specifically the "what v1.1 is honestly not" section)
• AWS condition keys: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html