How do you detect Kubernetes service accounts being created or modified?

What to watch in cluster audit logs

kubernetes service account are usually created or changed through the API server, so audit logs are the best place to detect those events without guessing from workload behaviour alone. Focus on object creation, patch, and update events for service account resources, then correlate them with who made the change, from which namespace, and whether the change happened in an expected deployment window.

A useful detection rule should not stop at “a service account was updated.” The higher-value signal is whether the change altered the account’s security posture, for example new annotations, automount settings, token-related settings, or references that affect how pods authenticate. Those changes matter because service account objects are part of the pod-to-API trust path, not just metadata.

Where Kubernetes audit data is already part of your detection stack, use it as the primary source for service account change visibility and then enrich it with namespace, controller, and workload ownership context. NHI Management Group’s Kubernetes NHI Security Guide covers service accounts, RBAC, projected tokens, and audit logging in the same operational path.

Which changes are most suspicious

The most important thing to compare is not only “did the object change?” but “did the change expand what the account can do?” An added role binding, a broader cluster role binding, or a new annotation that changes token behaviour can materially increase access even when the service account name stays the same.

Suspicion should rise when the service account is created in an unusual namespace, is attached to a workload that does not normally use one, or appears without a matching deployment change. Changes made by an unexpected user, automation pipeline, or controller deserve extra scrutiny because legitimate service account administration should be tied to a known owner and change process.

Changes to service account permissions are especially important because they can be used to turn a normal pod into a much more capable API client. The Service Account Security Guide is useful when you need to distinguish ordinary service account administration from changes that create overprivilege.

How to confirm whether the change is real risk or expected administration

Start by checking whether the service account is linked to a real workload owner, a known deployment pipeline, and a namespace that matches the application’s normal operating model. If those links are missing, the event is often more than a harmless metadata update, because you may be looking at shadow automation or an identity that was introduced outside standard change control.

Then inspect the workload chain around the account: which pods use it, whether those pods were redeployed at the same time, and whether the new permissions are actually required for the application’s current function. This matters because a service account can be modified long before its broader permissions are noticed in runtime activity.

For a broader view of how service accounts behave across platforms and why static credentials are often the wrong model, Ultimate Guide to NHIs is the right parent concept, while Cloud Workload Identity Guide helps when the Kubernetes identity is federated to cloud roles or temporary credentials.

Risk and Threat Considerations

Service account creation and modification are high-value events because they can quietly expand pod access to the Kubernetes API or to downstream cloud and platform resources. If an attacker can create a service account, bind extra permissions, or alter token-related settings, they may gain a durable way to act inside the cluster with the workload’s apparent legitimacy.

Failure mechanism: Attackers or rogue administrators abuse the normal service account lifecycle, then pair the new or modified account with broader RBAC permissions, altered annotations, or changed token behaviour to obtain access that looks operationally normal.

Impact: Pods can inherit more API power than intended, enabling secret access, workload impersonation, lateral movement, and persistence inside the cluster or into connected systems.

Practitioner Guidance

What to verify: Confirm that every service account change has an owner, a purpose, and a matching workload change record. If you cannot tie the change to a known application or deployment, treat it as a security event, not a routine configuration update.

What to measure: Track the number of service account creations and permission changes that occur outside approved deployment windows, because unexpected timing is often the first sign that the change path is being abused.

Practitioner takeaway: The most reliable detection pattern is not raw change volume, but whether the change meaningfully increases a pod’s effective authority without a matching business or deployment justification.

Related resources from NHI Mgmt Group

• How should teams reduce the risk of orphaned service accounts and stale tokens?
• How do you clean up unmanaged Microsoft Entra accounts created through self-service sign-up?
• How do you detect accounts created and deleted within a short time in Microsoft Entra ID?
• How should teams govern Kubernetes service accounts as NHI identities?