What breaks when Kubernetes access still depends on tickets and manual approvals?

Ticket-based access creates delays at exactly the moments teams need speed, such as incident response, deployment work, and emergency troubleshooting. It also adds administrative load for platform and security teams, introduces approval bottlenecks, and encourages workarounds. Over time, that friction pushes organisations toward broader standing access just to keep operations moving.

Why This Matters for Security Teams

Kubernetes access that depends on tickets and manual approvals creates a control model that is too slow for the system it is supposed to protect. Pods, jobs, controllers, and CI pipelines act on short timelines, while ticket workflows are built for humans, queues, and reviews. That mismatch encourages standing privileges, shared kubeconfigs, and “temporary” exceptions that quietly become permanent.

The real problem is not just delay. Manual approval paths do not scale to workload identity, ephemeral access, or incident response, and they rarely capture the full runtime context of what a service account or agent is trying to do. NHI Mgmt Group has repeatedly shown that organisations struggle to manage these identities at all, with the Ultimate Guide to NHIs noting that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Current guidance suggests that access must move closer to the request, not stay trapped in a ticketing queue. In practice, many security teams discover this only after engineers bypass the process to keep a deployment or outage from stalling.

How It Works in Practice

For Kubernetes, the better pattern is runtime authorization backed by workload identity, not human ticket trails. The access decision should be made when a pod, job, or automation requests a cluster action, using context such as namespace, service account, image provenance, destination cluster, time window, and the specific verb being requested. That aligns with the direction of the OWASP Non-Human Identity Top 10 and the control intent in NIST SP 800-53 Rev 5 Security and Privacy Controls, where least privilege and continuous enforcement matter more than one-time approval.

In practice, teams usually replace ticket-driven access with a combination of:

• Short-lived credentials issued just in time for the task, then revoked automatically.
• Workload identity anchored in cryptographic proof, such as OIDC-backed service identity or SPIFFE-style identity primitives.
• Policy-as-code evaluated at request time, so approval logic can consider namespace, labels, Git commit, deployment stage, and risk signals.
• Separate controls for break-glass access, with strict TTLs, audit trails, and post-incident review.

This matters because static RBAC alone cannot describe dynamic operator intent. A build job may need read access to one secret store for minutes, while a repair script may need temporary write access to a single namespace and nothing else. If the only path to access is a ticket, teams either wait too long or widen permissions to keep flow moving. The operational alternative is to let the platform issue constrained, ephemeral access for the exact action, then terminate it as soon as the task completes. NHI Mgmt Group’s Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it frames excess privilege and poor visibility as core exposure points, not side issues.

These controls tend to break down when legacy Kubernetes clusters depend on shared admin kubeconfigs, because the platform cannot reliably distinguish the workload, the human operator, and the emergency exception.

Common Variations and Edge Cases

Tighter access controls often increase operational overhead, so organisations have to balance speed against governance. There is no universal standard for this yet, especially where teams run hybrid clusters, older CI/CD tooling, or GitOps pipelines that were never designed for per-request authorization.

The most common edge case is break-glass access during an outage. Best practice is evolving toward time-bound elevation with mandatory logging and after-action review, but the approval path should be different from normal change tickets. Another case is multi-tenant platform engineering, where one approval model may be too coarse for development, staging, and production. In those environments, manual approvals often become ceremonial because operators already know the approval will be granted, which defeats the purpose of the control.

For organisations that need a stronger reference point, the 52 NHI Breaches Analysis shows how identity misuse and overbroad access patterns recur across incidents. The practical takeaway is simple: use tickets for human change governance, but use runtime policy for Kubernetes workload access. When teams keep asking humans to approve machine actions one by one, they end up protecting the process instead of the cluster.

Related resources from NHI Mgmt Group

• What breaks when access revocation still depends on manual ticket closure reviews?
• What breaks when application governance still depends on manual implementation and specialist knowledge?
• What breaks when identity workflows still depend on manual intervention for common access changes?
• What breaks when password migration still depends on manual exports and file deletion?