Overprivileged NHI with admin it never uses

The scenario

An image-processing service runs in a Kubernetes cluster and needs to read uploads from one bucket, write thumbnails to another and publish a message when it is done. During the original rollout the pod kept failing with permission errors at two in the morning, so the on-call engineer attached the account's administrator policy to the workload role to get the release out, with a comment that said tighten later. Later never came. The service now runs on forty nodes, belongs to a team that inherited it in a reorganisation, and authenticates with a role that can create users, change network rules and delete every bucket in the account.

In eleven months of logs the workload has called exactly six API operations. The several thousand others it is entitled to call have never been used, which means a compromise of the container image, a dependency or the node it runs on hands an attacker administrator rights that the workload itself has no use for.

Why it happens

• Permissions are granted under deadline pressure and never revisited. A failing deploy is urgent and visible; a policy that is too wide is invisible until something goes wrong.
• Declared policy and actual behaviour live in different tools. IAM shows what is allowed, logs show what is done, and nobody compares the two per identity.
• Wide roles get reused. A role that works for one workload is attached to the next because it already works, so overprivilege spreads by copy and paste. OWASP's Non-Human Identities Top 10 names both halves of this: NHI5, overprivileged NHI, and NHI9, NHI reuse.
• Least privilege has no owner. Shrinking a policy risks breaking something and rewards nobody, so every incentive points at leaving it alone.

How Trustivan helps

• Compute effective permissions, not declared ones. The identity graph computes an upper bound of what the workload role can reach from its trust relationships, group membership and inline policy statements. Managed policy documents are not read, and Deny is not evaluated.

  Available

• Compare entitlement with observed action. Setting the six operations the workload uses against the thousands it holds needs permission-usage facts, which no connector collects yet.

  Future capability

• Draft a least-privilege policy from evidence. A scoped policy proposed from observed actions, with the log window that justifies every statement, needs the same facts.

  Future capability

• Show blast radius before and after. The graph shows what the workload can reach today, every bucket and role on its path, as an upper bound. Modelling what remains once a proposed policy is applied is a future capability.

  Available

• Keep the owner attached to the decision. The inheriting team sees the finding and the evidence in one place, and a policy exception, approved by a second person and scoped with an expiry, is recorded against the identity.

  Available

What the evidence looks like

An overprivilege finding is only useful if it names the gap precisely and shows the logs behind it. Illustrating the problem, for the thumbnail workload:

Related capabilities

• Access Intelligence — effective access, as an upper bound, and access paths computed on the graph
• Effective Access — an upper bound of what an identity can reach, across trust and inline policy
• Blast Radius — the resources exposed if this identity is compromised
• Posture Management — high-impact access and ownership gaps as tracked findings
• Cloud environments — workload roles, federation and policy evaluation across accounts