Kubernetes Access Auditing: Knowing Who Did What and When

The pod was gone. No one admitted touching it. You need to know who accessed what, and when, in Kubernetes.

Kubectl itself does not log historical access. It is a client tool, not an audit system. If you want hard evidence of actions—who ran a command, which resource they touched, and at what timestamp—you must enable Kubernetes auditing and configure your API server to record events.

Start with the Kubernetes audit log. Enable --audit-log-path on the API server and set rules with --audit-policy-file. The audit policy defines which verbs, resources, and users to track. For example, log every get, list, create, update, and delete for critical namespaces. Use user, verb, resource, and stage fields to pinpoint the request.

Once enabled, you can use kubectl to query resources, but the audit log is where truth lives. Search the log by user or resource name. Combine it with jq or grep for quick filtering. The entry will show the username or service account, the exact object, and the UTC timestamp when it happened.

For cluster-wide visibility, push audit logs to a central system—Elasticsearch, Loki, or cloud-native logging services. Index by user.username and requestURI to answer the question: Who accessed what? When? This works for debugging, compliance, and security investigations.

RBAC complements auditing. kubectl get clusterrolebinding, kubectl describe rolebinding, and kubectl auth can-i reveal who can access what. Combined with audit logs, you get both capability and actual recorded actions.

Without auditing, you are blind. With it, you have a timeline you can trust.

Want to skip the manual setup and see access auditing live in minutes? Try hoop.dev—streamlined Kubernetes visibility, with real-time access tracking built in.