How do you audit who holds the AWS AmazonEKSMCPReadOnlyAccess Managed Policy?

How AWS managed policy attachment auditing works

The audit is really an attachment inventory question: find every IAM principal that has AWS IAM policies and roles associated with it, then isolate the principals attached to AmazonEKSMCPReadOnlyAccess specifically. In practice, that means checking direct user attachments, group membership, and role attachments, because the effective access path can be inherited rather than obvious from the user record alone.

A useful audit also distinguishes who can use the permission from who merely appears in an inventory. For example, a group attachment may still grant access to multiple users, and a role attachment may be the real path used by automation or temporary access. Confirming the principal type matters because removal decisions, ownership, and recertification evidence are different for users, groups, and roles.

If you already have access to IAM Access Analyzer or a similar inventory process, use it to validate the attachment list, then cross-check the result against the policy’s actual usage history. That reduces the risk of missing inherited access or overlooking a dormant attachment that still exists but is no longer operationally needed.

What to check after you identify the attachments

Once you have the attachment list, verify whether each principal still needs the policy for its current job function, environment, or automation path. The goal is not only to know where the policy is attached, but whether that attachment is still justified. A stale attachment is a standing access path, even when no one remembers using it.

Pay special attention to roles that are assumed by workloads, deployment tooling, or cross-account processes. Those paths are easy to miss because the human operator is not the effective principal. If the policy was attached as a convenience during provisioning or troubleshooting, it often survives long after the original need has gone away.

For broader governance context, Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful when the audit needs to fit into a repeatable access review and recertification process rather than a one-off cleanup.

When the attachment exists through a group, audit both the group membership and the policy attachment itself. Removing the policy from the group can be the right fix, but only if no remaining member depends on it. When the attachment exists through a role, review who can assume the role and whether the role should continue to exist at all.

How to remove unnecessary access without breaking workloads

Remove unused attachments in the narrowest way that preserves legitimate access paths. If a single user no longer needs the policy, detach it from that user rather than changing a shared group or role unless the shared path is also obsolete. That keeps the remediation targeted and reduces the chance of breaking unrelated access.

Before detaching anything from a role, confirm whether the role supports automation, cross-account access, or a managed workload flow. If it does, update the dependent workflow first or schedule the change so you can observe whether the role is still required. For cloud workloads, Cloud Workload Identity Guide is a helpful companion when you need to separate static permission assignment from runtime role use.

After cleanup, re-run the attachment review on a schedule and treat the result as part of ordinary access hygiene. A one-time removal does not prevent the same policy from being attached again later, so the real control is recurring review plus ownership of each principal that still carries the permission.

Risk and Threat Considerations

Unneeded managed policy attachments create durable access that is easy to overlook and hard to justify later. In AWS, a read-only policy can still expose operational detail, service metadata, and control-plane visibility that helps an attacker map the environment or prepare the next step after initial access.

Failure mechanism: The policy stays attached to a user, group, or role after the original business need has ended, so access remains available through inheritance or assumption even when no one actively uses it.

Impact: Excess access broadens the blast radius of a compromised principal, complicates least-privilege review, and increases the chance that an old attachment becomes the easiest path for misuse or reconnaissance.

Practitioner Guidance

What to verify: Confirm the exact attachment source for each principal, not just the current policy list on the user record. Group inheritance and assumed-role paths are the most common places where audits miss the real exposure.

Decision rule: If the attachment exists only for convenience or legacy access, remove it. If a role or group still supports an active workflow, validate the dependency first and remediate the workflow before detaching the policy.

Practitioner takeaway: The audit is complete only when you can explain both who has the policy and why each attachment still deserves to exist.

Related resources from NHI Mgmt Group

• How do you audit who holds the AWS AmazonBedrockFullAccess managed policy?
• How do you audit who holds the AWS AmazonDynamoDBReadOnlyAccess managed policy?
• How do you audit who holds the AWS AmazonEKSClusterPolicy managed policy?
• How do you audit who holds the AWS IAMAccessAnalyzerReadOnlyAccess managed policy?