IAM Condition Keys for Least Privilege

Conditions tighten policies. The high-impact conditions.

aws:SourceIp

Most teams write IAM policies that grant a role permissions on resources. The Action and Resource elements get most of the attention; the Condition element gets ignored. That is a mistake. Condition keys are how you turn a coarse "this role can access these resources" into a precise "this role can access these resources, only from these networks, only with MFA, only during business hours, only to specific IDs." They are the surgical scalpel of IAM.

What aws:SourceIp does:

• Limits access to IP ranges.: The condition restricts the policy to requests originating from the specified CIDR ranges. A role granted access to a sensitive S3 bucket can have a condition limiting use to your office VPN, your production NAT, or your dedicated build infrastructure.
• Office VPN, production CIDRs.: Common patterns: limit admin actions to the corporate VPN; limit production access to the VPC NAT gateways; limit emergency-access account usage to a specific bastion host. Each rule is a sentence in the policy and a serious tightening of the security posture.
• Catches stolen credentials.: A leaked credential cannot be used from an attacker's machine because the source IP fails the condition. The credential is functionally useless outside the allowed networks. Even if exfiltrated, it cannot be used to access the protected resources.
• Combine with other conditions.: aws:SourceIp can be combined with aws:RequestedRegion, aws:CurrentTime, aws:UserAgent. The combined conditions narrow access to exactly the cases that should be allowed; everything else is denied.
• Document the allowlist.: The CIDR list in the policy needs to be updated when network architecture changes. A policy that hardcodes a CIDR that has been retired silently breaks. The list is reviewed quarterly; the policy is updated as part of normal infrastructure change management.

aws:SourceIp is the simplest and one of the most effective condition keys. The cost is a few lines of YAML; the protection is permanent.

aws:SourceVpc

aws:SourceVpc is the network-aware condition for VPC-internal traffic. Where SourceIp uses public IP addresses, SourceVpc uses VPC IDs. The condition limits access to requests that originated inside specified VPCs.

• Limit access to VPC.: The condition restricts the policy to requests where the source VPC matches the allowed list. Cross-VPC access (which often indicates lateral movement or misconfiguration) gets denied at the IAM layer.
• Catches cross-VPC access.: A workload that should only be reachable from a specific VPC cannot be reached from another, even if the IAM principal would otherwise have permission. The defense is at the IAM evaluation layer, separate from network-level controls.
• Pairs with VPC endpoints.: When AWS services are accessed via VPC endpoints (private connectivity that does not traverse the internet), the source VPC is recorded. The condition can require access through specific endpoints, which restricts traffic to controlled paths.
• Useful for multi-account architectures.: Organizations with many AWS accounts use aws:SourceVpc to restrict cross-account access. A policy in account A can require access to come from VPCs in account B, which is one of the cleanest ways to constrain cross-account API calls.
• Logged in CloudTrail.: The source VPC is part of the request metadata. CloudTrail logs include it. The audit trail can show "this credential was used from VPC X at time Y," which is forensically valuable.

aws:SourceVpc is the network-segmentation condition for AWS-internal traffic. It complements aws:SourceIp; both restrict origin, at different layers.

aws:MultiFactorAuthPresent

The strongest condition key for sensitive actions is aws:MultiFactorAuthPresent. The condition requires that the calling identity authenticated with MFA recently (within the configured window). Actions that are particularly dangerous (production changes, IAM modifications, unencrypted data exports) become impossible without active MFA.

• Require MFA for sensitive actions.: Place the condition on policies that grant high-risk permissions. The action requires MFA; without it, even a principal with the underlying permission cannot perform it. This is the single most effective lateral-movement defense.
• Standard for sensitive operations.: Production deployments, IAM changes, data exfiltration prevention (s3:GetObject on sensitive buckets), encryption-key access, console logins to admin accounts. Each of these benefits from MFA conditioning.
• Time-window aware.: The MFA freshness can be tuned with aws:MultiFactorAuthAge. Recent MFA (within 1 hour) for the most sensitive actions; less recent (within 8 hours) for less sensitive ones. The MFA frequency matches the sensitivity level.
• Defends against credential theft.: A stolen long-lived credential typically does not have MFA attached. Actions guarded by MFA conditions are unavailable to the attacker. The damage from credential theft is bounded to the actions that do not require MFA.
• Pair with role chaining.: A common pattern: human user assumes a role that requires MFA; the assumed role has the elevated permissions. Service-to-service calls do not chain through the human, so they cannot use the MFA-conditioned permissions. The split is what enforces the human-in-the-loop for sensitive actions.

IAM condition keys are the difference between a policy that grants access broadly and one that grants access precisely. Nova AI Ops audits IAM policies for missing condition keys on sensitive actions, surfaces the cases where production policies do not require MFA on dangerous operations, and tracks the condition coverage over time so the IAM posture matures rather than drifts.