Skip to main content

Set up the Amazon EKS MCP server

The Amazon EKS MCP server gives AI agents access to your Kubernetes clusters — listing clusters, inspecting nodegroups, and querying workload state. This guide covers connecting it to MintMCP using either access keys or AWS SSO (IAM Identity Center). Authorizing the principal on each cluster is an AWS-side prerequisite — see below.

Prerequisites​

  • A MintMCP admin account
  • One or more EKS clusters
  • An IAM principal (user or role) already set up for EKS access on the AWS side:
note

EKS authorization has two layers. The connector authenticates with your AWS credentials and generates the Kubernetes API token automatically (no kubeconfig needed) — but cluster calls return Unauthorized unless that principal is also mapped on each cluster via an EKS access entry. Set up the access entry before connecting.

IAM permissions​

The principal you connect needs the IAM permissions the connector uses for its AWS API calls — these are documented for the Amazon EKS MCP server. The connector runs read-only by default.

Read-only operations​

Attach this policy to the principal you connect:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "eks:DescribeInsight",
        "eks:ListInsights",
        "ec2:DescribeVpcs",
        "ec2:DescribeSubnets",
        "ec2:DescribeRouteTables",
        "cloudformation:DescribeStacks",
        "cloudwatch:GetMetricData",
        "logs:StartQuery",
        "logs:GetQueryResults",
        "iam:GetRole",
        "iam:GetRolePolicy",
        "iam:ListRolePolicies",
        "iam:ListAttachedRolePolicies",
        "iam:GetPolicy",
        "iam:GetPolicyVersion",
        "eks-mcpserver:QueryKnowledgeBase"
      ],
      "Resource": "*"
    }
  ]
}
note

AWS's IAM policy editor may flag eks-mcpserver:QueryKnowledgeBase as unrecognized ("the service ... does not exist"). That's a validation lag for the newer eks-mcpserver namespace, not an error in the policy — the action gates the connector's EKS troubleshooting knowledge-base tool (search_eks_troubleshoot_guide). If the editor lets you save through the warning, keep it. If it blocks you, remove that one line — only the troubleshooting-guide tool is affected, and you can add it back later.

To attach this policy to an IAM user (the Access keys path), add it as an inline policy:

  1. Open the user's Permissions tab and choose Add permissions > Create inline policy

    User Permissions policies panel with the Add permissions button Add permissions dropdown showing Create inline policy

  2. Switch the editor to JSON, paste the policy above, then review and create it

    Policy editor in JSON mode showing the EKS read-only actions

For the AWS SSO path, add these permissions to your permission set instead (see the AWS SSO tab below).

Write operations​

Write tools (such as apply_yaml and manage_k8s_resource) are disabled by default. If you enable them, the principal needs broader access — the following AWS managed policies are recommended:

  • IAMFullAccess — create and manage IAM roles and policies
  • AmazonVPCFullAccess — create and configure VPC resources
  • AWSCloudFormationFullAccess — create, update, and delete CloudFormation stacks

Grant write permissions only if your team needs them; the read-only policy above is sufficient for inspecting clusters and workloads.

These IAM permissions cover the connector's AWS API calls only — cluster-level authorization is separate (see the access entry in Prerequisites).

Add Amazon EKS to MintMCP​

Amazon EKS is pre-listed in the MintMCP MCP store. Open the connector and choose the auth mode that matches your AWS setup.

Use this option when you have an IAM user with long-lived access keys. No IAM Identity Center required — the keys don't expire, but you must rotate them manually.

  1. Go to the IAM console and open the user

    IAM users list with a user selected

  2. Click Security credentials > Access keys > Create access key

    User detail tabs with Security credentials selected Access keys panel with the Create access key button

  3. Select Application running outside AWS and click through to create the key

    Access key use case selection with Application running outside AWS selected

  4. Copy the Access key ID and Secret access key — the secret is shown only once

    Retrieve access keys page showing the access key ID and masked secret access key

  5. Attach the read-only policy to this user as an inline policy (see IAM permissions), and make sure it has the cluster access entry from Prerequisites

Configure the connector

  1. In MintMCP, go to MCP store → Manage store
  2. Find the Amazon EKS connector and click to install it
  3. Set Authentication Method to Access Keys (env vars)
  4. Enter the following values:
FieldValue
AWS_ACCESS_KEY_IDThe access key ID
AWS_SECRET_ACCESS_KEYThe secret access key
AWS_REGIONThe AWS region where your clusters live (for example, us-east-1)
  1. Click Save

Security considerations​

  • IAM user access keys don't expire but are long-lived secrets — rotate them on a schedule and scope the IAM policy to the minimum required permissions.
  • Always map the base principal ARN in EKS access entries — session ARNs (arn:aws:sts::…:assumed-role/…/<session>) create entries that silently never match.
  • The connector generates Kubernetes API tokens using AWS STS — equivalent to aws eks get-token. No kubeconfig file is stored on MintMCP's infrastructure.
  • AWS SSO ties each call to an individual's SSO session at the AWS level (visible in CloudTrail via the assumed-role session), giving a cleaner audit trail than shared static keys. Note that users assigned the same permission set share its IAM role, so the EKS access entry — and the in-cluster (Kubernetes) view — sees that shared role rather than the individual.
  • AmazonEKSViewPolicy is read-only. Grant it at cluster scope unless namespace-level isolation is required.

Next steps​