iam-ape: resolve principal-based deny conditions (ARN/account/tag) (CIEM-685)

[yanas-orca]

Problem

iam-ape does not evaluate IAM conditions — it carries them symbolically. A conditional deny is treated as a partial deny: the action stays in the effective allow-set (with the condition merged in) rather than being removed. Only an unconditional deny fully removes an action.

That's correct for request-context conditions a static evaluator can't know (region, MFA, source IP, resource tags, time). But conditions keyed on the principal — aws:PrincipalARN, aws:PrincipalAccount, aws:PrincipalTag/* — are decidable at evaluation time, because ape evaluates per-principal and holds the principal's entity object.

Impact (CIEM-685): customer root SCPs deny bedrock:Create/Update/DeleteGuardrail conditionally — e.g. ArnNotLike aws:PrincipalARN […SSO admin roles], and a second SCP with StringNotEquals aws:PrincipalAccount […] AND ArnNotLike aws:PrincipalARN […]. Because the denies are conditional, ape leaves the guardrail actions in a non-exempt role's effective allow-set, so the "unauthorized guardrail management" alert keeps firing even though the role is denied those actions in the cloud.

Fix

Resolve deny conditions built only from known principal facts against the evaluated principal:

• aws:PrincipalARN, aws:PrincipalAccount (parsed from the ARN), aws:PrincipalTag/<k> (from the principal's Tags).
• Operators: ArnLike/ArnNotLike/ArnEquals/ArnNotEquals + String* equivalents.
• Resolution outcome per statement: applies → enforce as an unconditional deny; doesn't apply → drop; undecidable (any non-principal key like region/MFA, an unmodeled operator, or an absent tag) → keep symbolic (unchanged behavior).

Why resolve before expansion

The policy expander splits a multi-operator Condition block into independent single-operator deny entries (expand_policy._append_action). Resolving after expansion would treat A AND B as two separate denies and could strip an action based on one clause alone — wrongly closing alerts. So conditions are resolved on the whole statement, before expansion, preserving AND semantics (verified against the real p-gh487uoz account+arn deny).

How it stays fast

SCPs are partitioned in __init__:

• the static baseline (the FullAWSAccess * allow + any statement we can't resolve) is expanded once, as today;
• only principal-conditional Deny statements are kept raw and resolved + expanded per principal — these are targeted (specific actions), so there's no per-principal re-expansion of *.

The should_deny / permission-boundary hot path is unchanged — resolved denies simply arrive unconditional.

Tests

tests/test_principal_conditions.py (10 cases): unconditional removal; ARN condition applies/skips (non-exempt vs exempt); account condition applies/skips; mixed account+ARN AND-semantics (applies for non-allowed account, skips for allowed); principal-tag applies/skips; absent-tag stays symbolic; region condition stays symbolic; mixed principal+region stays symbolic.

All 48 tests pass (incl. existing test_e2e). black / isort / flake8 clean; mypy clean for evaluator.py. Version bumped 1.1.7 → 1.1.8.

Validated on the customer's real SCPs (p-6pwmb6if + p-gh487uoz): a non-exempt role loses the guardrail actions (alert clears); the exempt SSO admin roles keep them (alert correctly still fires for those — a separate rule-tuning question).

Notes for reviewers (IAM team)

• Changes how every deny with a principal-only condition resolves, fleet-wide (more accurate; matches AWS). Worth a blast check on real accounts before release.
• Conservative by construction: anything not provably decidable stays symbolic, so errors fail toward keeping permissions / firing alerts, never toward wrongly clearing them.
• Deliberately out of scope: aws:PrincipalOrgID/OrgPaths (not in get-account-authorization-details), aws:username/userid (runtime-session ambiguity for roles), and all request-context keys (undecidable statically).
• Still pending for CIEM-685: confirm the customer's actual deployed guardrail-deny SCP (conditional vs unconditional) to decide whether this change is required for their alert or just a correctness improvement.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud