Service Account Permissions

Service accounts must be granted the minimum permissions necessary to perform their intended function. This foundational security principle limits the potential damage from credential compromise or software error.

• Scope Definition: Permissions should be scoped to specific APIs, resources (like a single database or storage bucket), and actions (e.g., read only, not read/write).
• Regular Audits: Permissions should be reviewed and pruned periodically to remove unused entitlements as service functions evolve.

Unlike user accounts, service accounts are designed for headless, programmatic authentication. They lack interactive login capabilities (like passwords for UI access) and are used by applications, daemons, or orchestration systems.

• Key-Based Authentication: Typically authenticate via long-lived API keys, JSON Web Tokens (JWTs), or X.509 certificates.
• Machine Identity: The account represents the machine or service, not a human, which simplifies audit trails (service-account-pipeline invoked API X).

The credentials for a service account should have tightly defined scope and expiration to reduce the risk window.

• OAuth 2.0 Scopes: When using OAuth, scopes (e.g., https://www.googleapis.com/auth/cloud-platform.read-only) explicitly limit what an access token can do.
• Short-Lived Tokens: Modern practice uses short-lived access tokens (minutes/hours) refreshed via a secure backend, rather than eternal API keys. Just-in-Time (JIT) access systems can grant permissions only for the duration of a specific task.

Permissions are commonly assigned through Role-Based Access Control (RBAC) or attached directly to resources.

• RBAC Assignment: A service account is assigned a predefined role (e.g., roles/cloudsql.client) that bundles necessary permissions.
• Resource-Based Policies: Some systems allow policies attached directly to a resource (e.g., a Cloud Storage bucket policy) that specify which service accounts can access it. This combines the authorization boundary (the resource) with the allowed principals.

Every action taken by a service account must generate an immutable audit log. This is critical for security forensics, compliance, and debugging automated workflows.

• Principal Identification: Logs must clearly record the service account identity (e.g., [email protected]).
• Action Detail: Logs should include the API method called, parameters, source IP, and timestamp. This creates a complete audit trail for all non-human activity.

Service account credentials are sensitive secrets that require secure, centralized management, not hard-coded in application files.

• Vault Systems: Credentials should be issued and rotated automatically by secret managers (e.g., HashiCorp Vault, AWS Secrets Manager) or workload identity platforms.
• Dynamic Credentials: Best practice involves the application fetching a short-lived credential from a secure manager at runtime, adhering to zero-trust principles for secure credential management.

The principle of least privilege is the foundational security doctrine that directly informs service account permission design. It mandates that a service account should be granted only the minimum permissions necessary to perform its intended function, for the shortest duration required. Violating this principle by granting overly permissive roles (e.g., Owner or Editor) dramatically increases the blast radius of a credential compromise. Adherence is achieved through fine-grained custom roles and regular permission audits.

Credential scoping is the operational practice of limiting the permissions embedded within or granted by a service account's credentials. This is a direct application of least privilege. Techniques include:

• Defining narrow IAM roles for the service account.
• Using OAuth 2.0 scopes to restrict token-based access.
• Employing permission boundaries in IAM systems to set a maximum allowable permission ceiling.
• Implementing short-lived credentials to minimize the exposure window of any granted permissions.

A service account audit trail is the immutable, chronological log of all authentication and authorization events related to that non-human identity. This is critical for security forensics and compliance. Key logs include:

• Authentication Logs: When the service account credential was used and from what source IP.
• Authorization Logs: Which permissions were checked and whether they were granted or denied for each API call.
• Admin Activity Logs: Changes to the service account's IAM roles or permissions themselves. Platforms like Google Cloud Audit Logs and AWS CloudTrail provide these capabilities, allowing security teams to detect anomalous behavior, such as a service account accessing resources at an unusual time or from an unexpected location.