Most EKS access stories start at the wrong layer. Teams wire up an IAM user, drop a kubeconfig in a secret, and call it access control. Then an AI agent inherits that kubeconfig and the question "who is this agent and who said it could run this" has no answer. OIDC/SSO exists to answer that question, and configuring AI agents access to EKS with OIDC/SSO is how you make the answer enforceable rather than aspirational.
The model is simple to state. The agent authenticates against your identity provider, the provider issues a token, and a gateway in front of the cluster verifies that token and reads identity plus group membership before any kubectl command moves. hoop.dev is the gateway that does this.
What OIDC/SSO actually governs here
hoop.dev is an open-source Layer 7 access gateway and an OIDC/SAML relying party. It does not replace your identity provider and it does not front the provider's admin API. The engineer or agent authenticates to the provider, the provider issues the token, and hoop.dev verifies it. From the verified token hoop.dev reads who the caller is and which groups they belong to, then uses that to authorize access to the EKS connection.
That is the load-bearing distinction. OIDC/SSO is consumed for authentication into the gateway. The gateway then governs the connection to the cluster. Your provider stays the source of truth for identity; hoop.dev is the point where that identity turns into a decision about what reaches EKS.
How the connection to EKS works underneath OIDC/SSO
Once a caller is authenticated by OIDC/SSO, hoop.dev's kubernetes-eks connector reaches the cluster on a separate credential. The network-resident agent assumes a configured AWS IAM role, the EKS_ROLE_ARN, as the service identity, and that role maps to a Kubernetes RBAC role. The caller's verified identity is attributed at the gateway and recorded against every command; the cluster itself is reached by the service role. The agent never holds a kubeconfig, so there is nothing on the agent for an attacker to lift.
Setup steps
- Connect your OIDC/SSO provider to hoop.dev as the authentication source so engineers and agents sign in through it.
- Map provider groups to access policies in the gateway. A group like
ai-agents-readonly becomes a policy that grants a scoped EKS connection. - Configure the EKS connection with cluster URL, region, cluster name, and the IAM role ARN that maps to the right RBAC role.
- Point the AI agent at the gateway and have it complete the OIDC/SSO flow to obtain a session.
- Verify by checking that a
kubectl auth can-i call reflects the policy tied to the agent's group, not a static kubeconfig.
# the agent presents a verified OIDC identity to the gateway
# the gateway maps group -> policy -> EKS connection (role ARN -> RBAC)
group: ai-agents-readonly
connection: prod-eks
binding_user_role: eks-readonly
The verification step matters more than it looks. If the answer to can-i tracks the group you assigned in the provider, then access really does derive from OIDC/SSO. If it tracks a kubeconfig sitting on the agent, you have a login screen in front of standing access, which is not the same thing.
Pitfalls
- Do not treat OIDC/SSO as a one-time login and then leave a long-lived kubeconfig on the agent. The whole point is that access derives from the verified session.
- Do not map every agent to one broad group. Group membership is your scoping lever; use it to keep blast radius small.
- Do not expect hoop.dev to manage your provider. It verifies tokens and reads identity. Admin of the provider stays with the provider.
Why this is the stronger model
The requirement is that authorization to EKS derives from an identity your provider already owns, checked at a point the agent cannot reconfigure. OIDC/SSO supplies the identity; the gateway is where the check runs. One design scatters that check; the other puts it on the single path to the cluster. hoop.dev embodies the second. Start with the getting started guide, and read more on identity-aware access patterns.
FAQ
Does hoop.dev replace my identity provider? No. It is a relying party. Your provider issues tokens; hoop.dev verifies them and reads identity to drive authorization.
How does OIDC/SSO connect to Kubernetes RBAC? The verified identity and its group select a policy and an EKS connection. The connection's IAM role maps to a Kubernetes RBAC role inside the cluster.
Can agents and humans use the same flow? Yes. Both authenticate through OIDC/SSO and both are authorized and recorded the same way.
hoop.dev is open source. Pull the code at github.com/hoophq/hoop and put OIDC/SSO in front of your EKS access where it belongs.
