It’s a common misconception that simply assigning a service account to a bot automatically satisfies least privilege. In reality, a non‑human identity can inherit far more permissions than it ever needs, and those excess rights become a silent attack surface.
In Kubernetes, non‑human identities include service accounts used by CI/CD pipelines, automated operators, and AI agents. They are created once, then referenced by many jobs, scripts, or controllers. Because they are not tied to a person, the usual “ask the user” checks disappear, and the responsibility for limiting scope shifts entirely to how the identity is configured.
The principle of least privilege demands that each identity receive only the permissions required for its specific task. For a human, this often translates to role‑based access controls that are reviewed regularly. For a bot, the same discipline must be applied, but the enforcement points differ: the bot’s token is presented to the Kubernetes API server without any intermediate guardrails.
Many organizations start with a single, highly‑privileged service account that all pipelines share. The account may have cluster‑admin rights, full read/write access to every namespace, and the ability to create or delete resources. Because the same token is reused, there is no visibility into which job performed which action, and any compromised pipeline instantly inherits the full blast radius of the account.
What is missing in this setup is a control layer that sits between the identity and the Kubernetes control plane. The RBAC rules on the API server still decide whether the request is allowed, but they do not provide per‑request approval, real‑time masking of sensitive fields, or session recording. The request reaches the target directly, leaving the organization without audit trails, without the ability to block risky commands, and without a way to enforce just‑in‑time elevation.
hoop.dev fulfills that missing control layer. It acts as an identity‑aware proxy that intercepts every kubectl, exec, or port‑forward request before it reaches the Kubernetes API server. By placing enforcement in the data path, hoop.dev can apply the least‑privilege checks that static RBAC alone cannot provide.
Setup – Engineers configure OIDC or SAML authentication so that each non‑human identity presents a short‑lived token. The token is mapped to a specific service account with the minimal set of RBAC roles required for its job. hoop.dev validates the token, extracts group membership, and enforces that the request originates from an authorized source.
The data path – Once authenticated, the request is forwarded through hoop.dev’s gateway. The gateway understands the Kubernetes wire protocol and can inspect each command in real time. It can require a just‑in‑time approval step for privileged operations such as creating ClusterRoles or deleting namespaces.
Enforcement outcomes – hoop.dev records every session, providing a replayable audit log that shows exactly which commands were run and what data was returned. It can mask secret values in responses so that logs never expose credentials. It can block dangerous commands, such as "kubectl delete --all", before they reach the API server. Because the gateway holds the credential, the underlying agent never sees the secret, reducing the risk of credential leakage.
These capabilities give organizations concrete evidence of how non‑human identities interact with Kubernetes. Auditors can see per‑session logs, approval records, and masked data outputs, which support compliance programs without claiming any certification. Teams also gain the ability to rotate service‑account keys frequently, knowing that any compromised token will be rejected by the gateway.
To try this approach, start with the getting‑started guide. The documentation walks through deploying the gateway, registering a Kubernetes connection, and wiring non‑human identities to OIDC. Because hoop.dev is open source, you can review the code and contribute improvements directly on GitHub.
For a high‑level overview of hoop.dev’s capabilities, see the product page.
Applying least privilege to non-human identities on Kubernetes
When a bot needs to deploy a Helm chart, grant it only the "create", "update", and "delete" permissions on the target namespace. When a monitoring agent needs to read pod metrics, give it read‑only access to the "metrics.k8s.io" API. By defining these narrow scopes in the OIDC token mapping and letting hoop.dev enforce them at request time, you prevent over‑privileged tokens from being misused.
FAQ
- Can hoop.dev enforce policies on existing service accounts? Yes. You map the existing account to a token that hoop.dev validates, then define per‑operation policies that the gateway applies.
- Does using hoop.dev add latency to Kubernetes commands? The gateway adds only a small network hop; the benefit of auditability and real‑time guardrails outweighs the minimal overhead.
- Is the solution compatible with existing CI/CD pipelines? Absolutely. Pipelines simply point their kubectl client at the hoop.dev endpoint instead of the API server, without changing the underlying job logic.
Ready to see the code? View the source on GitHub and start hardening your non‑human identities today.
