Understanding secrets vs. service accounts: Best practices for security

TL;DR

Secrets give access, while service accounts define who should have that access. Secrets are best for short-lived, low-risk use cases like local development or prototyping. Service accounts group and scope secrets for production environments, making it easier to enforce least privilege, rotate credentials automatically, and audit access at scale. Together, they form a scalable foundation for secure, maintainable authentication across your infrastructure.

Secrets sprawl occurs as organizations grow: every new instance, every new employee, and every third-party product increases the number of secrets the team must manage. Without a clear way to organize them, coordination of secrets quickly becomes unwieldy.

One effective way to handle secrets management is to employ the use of service accounts. Service accounts are not secrets; rather, they are an identity that aggregates secrets for easier management.

In this post, we will differentiate between secrets and service accounts and show you how to leverage both to best secure your infrastructure.

Secrets vs. service accounts: What’s the actual difference?

Secrets work like a key works in a lock, providing access to anyone who possesses the secret. Service accounts are identities that describe an access pattern, and that pattern is used to assign secrets to the service account.

Consider an office complex with secured badge access to extend the key example. Each door in the building is like a secret, and every employee must decide whether to provide access(or not provide access) to each door. In a two-room office with five employees, this might not be an issue, but what happens as the team scales to hundreds of employees across several buildings?

With thousands of possibilities, providing 100% accurate access is impossible. Jane may suddenly find that she has lost access to the cafeteria at lunch time, and HR might accidentally have access to the IT closets. The same thing happens with secrets: it’s impossible to correctly scope individualized access via secrets 100% of the time.

Service accounts create logical groupings of secrets

To simplify matters, service accounts are generated. These accounts describe patterns of use and grant access based on those patterns. In our office scenario, a few sample service accounts might be:

• Employees: Can access all buildings from 9–5, Monday–Friday.
• Building 1 employees: Given 24/7 access to Building 1.
• IT closets: Only employees in the IT group have access.
• CEO office: Only the CEO has access.

A service account provides grouped, least privilege access to areas of the building. When a user attempts to open a door, two calls are made: one call to see if the user is in a service account associated with the door, and if authenticated, a second call with the authentication key to open the door.

The front door of Building 1 “secret” would be leveraged by many access “service accounts.” For example, two of them might be all employees, and Building 1 employees. The same secret is used, but based on the access requirements, the privilege is modified. If it is 10 AM, all employees are granted access. At 5:10 PM, only Building 1 employees can enter.

The same approaches described above can be used to organize access of application secrets into service accounts. Rather than assigning secrets to each CI-CD runner, the CI-CD runners are assigned service accounts that provide access to the secrets required:

• ci-cd-runner-dev
• ci-cd-runner-staging
• ci-cd-runner-prod

Databases might have several service accounts that have access, each with different levels of access. Imagine a database of payment data. Not every connection to this database requires the same level of access:

• Purchasing service: Can insert new fields into the sales records.
• Shipping service: Can read shipping address and items to be shipped, but cannot see(or modify) purchase details.
• Billing service: The billing service can read sales data and pricing information, but cannot see shipping details.
• Reporting service: Can read aggregated data, but is unable to retrieve individual account information.

Using service accounts as roles to determine which services have access to tooling ensures that least privileged access is enforced and makes it easy to group access for new tools that need connectivity.

The use of different service accounts makes auditing access easier. Secret rotation is simplified, the service account just asks for a secret and is given the new one, without any work on the developer side.

Using a service account abstracts credentials away from code and developers, simplifying access rules, and rotation of secrets.

Best practices for using secrets vs. service accounts

When should developers use secrets vs. a service account? Secrets are best used for quick, simple access to a service. This is perfect for a short-lived service that might run locally or when prototyping a project in a development environment. In production, they might be used for a low-risk credential that can be easily revoked without downtime.

• Use secrets when:
  • Prototyping: Local and dev environments.
  • Risk is low: A free weather API is unlikely to leak sensitive information.
  • Dynamic secrets: Secrets that can be used just once, or for extremely short periods of time.

But for services that are long-running, require scoped access, and regular credential management, service accounts are the way to go. By grouping and organizing secrets into service accounts, it becomes easier to manage who can access resources.

• Use service accounts for:
  • Long-running services
  • Scoped access
  • Production services

Generally, teams will require access to the same resources at the same permission levels. Using the building access management example: if Jane's group gets reassigned to Building 3, it is a matter of changing access to two service accounts (removing employee_building_1 and adding employee_building_3) for each employee, rather than changing access on hundreds of individual doors.

What goes wrong when you choose the wrong access management implementation

Effective secrets management revolves around providing the correct access to identities (whether machines or human users) in a secure way. Imagine a team of developers who are using a secret to access an AWS S3 bucket. A developer accidentally exposes the secret in a GitHub commit. He quickly realizes his mistake and rotates the secret, but now he must inform the rest of the team about the new secret, and they must update their configurations to continue developing.

If the team had been using a service account, the process of rotating the secret is abstracted by their service account. The other developers on the team use the service account to get the secret, and are completely unaware that the underlying secret was rotated.

But what happens if a service account credential is exposed? If an attacker gains access to a valid service account, they could pose as that identity. However, in order to access the secrets of the service account, the attacker needs to know where the secrets are stored and how to request the secrets. This is an important nuance: unlike an exposed secret, the attacker is not explicitly granted access, but only has the opportunity to access services. This obfuscation is a further protection provided by service accounts.

Secrets management: Secure and scalable patterns for modern teams

Modern teams need approaches to authentication and secrets management that are scalable, secure, and maintainable across environments. To best do this, teams should use service accounts as primary identities for all actions: CI/CD, automation, services, etc. Each service account is properly scoped with least privilege permissions to fit the needs of the account. Credentials can be regularly rotated without disruption, as they are never stored in the service account.

Secrets should only be utilized for short-lived processes like scripts or temporary jobs. All secrets (whether used discretely or as a member of a service account) should be managed in a secrets management solution like Doppler. This makes it easier to issue, rotate, and revoke the secrets.

All secrets and service accounts should be separated by environment to prevent secrets leakage. Naming conventions should be consistent to make auditing and rotation easier. Most importantly, all access must follow role-based access control, providing just the needed access rights for the role.

Service accounts abstract access patterns

As cloud deployments grow and become more complex, the number of secrets grows exponentially. While teams know the importance of storing secrets securely, the administrative tasks of deploying, rotating, and managing said secrets are overwhelming. Using secrets management solutions like Doppler simplifies many of these tasks, including defining least privilege and access management for each secret.

To further abstract secrets usage and simplify large scale secrets management, teams should employ service accounts to group secrets by usage patterns. Service accounts make it easier to grant perfectly scoped access to services, while abstracting away the need for code to directly store secrets. This approach not only makes code more secure, but it also makes it easier for teams to rotate or update the underlying secrets seamlessly without service interruptions.

The choice between service accounts and secrets is not an either/or. It’s about choosing the correct pattern for the job, and it depends on the scope and lifecycle of the secrets in use.