Best Practices for Investigating Service Account Key Origins and Usage

Read full article here:  https://www.p0.dev/blog/service-account-key-origins/?utm_source=nhimg

Service accounts are the backbone of cloud automation, but the keys tied to them often become one of the weakest links in enterprise security. A recent P0.dev article sheds light on how to investigate where service account keys come from, how they are used, and what organizations can do to lock them down.

Why Service Account Keys Are a Risk

Unlike user credentials, service account keys can be downloaded and shared without traceability. Once a key is out in the wild, it’s nearly impossible to know who is using it. For Non-Human Identities (NHIs) such as workloads, scripts, and automation pipelines, this lack of visibility turns service account keys into powerful, unmanaged secrets.

 Key Highlights

1. Finding the Origins of Keys

• Audit logs (CreateServiceAccountKey) record who created a key, giving security teams a way to trace its origin.
• This helps identify whether a key was created by a developer, an automated pipeline, or even through risky manual processes.

2. Tracking Impersonation

• Audit logs also reveal impersonation chains using serviceAccountDelegationInfo.
• This is critical for understanding whether actions came from humans or other service accounts.

3. Analyzing Usage Patterns

• While you can’t pinpoint who used a key, logs capture IP addresses tied to requests.
• Combined with monitoring metrics, this provides visibility into how keys are being leveraged across environments.

4. Leveraging Monitoring Metrics

• Google Cloud exposes authentication metrics that distinguish between key-based logins and impersonation-based access.
• These metrics allow teams to spot risky patterns and enforce stronger controls.

Recommendations & Best Practices

1. Audit & Investigate

• Log key creation events and query who created them.
• Trace impersonation chains to distinguish between human-initiated and automated service account actions.
• Review IP addresses tied to key usage to contextualize where and how keys are being used.

2. Secure by Design

• Remove unused service accounts, delete unused keys, and right-size IAM roles, avoid blanket permissions like "Editor".
• Prefer impersonation or attached accounts over user-managed keys for authentication. Where keys are essential, minimize their use.

3. Policy Enforcement

• Implement organization-level policy constraints to disable key creation or uploads, enabling exceptions only when strictly necessary.
• Follow a zero-trust mindset: keys are high-risk, treat them like passwords.

Why This Matters for NHI Security

Service accounts are a prime example of Non-Human Identities (NHIs) that now outnumber human identities in most enterprises. If left unchecked, their keys can act as backdoors for attackers. The key takeaway from P0.dev’s research is clear:

Keys should be treated like passwords, risky, limited, and ideally replaced with stronger mechanisms such as impersonation and short-lived credentials.

By tightening controls around service account keys, organizations can reduce their exposure and build a more secure foundation for managing NHIs in the cloud.