Trust:ec2.amazonaws.com: This policy allows the AWS EC2 service to assume the IAM role. It is required to attach the role to an EC2 instance, enabling applications running on that VM to automatically retrieve and use temporary AWS credentials. If your role does not require binding to a specific EC2 instance, it can skip this policy.

Permission:sts:AssumeRole: This permission allows the current identity (e.g., KongRole) to request temporary credentials for a different target role (e.g., VaultRole). It is required to initiate the "identity switch" and perform a cross-role handshake.

Permission:iam:getRole: This permission allows the active role to retrieve metadata and the internal ID of a specific IAM role from AWS. It is required for HashiCorp Vault to verify the existence and details of the Role ARN you are trying to bind.

The critical trust relationship is on VaultRole: it must explicitly trust KongRole as a principal allowed to assume it. Without this, even if Kong has sts:AssumeRole permission, the STS call will be denied at the trust boundary.

VaultRole trust Policy

VaultRole \- trust-policy.json

{
  "Version": "2026-3-27",
  "Statement": [
      {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
      },
      // Allows Kong to assume this role for Vault login
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/KongRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Vault Configuration

prepare-vault.sh

# Enable AWS auth method on Vault
vault auth enable aws

# Configure the client — no access key needed with instance profiles
vault write auth/aws/config/client region=us-east-1

# Create a Vault role bound to the VaultRole ARN
# (Kong presents this ARN after assuming the role)
vault write auth/aws/role/kong-role \
  auth_type=iam \
  bound_iam_principal_arn="arn:aws:iam::<ACCOUNT_ID>:role/VaultRole" \
  policies=kong-policy \
  ttl=1h

# Create the access policy
vault policy write kong-policy - <<EOF
path "kv/data/kong/*" {
  capabilities = ["read"]
}
EOF

# Store a secret
vault secrets enable -path=kv kv-v2
vault kv put kv/kong/db-password value="supersecret"

Kong Configuration

kong-vault-config.yaml

vaults:
  - prefix: my-vault
    name: hcv
    config:
      auth_method: aws_iam     # Use IAM, not token/approle
      assume_role_arn: "arn:aws:iam::<ACCOUNT_ID>:role/VaultRole"
      aws_region: us-east-1
      auth_role: kong-role     # Vault role name to authenticate against
      host: <vault-private-ip>
      port: 8200
      kv: v2

💡Pro Tip AWS supports two Vault auth methods: IAM (role-based, shown here) and EC2 (instance identity document). The IAM method is recommended for production. It works across services, not just EC2.

Why this matters: Governance without blind spots

The shift from static credentials to IAM role-based authentication isn't just a security upgrade. It changes your operational posture in meaningful ways.

• No rotation burden. Static access keys expire, get rotated, get accidentally committed to Git. IAM role credentials are temporary by design. STS issues them fresh for each session. There's nothing to rotate and nothing to leak.
• Unified audit trail. When Kong authenticates to Vault via AWS IAM, every access is traceable through AWS CloudTrail. You can see exactly when Kong assumed VaultRole, from which instance, and what it accessed. Static key usage is opaque by comparison.
• Least-privilege by policy. The kong-policy in Vault scopes Kong to read only from kv/kong/*. The IAM trust policy scopes VaultRole to only be assumed by KongRole. Security is enforced at two independent layers.
• Consistency across your fleet. The same pattern works whether Kong is connecting to Postgres, Redis, or Vault. Your operations team learns one mental model instead of four different workarounds.

Getting Started

If you're running Kong on AWS today and connecting to HashiCorp Vault with an AppRole token or a hardcoded access key, 3.14 gives you a clean migration path to eliminate those static credentials entirely.

Start with Kong Gateway 3.14 by [signing up for Kong Konnect](https://konghq.com/products/kong-konnect/register)signing up for Kong Konnect for free. Or, if you want to try Kong Gateway Enterprise 3.14, you can explore the options for getting started [here](https://konghq.com/install)here.

To explore the comprehensive list of features, fixes, and updates, please see the available CHANGELOG for Kong Gateway Enterprise [here](https://docs.konghq.com/gateway/changelog/)here