IAM Permissions Boundary Conflict Resolver

The Incident (What Does the Error Mean?)

Raw error output:

An error occurred (AccessDenied) when calling the PutObject operation:
User: arn:aws:sts::123456789012:assumed-role/app-deploy-role/session
is not authorized to perform: s3:PutObject on resource:
arn:aws:s3:::prod-artifacts-bucket/deploy/*
because no permissions boundary allows the s3:PutObject action

The phrase "because no permissions boundary allows" is the signal. This is not a missing identity policy — it is a permissions boundary gap. The role app-deploy-role has an inline or managed policy granting s3:PutObject, but the boundary policy attached to that role omits it entirely.

Immediate consequence: Every API call gated by the missing boundary action fails with AccessDenied at runtime. CI/CD pipelines stall, Lambda deployments fail silently, and ECS task roles cannot write logs — depending on which action is blocked.

The Attack Vector / Blast Radius

Permissions boundaries exist specifically to constrain privilege escalation. If a developer or automated pipeline created this role with iam:CreateRole + iam:AttachRolePolicy but the org-wide boundary SCP was not updated, you now have a silent least-privilege violation in both directions:

1. Operational blast radius: Any service relying on this role is dead. If the role is used by a deployment pipeline, every environment that role touches is frozen.
2. Security risk of the wrong fix: The instinctive wrong fix is attaching AWS:* or *:* to the boundary to "just make it work." That collapses the boundary entirely — the role can now escalate to any permission its identity policy grants, including iam:PassRole, sts:AssumeRole, or ec2:RunInstances. A compromised workload with that role becomes a full account takeover vector.
3. Audit trail gap: If the boundary was silently too permissive before and someone tightened it without updating identity policies, you may have multiple broken roles across accounts — check CloudTrail for AccessDenied events with the "reason":"PermissionsBoundary" field across all regions.

CloudTrail query to find all boundary-blocked calls in the last 24h:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AccessDenied \
  --start-time $(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ) \
  --query "Events[?contains(CloudTrailEvent, 'PermissionsBoundary')].{Time:EventTime,User:Username,Event:CloudTrailEvent}" \
  --output table

Prevention in CI/CD

1. Checkov — block boundary-less role creation at PR time:

# .checkov.yml
checks:
  - CKV_AWS_274  # Ensure IAM roles have permissions boundaries attached
  - CKV_AWS_275  # Ensure boundary does not allow iam:* wildcard

2. OPA/Conftest policy — enforce boundary attachment on every aws_iam_role resource:

package terraform.aws.iam

deny[msg] {
  resource := input.resource.aws_iam_role[name]
  not resource.config.permissions_boundary
  msg := sprintf("IAM role '%v' is missing a permissions_boundary. Attach a scoped boundary policy.", [name])
}

deny[msg] {
  resource := input.resource.aws_iam_policy[name]
  statement := resource.config.policy.Statement[_]
  statement.Effect == "Allow"
  statement.Action == "*"
  msg := sprintf("Policy '%v' uses wildcard Action in Allow statement — forbidden in boundary policies.", [name])
}

3. GitHub Actions — run boundary drift detection on every merge to main:

- name: Validate IAM Boundaries
  run: |
    checkov -d ./iam --framework terraform \
      --check CKV_AWS_274,CKV_AWS_275 \
      --hard-fail-on HIGH

4. AWS Config Rule — deploy iam-role-managed-policy-check with the managedPolicyArns parameter set to your org-standard boundary ARN. Any role created without it triggers an SNS alert and auto-remediation Lambda within 60 seconds.