Amazon EKS IAM Condition Keys: Enforce Cluster Guardrails with SCPs and IAM

On April 20, 2026, AWS added seven Amazon EKS IAM condition keys that finally make several cluster standards enforceable before the cluster is created or changed. That date matters because many EKS governance programs still depend on after-the-fact checks: a Config rule, a security scan, a platform review, or a Slack message asking why a public endpoint exists in production. The new keys move those controls into IAM and AWS Organizations SCPs.

The announcement is short, but the operational impact is large. AWS says the condition keys apply to CreateCluster, UpdateClusterConfig, UpdateClusterVersion, and AssociateEncryptionConfig. That means platform teams can block noncompliant cluster settings at the API boundary instead of discovering them after workloads are already scheduled.

If you already use IAM permission boundaries for delegated platform work, this fits the same model described in IAM Permission Boundaries: Delegating Safely Without Losing Control. The difference is scope. Permission boundaries limit what delegated roles can do. EKS condition keys limit what cluster shapes those roles can create or mutate.

Source: AWS: Amazon EKS enhances cluster governance with new IAM condition keys.

The Seven New EKS Governance Keys

Here is the practical map. These are not abstract IAM features. Each one maps to a platform decision you either want to centralize or let teams choose intentionally.

These controls matter most in multi-account AWS Organizations setups where application teams own workload accounts and the platform team owns the cluster baseline. Without preventive controls, every account becomes a negotiation.

Decision Table: SCP, IAM Policy, or Admission Control?

Do not use SCPs for everything just because they are powerful. SCPs are blunt by design. IAM identity policies are better for team-level delegation. Kubernetes admission control is still necessary for workload-level policy.

For EKS workload policy, keep using tools like Kyverno, Gatekeeper, and Pod Security Standards. The article on Kyverno Policy-as-Code on EKS is still the right layer for pods, namespaces, labels, images, and runtime constraints. These new IAM keys operate one layer above that: cluster lifecycle governance.

Baseline Guardrail Model

A clean EKS governance model has three layers:

1. AWS Organizations SCPs define non-negotiable company rules.
2. IAM policies define what each platform or application role can do.
3. Kubernetes policy defines what workloads can run inside the cluster.

For example, the organization may decide:

• Production clusters must use private endpoint access.
• Public endpoint access is denied except in sandbox accounts.
• Secrets encryption must use a customer-managed KMS key from the security account.
• Only approved Kubernetes versions can be created or upgraded to.
• Deletion protection is required for production.
• Zonal shift is required for tier-0 and tier-1 workloads.

That gives teams freedom inside safe boundaries. It is the same philosophy as Amazon EKS Auto Mode in Production: use AWS-managed capabilities where they reduce operational toil, but encode your production assumptions explicitly so surprises do not arrive during an incident.

Example SCP: Deny Public EKS Endpoints in Production

This SCP denies cluster creation and endpoint updates when a request tries to enable public endpoint access in accounts tagged or organized as production. In a real organization, attach it to the production OU, not the whole root, unless every account follows the same rule.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPublicEksEndpointInProduction",
      "Effect": "Deny",
      "Action": [
        "eks:CreateCluster",
        "eks:UpdateClusterConfig"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "eks:endpointPublicAccess": "true"
        }
      }
    }
  ]
}

Pair it with a second deny for eks:endpointPrivateAccess = false. I usually keep those endpoint checks as two separate statements instead of one clever block. The error message is easier to read during a failed Terraform apply, and the fix is obvious: turn off the public endpoint, turn on the private endpoint, or do both.

Example SCP: Require Approved Kubernetes Versions

Version governance is one of the best uses for condition keys because unsupported versions create hidden operational risk. You do not want every account discovering version policy during the next emergency upgrade.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedEksVersions",
      "Effect": "Deny",
      "Action": [
        "eks:CreateCluster",
        "eks:UpdateClusterVersion"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "eks:kubernetesVersion": [
            "1.31",
            "1.32",
            "1.33"
          ]
        }
      }
    }
  ]
}

The exact version list should come from your platform support matrix. Keep it in code. Update it as part of the same process you use for the EKS cluster upgrade zero-downtime playbook. A hard-coded SCP that nobody owns becomes a future outage.

Example SCP: Require Secrets Encryption with Approved KMS Keys

EKS secrets encryption is not just a compliance checkbox. Kubernetes Secrets are base64-encoded objects stored in etcd. EKS gives you the option to use AWS KMS for envelope encryption, and these condition keys let you make that option mandatory.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyEksWithoutApprovedSecretsKey",
      "Effect": "Deny",
      "Action": [
        "eks:CreateCluster",
        "eks:AssociateEncryptionConfig"
      ],
      "Resource": "*",
      "Condition": {
        "ForAllValues:StringNotLike": {
          "eks:encryptionConfigProviderKeyArns": [
            "arn:aws:kms:*:123456789012:key/*",
            "arn:aws:kms:*:210987654321:key/*"
          ]
        }
      }
    }
  ]
}

This is where teams should be precise. If every team creates its own KMS key with inconsistent rotation, grants, and aliases, you have encryption but not governance. For regulated workloads, connect this to the pattern in Building PCI DSS-Compliant Architectures on Amazon EKS: centralize key policy, log KMS usage, and keep evidence collection boring.

