What is a Service Account?

Definition

A service account is a non-human identity used by an application, service, script, or workload to authenticate to other systems and perform actions. Unlike user accounts (representing humans), service accounts represent software processes.

The term spans many platforms:

• Active Directory — service accounts (regular user accounts used as SAs), Managed Service Accounts (MSAs), Group Managed Service Accounts (gMSAs), delegated Managed Service Accounts (dMSAs).
• Google Cloud — Service Accounts (special principal type with @project.iam.gserviceaccount.com).
• AWS — IAM Users (sometimes for workloads), IAM Roles (preferred for workloads).
• Azure — service principals, managed identities.
• Kubernetes — ServiceAccount resource per pod/namespace.
• SaaS — vendor "API accounts" or "integration accounts."

In simple terms:

A service account is the identity an application uses to talk to other systems — like a person account, but for software.

---

Why It Matters

• SAs are everywhere — every app, integration, script, batch job has one or many.
• SAs typically have:
  • More permissions than typical users.
  • No MFA.
  • Less monitoring.
  • No active lifecycle.
  • Long-lived credentials that leak.
• SAs are top targets in modern breaches.

---

Types of Service Account

Active Directory

• User-based SAs — regular AD user, used as SA. Vulnerable to Kerberoasting if SPN registered.
• MSA — host-bound; auto-managed password.
• gMSA — group-bound; auto-managed; multiple hosts.
• dMSA — delegated; new (Server 2025); more secure replacement for legacy SAs.

Google Cloud

• SAs with @project.iam.gserviceaccount.com suffix.
• Authenticate via JSON key (deprecated for new) or impersonation / WIF.

AWS

• IAM users (legacy; not recommended for workloads).
• IAM roles assumed by workloads (preferred).
• IRSA for K8s.

Azure

• App registrations / service principals (OAuth apps).
• Managed identities (system-assigned / user-assigned).

Kubernetes

• Each pod has a K8s SA; permissions via Roles / ClusterRoles.
• Federated to cloud IAM via IRSA / GKE WI / AKS WI.

SaaS

• Salesforce Connected Apps.
• Microsoft 365 application identities.
• Vendor-specific "API users."

---

Common Risks

Kerberoasting (AD)

User-based SAs with SPNs vulnerable to offline password cracking.

Long-Lived Static Keys

GCP SA JSON keys; AWS IAM access keys; Azure SP secrets — leaked, never rotated.

Hardcoded Credentials

In code, configs, scripts, CI secrets.

Over-Permissioning

SAs granted Editor / Owner / SA Admin "for convenience."

Shared SAs

One SA used by many apps; audit attribution lost.

Orphaned SAs

Created by departed employees; never decommissioned.

Domain-Wide Delegation

Workspace SAs that can act as any user.

Misconfigured Federation

WIF pools with weak attribute conditions.

---

Real-World Examples

1. Kerberoasting Compromise

User SA for SQL Server had SPN; weak password (8 chars). Attacker requested Kerberos ticket; cracked offline; gained DB admin. Mitigation: gMSA / dMSA migration; long passwords; KAS armoring.

2. Leaked GCP SA Key

SA JSON key committed to GitHub; scanner found it; project enumerated. Mitigation: secret scanning + WIF migration + key rotation.

3. Over-Permissioned SA

CI SA had Project Editor for "deploy" use case. CI compromise enabled production database damage. Mitigation: scoped roles per service; least privilege.

4. Orphaned SA

SA created 5 years ago by a developer who left. Still active, in 23 IAM bindings. Discovered in audit. Mitigation: NHI lifecycle process; periodic review.

5. Domain-Wide Delegation Abuse

Workspace SA with DwD used by an automation script. Compromised script accessed any user's email. Mitigation: removed DwD; replaced with per-user OBO; HITL for high-risk use cases.

---

Best Practices

1. Inventory all service accounts across platforms.
2. Owner per SA (named human).
3. Per-app / per-purpose SAs — no sharing.
4. Federation / managed identity preferred over keys.
5. Eliminate static keys where possible; rotate when unavoidable.
6. Least privilege with quarterly review.
7. gMSA / dMSA in AD instead of user-based SAs.
8. No SPNs on user accounts if possible.
9. Strong passwords / no passwords (managed by platform).
10. Audit + anomaly detection on SA usage.
11. Lifecycle workflow — provisioning + decommissioning.
12. Compliance mapping.

---

Checklist

• Inventory of all SAs?
• Owners assigned?
• Per-purpose (no sharing)?
• Federation / managed identity preferred?
• Static keys minimized + rotated?
• Least privilege quarterly review?
• gMSA / dMSA in AD?
• No user-SAs with SPNs?
• Audit + anomaly detection?
• Lifecycle workflow?
• Decommissioning of orphans?
• Compliance mapped?

---

How Forestall Helps

Forestall continuously discovers, inventories, and risk-ranks service accounts across cloud, AD, SaaS, and Kubernetes — with prioritized remediation guidance.

---

Frequently Asked Questions

What's the difference between a service account and a user account?

User = represents a person; interactive auth + MFA. Service account = represents software; programmatic auth; no MFA.

Should I use gMSA over MSA?

Yes — gMSA supports multiple hosts and is more flexible. dMSA is even better when available (Server 2025).

Why are GCP SA JSON keys risky?

Long-lived, easily leaked, hard to rotate at scale. Modern best practice: WIF + impersonation.

What about Kubernetes SAs?

Use them; federate to cloud IAM via IRSA / GKE WI / AKS WI to eliminate static cloud credentials.

Should I share SAs across applications?

No — per-app SAs preserve attribution and enable least privilege.

---

Conclusion

Service accounts are the workhorses of modern automation — and one of the most-targeted identity surfaces. Inventory, assign owners, eliminate static keys via federation / managed identity, enforce least privilege, automate lifecycle, monitor anomalies, and migrate to modern alternatives (gMSA / dMSA in AD; WIF / managed identity in cloud). Done well, your service accounts become a managed asset rather than your environment's biggest unmanaged risk.