Giving a service account or AI‑driven bot unfettered access to an EKS cluster is a recipe for privilege creep and undetectable abuse.
Relying on a non-human identity without additional safeguards leaves the cluster exposed to credential theft and unchecked actions.
Using a non-human identity model is essential to avoid credential reuse and to enforce least‑privilege at the source.
Most teams today solve the problem by creating a long‑lived IAM role, attaching a broad set of Kubernetes RBAC permissions, and embedding the role’s credentials in a CI pipeline or a container image. The same static secret is reused by dozens of autonomous processes, from nightly jobs to on‑demand model inference. Because the role is never rotated, any compromise of the secret instantly grants an attacker full control over the cluster. Auditing is limited to cloud‑provider logs that show the role was assumed, but they do not reveal which command was run, which pod was accessed, or whether sensitive data was exfiltrated.
Switching to a non-human identity model is the first step toward reducing that risk. By issuing short‑lived, purpose‑bound identities for each agent, you can enforce least‑privilege and limit the blast radius of a breach. However, without a control point that inspects the actual traffic, the request still travels directly to the Kubernetes API server. The cluster sees a valid IAM principal, but it has no visibility into the command sequence, no inline masking of secret values in responses, and no mechanism to require human approval for risky operations.
hoop.dev places a Layer 7 gateway directly in the data path between the non-human identity and the EKS control plane. The gateway assumes a dedicated IAM role, maps the session to a Kubernetes RBAC binding, and then proxies every kubectl or API request. Because the gateway is the only point that can see and act on the traffic, it can enforce just‑in‑time approvals, mask sensitive fields in API responses, block dangerous commands before they reach the cluster, and record a full, replayable session log.
Why non-human identity matters for EKS
Autonomous agents are not people, yet they often need elevated permissions to perform tasks such as scaling workloads, rotating secrets, or collecting metrics. Treating them as human users leads to over‑provisioned roles, because the safest default is to give them more access than they truly need. A non-human identity approach forces you to define the exact scope of each agent, issue credentials that expire after a short window, and tie each credential to a specific workflow.
Even with scoped credentials, the cluster itself cannot enforce policy on the payload of the request. An agent could still issue a kubectl exec into a privileged pod, read secret environment variables, and exfiltrate data without any trace beyond the IAM audit event. That gap is where the data path must intervene.
How the gateway enforces policy in the data path
hoop.dev acts as an identity‑aware proxy. When an autonomous process authenticates via OIDC, the gateway validates the token, extracts the group membership, and then maps the session to the pre‑configured IAM role for EKS. The agent assumes that role, and the gateway forwards the request to the Kubernetes API server. Because the gateway sits between the identity and the target, it can apply several enforcement outcomes:
- Just‑in‑time approval: before a privileged operation such as deleting a namespace is executed, the gateway pauses the request and routes it to an approver. The operation proceeds only after explicit consent.
- Inline data masking: any response that contains secret data, such as ConfigMap values or pod environment variables, is filtered in real time so that the downstream agent never sees raw secrets.
- Command blocking: known‑dangerous actions, like port‑forwarding to a sensitive service, are rejected before they reach the API server.
- Session recording: every request and response is captured, timestamped, and stored for replay. Auditors can reconstruct the exact sequence of actions taken by an autonomous agent.
All of these outcomes are possible only because hoop.dev is the sole point of egress for the traffic. The Kubernetes control plane never sees the raw credentials, and the autonomous process never interacts directly with the API server.
Deploying the gateway for EKS
Start with the standard quick‑start deployment. The gateway runs as a Docker Compose service or a Kubernetes pod, and a network‑resident agent is placed in the same VPC or subnet as the EKS cluster. The agent is configured with the IAM role that it will assume for EKS access. This role is distinct from any human‑admin role and is granted only the permissions required for the agent’s workload.
Next, register the EKS cluster as a connection in the gateway. During registration you provide the cluster endpoint, the AWS region, and the ARN of the IAM role that the agent should assume. The gateway creates a corresponding Kubernetes ClusterRoleBinding that maps the session name to a limited RBAC role, such as view plus a custom permission for the specific namespace the agent needs.
Finally, configure the non-human identity provider. The autonomous process obtains an OIDC token from your identity platform (Okta, Azure AD, etc.). The token includes group claims that the gateway uses to decide whether the request is eligible for just‑in‑time approval or can be auto‑approved.
For detailed steps, see the getting‑started guide and the learn section. The repository contains the full deployment manifests and example policies.
Benefits of the integrated approach
By combining non-human identity with a data‑path gateway, you achieve three security goals in one place:
- Least‑privilege access is enforced at the moment of request, not just at credential issuance.
- All privileged actions are either approved by a human or automatically blocked, eliminating silent abuse.
- Full auditability is provided by session recordings that survive even if the underlying IAM role is compromised.
These outcomes would disappear the moment hoop.dev is removed from the path; the IAM role alone cannot provide approval workflows, masking, or replayable logs.
FAQ
Can I use existing IAM roles without creating a new one for the gateway?
No. The gateway requires a dedicated role so it can map the session to a specific Kubernetes RBAC binding and enforce just‑in‑time approvals. Sharing a role with human users would bypass the enforcement layer.
Does hoop.dev store any credentials?
The gateway holds the IAM role credentials only in memory while the session is active. Agents never see the raw secret, and the credentials are never persisted to disk.
How do I integrate this with my CI/CD pipeline?
Configure the pipeline to request an OIDC token for the service account that runs the job, then point the job’s kubectl commands at the gateway endpoint. The pipeline will automatically benefit from approval, masking, and recording without code changes.
Ready to try it yourself? Contribute or run a demo from the open‑source repository: https://github.com/hoophq/hoop.