Example SCP: Require Deletion Protection for Production

Deletion protection should be boring. Production clusters should not disappear because the wrong Terraform workspace ran or someone tested a cleanup script with broad permissions.

The policy shape is the same as the endpoint example: deny eks:CreateCluster and eks:UpdateClusterConfig when eks:deletionProtection is false. Do not attach that to sandbox OUs unless you really want every experiment to require a special break-glass path. The point is to protect durable environments, not to make engineers afraid to delete lab clusters.

Example IAM Policy: Delegated Cluster Creation

SCPs set the ceiling. IAM policies still define who can act. For a delegated platform role, keep the identity policy narrow and make the conditions match the platform contract: private endpoint enabled, public endpoint disabled, deletion protection on, approved version selected, approved KMS key used, and zonal shift enabled where the workload tier requires it.

Do not copy a policy from a blog post straight into the management account. Keep the full JSON in your platform repository, add tests for the AWS CLI and Terraform paths, and verify the same request through any internal portal your teams use. IAM condition evaluation is exacting. A tool that omits a field can fail differently from a tool that sends the field as false.

Terraform Pattern: Make the Guardrail Visible

Preventive IAM controls should not be invisible. If Terraform users only see an AccessDenied error after a ten-minute plan/apply cycle, they will blame AWS instead of understanding the standard.

Put the approved values in the module interface. The key part is the validation, not the number of variables:

variable "kubernetes_version" {
  type        = string
  description = "Approved EKS Kubernetes version."

  validation {
    condition     = contains(["1.31", "1.32", "1.33"], var.kubernetes_version)
    error_message = "Use an approved EKS version from the platform support matrix."
  }
}

Then set the cluster arguments explicitly in your module:

resource "aws_eks_cluster" "this" {
  vpc_config {
    subnet_ids              = var.private_subnet_ids
    endpoint_public_access  = false
    endpoint_private_access = true
  }

  deletion_protection = true
}

The SCP remains the enforcement layer. Terraform validation is the developer experience layer. You need both. One prevents bad clusters from existing. The other tells engineers what the standard is before the AWS API rejects the request.

Practical Rollout Checklist

Roll this out like a production control, not like a documentation update.

• Inventory all accounts that can create or update EKS clusters.
• Identify which OUs are production, non-production, sandbox, and shared services.
• List current cluster endpoint settings, Kubernetes versions, deletion protection, KMS encryption, and zonal shift status.
• Decide which controls are mandatory at the SCP layer and which belong in IAM policies.
• Add exceptions only for accounts, not individual engineers, where possible.
• Test each policy in a sandbox OU with Terraform, AWS CLI, eksctl, and your platform tooling.
• Publish a support matrix for approved Kubernetes versions and scaling tiers.
• Update Terraform modules so denied settings fail validation before AWS API calls.
• Add CloudTrail detection for denied EKS API calls so platform teams can spot friction.
• Document break-glass steps for temporary public endpoint access, if your organization allows it.

That last item matters. The existence of a guardrail does not remove the need for an emergency path. It makes the emergency path explicit, logged, and reviewed.

Gotchas Before You Attach the SCP

Update APIs matter as much as create APIs

If you only restrict CreateCluster, someone can create a compliant cluster and later update it into a noncompliant state. AWS says these condition keys apply to create and update APIs, so cover both.

SCPs do not grant permissions

An SCP can deny public endpoints, but it cannot allow a platform role to create clusters. You still need identity policies, permission boundaries, and role trust policies. This is the same evaluation model covered in the IAM permission boundaries guide.

Condition keys can break automation that omits default values

Some tools rely on service defaults instead of sending every field. If your deny condition expects a key that is not present, test the behavior carefully. You may need separate Null checks so missing configuration fails closed without confusing engineers.

KMS key governance includes grants and key policy

Requiring a KMS key ARN is not enough. The EKS service principal and cluster role need the right permissions, security teams need audit visibility, and key deletion must be controlled. A wrong key policy can block cluster creation just as effectively as an SCP.

Version allowlists need an owner

Kubernetes version allowlists age quickly. Assign ownership to the platform team and update the list before forcing teams to upgrade. Otherwise the policy becomes a bottleneck during normal cluster lifecycle work.

Private endpoint access requires network readiness

Denying public endpoint access is easy. Operating private-only clusters requires VPN, Direct Connect, bastion, SSM, private DNS, and CI runner connectivity. Solve that before attaching the SCP to production.

Where This Fits in an EKS Platform

These condition keys are not a replacement for platform engineering. They are a way to make the platform contract enforceable.

Use them to answer questions before they become incidents:

• Can a team create a public EKS endpoint in production? No.
• Can a team skip secrets encryption? No.
• Can a team upgrade to a version the platform has not tested? No.
• Can a team delete the production cluster with a broad automation role? No.
• Can a critical workload opt out of zonal shift readiness? No.

The best result is not more denied API calls. The best result is that teams never submit bad requests because modules, templates, and documentation already encode the policy. SCPs should be the guardrail at the cliff edge, not the normal developer feedback loop.

If you run multiple EKS clusters across accounts, this April 2026 release is worth prioritizing. It lets you move cluster governance from “scan and complain later” to “prevent the unsafe shape from existing.” For EKS, that is a much stronger operating model.