SCP Deny CreateAccessKey Policy Inspector

The Incident (What Does the Error Mean?)

When a power user or CI role calls iam:CreateAccessKey, AWS evaluates all SCPs in the hierarchy before evaluating identity-based policies. An explicit SCP Deny cannot be overridden by any IAM policy, including AdministratorAccess. The call is dead on arrival.

Raw error returned to the caller:

An error occurred (AccessDenied) when calling the CreateAccessKey operation:
  User: arn:aws:iam::123456789012:assumed-role/PowerUserRole/session
  is not authorized to perform: iam:CreateAccessKey
  with an explicit deny in a service control policy

Immediate consequences:

• Terraform/Pulumi apply pipelines fail when trying to rotate or bootstrap service account keys.
• Developer onboarding scripts break silently — aws configure completes but no key is actually written.
• Incident responders cannot generate break-glass credentials during an active outage.

The Attack Vector / Blast Radius

This is a dual-edged misconfiguration — it hurts defenders and, if misconfigured in the opposite direction, helps attackers.

Why the blanket Deny is dangerous to operations: SCPs apply to the entire OU. A single poorly scoped statement cascades across every account in that OU. If your PowerUserRole is used by 40 engineers and 12 CI/CD pipelines across 8 accounts, every single one of those principals is now locked out of programmatic credential creation. There is no IAM Allow that can dig you out — SCPs are evaluated before identity policy evaluation in the IAM authorization logic.

Why removing the Deny entirely is dangerous to security: If you simply delete the SCP statement in a panic, you re-expose the attack surface it was designed to close:

• A compromised developer account can call iam:CreateAccessKey on any other IAM user, including high-privilege service accounts, creating a lateral movement path.
• Long-lived access keys are a top-3 initial access vector in AWS breach post-mortems (Pacu, CloudFox, and similar tooling enumerate them in seconds).
• Attackers with iam:CreateAccessKey on a dormant admin user can create a persistent backdoor key that survives password resets and MFA changes.

The correct posture: Deny iam:CreateAccessKey for everyone except a tightly scoped set of principals (break-glass roles, specific CI/CD roles) identified by ARN or principal tag.

Prevention in CI/CD

This class of misconfiguration — overly broad SCP Deny without condition scoping — is entirely preventable with policy-as-code gates.

1. Checkov — Scan SCPs Before `aws organizations update-policy`

# Install
pip install checkov

# Scan your SCP JSON file
checkov -d ./scps/ --framework cloudformation
# Or for raw JSON policy files:
checkov --file ./deny_access_key_scp.json --check CKV_AWS_274

CKV_AWS_274 flags IAM policies (and can be extended for SCPs) that allow or deny iam:CreateAccessKey without condition constraints.

2. OPA/Rego — Custom Policy Gate in Your Pipeline

# opa/scp_deny_scope_check.rego
package aws.scp

violation[msg] {
  stmt := input.Statement[_]
  stmt.Effect == "Deny"
  stmt.Action[_] == "iam:CreateAccessKey"
  not stmt.Condition
  msg := sprintf(
    "SCP statement '%v' denies iam:CreateAccessKey with no condition scoping. Add ArnNotLike or PrincipalTag condition.",
    [stmt.Sid]
  )
}

# Evaluate before applying
opa eval --data opa/scp_deny_scope_check.rego \
         --input deny_access_key_scp.json \
         "data.aws.scp.violation"

3. Terraform `aws_organizations_policy` — Enforce via `lifecycle` Precondition

resource "aws_organizations_policy" "deny_create_access_key" {
  name    = "DenyCreateAccessKey"
  content = data.aws_iam_policy_document.deny_access_key.json

  lifecycle {
    precondition {
      condition = can(
        jsondecode(data.aws_iam_policy_document.deny_access_key.json).Statement[0].Condition
      )
      error_message = "SCP Deny on iam:CreateAccessKey MUST include a Condition block to scope exemptions."
    }
  }
}

4. Git Pre-Commit Hook — Last-Mile Defense

# .git/hooks/pre-commit
#!/bin/bash
for f in $(git diff --cached --name-only | grep 'scp.*\.json'); do
  if jq -e '.Statement[] | select(.Effect=="Deny" and (.Action=="iam:CreateAccessKey" or (.Action[]?=="iam:CreateAccessKey"))) | select(.Condition == null or .Condition == {})' "$f" > /dev/null 2>&1; then
    echo "ERROR: $f contains an unscoped SCP Deny on iam:CreateAccessKey. Add a Condition block."
    exit 1
  fi
done

Key takeaway: Every SCP Deny on a sensitive IAM action must ship with a condition. Unconditional Denies are operational landmines. Tag-based exemptions scale; ARN lists don't.