Autonomous agents can reach an EKS cluster using a single OIDC/SSO identity, with permissions granted only for the exact operation they need, while every command is recorded and any sensitive data is masked. In that model the agent never holds long‑lived AWS keys, and the cluster sees a short‑lived, purpose‑bound session that expires automatically. Teams gain confidence that a bot cannot wander beyond its intended scope, and auditors have a complete audit trail of what was run. The combination of just‑in‑time access, real‑time approval, and command‑level audit turns a potential security blind spot into a controllable surface.
Why oidc/sso matters for EKS access
OIDC/SSO provides a federated identity that can be mapped to AWS roles and, ultimately, to Kubernetes RBAC. By using a single identity provider, organizations can retire static IAM users for bots, enforce MFA at the source, and centralise group membership. The identity itself is trustworthy, but without a gateway the request still travels directly to the cluster, leaving the control plane exposed to unchecked commands.
Current practice and its gaps
Many teams provision autonomous agents with long‑lived IAM access keys that are stored in secret managers or embedded in CI pipelines. The keys often have broad permissions, read/write across all namespaces, ability to create new resources, and sometimes even cluster‑admin rights. Because the agent talks straight to the EKS API, there is no record of which command was issued, no way to mask secrets that appear in logs, and no inline approval step for privileged actions. If a credential is compromised, the attacker can move laterally across the entire cluster with no visibility.
The missing enforcement layer
Even when OIDC/SSO is in place, the request still reaches the Kubernetes control plane directly. The setup decides who may start a session, but it does not enforce what the session may do. Without a data‑path enforcement point, you cannot apply command‑level guardrails, capture a complete audit trail, or perform real‑time data masking. The security guarantees you need exist only when a gateway sits between the identity and the cluster.
hoop.dev as the data‑path gateway
hoop.dev is a Layer 7 gateway that proxies every connection to EKS. It verifies the OIDC/SSO token, extracts group claims, and then uses a dedicated IAM role that the gateway agent assumes. That role is mapped to a Kubernetes RBAC binding, so the session inherits the exact permissions required for the requested operation. Because the gateway holds the credential, the agent never sees it.
How hoop.dev enforces oidc/sso for EKS
- Identity verification – hoop.dev validates the OIDC/SSO token against the configured IdP and reads group membership.
- Just‑in‑time role assumption – The gateway agent assumes the EKS‑specific IAM role defined on the connection, which is linked to a Kubernetes ClusterRoleBinding for the session.
- Command‑level guardrails – Before any kubectl command reaches the API server, hoop.dev inspects the request. Dangerous verbs such as delete on cluster‑wide resources can be blocked or routed for manual approval.
- Inline data masking – Responses that contain secret fields are filtered in real time, preventing sensitive values from appearing in logs or downstream tools.
- Session recording – Every command and its result are recorded by hoop.dev, creating a replayable audit trail that auditors can query without needing access to the cluster itself.
- Approval workflows – For actions that exceed a predefined risk threshold, hoop.dev pauses the request and notifies a reviewer. Once approved, the command proceeds; otherwise it is denied.
All of these outcomes are possible only because hoop.dev occupies the data path between the identity provider and the EKS control plane.