Assigning the AWS AmazonEKSMCPReadOnlyAccess Managed Policy can expose more read access than a workload truly needs, which increases the impact of credential theft or abuse. Any broad read policy can reveal cluster, configuration, or operational details that help an attacker move laterally or plan follow-on actions. Review the exact permissions, apply least privilege, and remove unused access.
Why AmazonEKSMCPReadOnlyAccess Still Creates Meaningful Exposure
Read-only is not harmless when the permissions are broad. For an EKS-integrated workload, the policy can expose cluster structure, namespace layout, workload metadata, add-on configuration, and other operational details that help an attacker understand the environment and choose the next step. That visibility can turn a stolen token into a better-planned intrusion path.
If the workload does not genuinely need those EKS read paths, the access itself is unnecessary exposure. The main question is not whether the policy can write changes, but whether it reveals enough state to make subsequent abuse, privilege escalation, or lateral movement easier.
That matters because attackers often benefit from reconnaissance before they attempt control-plane abuse. Even without write access, a policy that reveals topology, naming patterns, cluster ownership, or configuration gaps can reduce attacker uncertainty and improve their ability to target higher-value systems.
What to Check Before You Assign It
Start by confirming whether the calling workload actually needs EKS read visibility, or whether it only needs a narrower operational signal such as a specific API response, metric, or health check. The more you can constrain the subject, the less useful the policy becomes to an attacker if credentials are exposed.
Review the permissions at the exact action level and test the effective result in the same role, account, and cluster context where the workload runs. A managed policy name does not tell you whether the attached scope is fit for purpose, especially when the workload only needs a small subset of the data the policy exposes.
If the workload is a service, automation, or deployment component, treat the policy as part of its access boundary. A read-only policy can still be too broad if it grants visibility across clusters, environments, or teams that the workload does not need for normal function.
How Exposure Becomes a Security Problem
Broad read access often becomes a force multiplier for compromise. Once stolen or abused, it can reveal the environment map an attacker needs to identify service names, configuration drift, privileged workloads, or weak segmentation between clusters and namespaces.
It also increases the value of any compromised credentials because the attacker can use the read permissions to verify what exists, what is running, and where the most sensitive resources sit. That intelligence can support follow-on actions such as privilege escalation, credential targeting, or more precise persistence planning.
For cloud environments, this is especially important because discovery data is often enough to shorten the attack path. The policy may not directly change state, but it can reduce the cost of finding the best place to strike next.
Risk and Threat Considerations
Broad read access can enlarge the blast radius of a stolen workload identity or secret. Even without write permissions, the attacker may gain enough cluster and configuration detail to improve targeting, map trust relationships, and identify the most sensitive workloads or misconfigurations.
Failure mechanism: The policy grants more visibility than the workload needs, so compromised credentials can be used for reconnaissance, environment mapping, and selection of higher-value follow-on targets.
Impact: The attacker gets a clearer path to lateral movement, privilege escalation, or operational disruption, while defenders lose the advantage of limited exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Broad read access can overexpose a workload identity. |
| NHI-02 — Secret Leakage | Credential theft becomes more damaging when read permissions reveal environment detail. | |
| Recommendation — Reduce the policy to the minimum EKS read actions the workload truly needs. Limit exposed read data so stolen credentials yield less environment intelligence. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The question is about excessive permissions relative to workload need. |
| IA-5 — Authenticator Management | Credential abuse is a central risk when a broad policy is attached to a workload identity. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Monitoring is needed to spot unusual use of read access for reconnaissance. | |
| Recommendation — Apply least privilege to narrow EKS read access to the minimum required actions. Rotate and protect the credential or token that can assume the policy. Review logs for unusual enumeration or broad read activity against EKS resources. | ||
Practitioner Guidance
What to verify: Confirm the workload’s actual call pattern before accepting a managed read policy as the default. If the workload only needs a narrow subset of EKS information, replace broad managed access with a tighter custom policy or a different design.
Decision rule: If the permissions reveal cluster structure or operational detail beyond what the workload needs to function, treat that as excess exposure even when no write access exists. If you cannot justify the visibility, remove it.
What good looks like: The workload can complete its task with the smallest practical read surface, and any exposed cluster metadata is limited to what the application genuinely requires to operate.
Practitioner takeaway: Read-only policies still shape attacker knowledge, so the right test is not “can it change anything,” but “what useful intelligence does it reveal if the credential is stolen?”