Prevent leaked secrets

There is no single solution to prevent leaked secrets. While every organization is different, there are common practices you can apply to your organization.

This section outlines essential strategies to safeguard your secrets:

Separation of duties: Distribute security responsibilities across teams
Restrict access to secrets: Implement least-privilege access controls
Dynamic credentials: Use short-lived, automatically rotating credentials
Single sign-on (SSO): Centralize authentication across systems
Centralized secret management: Store and retrieve secrets from an secrets management platform
Secure remote access: Apply zero-trust principles to network access

Separation of duties

Separation of duties (also known as segregation of duties) is a security practice that reduces the risk of a data breach by ensuring no single person has control over all aspects of a workflow. Separation of duties may be required by government or industry regulations, for example, Sarbanes-Oxley (SOX) in the United States.

A common implementation of separation of duties is to have separate teams responsible for software development, testing, building, and releasing the software to production. This separation ensures no single person can introduce security issues into the workflow. For example, if a developer attempts to introduce a bug to steal fractions of a penny from every transaction, stages in the software development lifecycle would discover the bug.

Restrict access to secrets

When managing secrets, a good practice is to restrict access to secrets, even from the security team, while allowing them to manage and support the secrets management platform. This separation ensures that the security team does not have access to all stored secrets.

Zero trust is a security model that assumes that all users, devices, and networks are untrusted until proven otherwise. Consider remote access solutions — conventional remote access solutions such as virtual private networks (VPNs) typically allow access to the entire network, once authenticated. This potentially exposes systems and data to unauthorized access.

When using a zero trust model for remote access, users and devices have access to the specific resources required. This helps to reduce the risk of a data breach because access to resources is restricted.

HashiCorp resources:

External resources:

Dynamic credentials

Dynamic credentials are short-lived credentials generated on demand and valid for a limited time. Dynamic credentials are useful in scenarios where SSO integration is not available. Because these credentials are valid for a limited time, the risk of exposing the secret is reduced.

Workload identity federation (WIF) creates a trust between systems. Once you complete the WIF configuration, a service like Terraform or Vault creates dynamic credentials in the target platform. Compare this to conventional methods where you might provision a long lived service account with a key or password. These accounts still need to managed, and rotated. With WIF, there is a trust between the systems so there is no risk to the service account secret being leaked. The service that provisions the dynamic credential revokes it when the workflow is complete or TTL expires.

Where SSO and WIF diverge is that WIF uses the trust relationship to provision temporary, dynamic credentials. These credentials have a short TTL, so there is a limited risk if they become exposed. Credentials are managed by the configured services, so there is no need to revoke, renew, or replace the credentials.

HashiCorp Vault generates dynamic credentials for a variety of systems, including AWS, Azure, GCP, HCP Terraform, and several database platforms.

Vault Enterprise supports WIF integration with AWS, Azure, and GCP. Using WIF, you can configure the cloud provider auth method, or secrets engine without static service accounts.

You can configure your application to request dynamic credentials from Vault before connecting to a cloud service provider, or backend database. You can also use the HCP Terraform secrets engine to generate dynamic credentials for different Terraform providers. This allows Terraform to provision the defined resources without needing to store static credentials.

HashiCorp resources:

Use single sign-on

You can use single sign-on to prevent leaking secrets. Single sign-on (SSO) is a process that allows users or workloads to authenticate to different services and applications using a single set of credentials. Common identity providers used to configure SSO include Microsoft Active Directory and Okta.

Having different logins for different systems is a common source of process friction. People, teams, and workloads often need to use different authentication workflows. This process friction causes frustration and often leads people to try to circumvent security processes.

NIST SP 800-63 Digital identity guidelines and NIST SP 800-171 recommend using federated identity providers, and centralizing authentication to reduce security risks.

When reviewing tools and services to use for scanning for leaked secrets, ensure these services support SSO. This will limit friction in adopting the tools.

HashiCorp tools like HCP Vault Radar, HCP Terraform, Vault, and Boundary support SSO. SSO lets you adopt HashiCorp tools and integrate with your IdP. Your security team can access Vault Radar in the HCP Portal, and Vault with the same credentials.

For workloads that require access to Vault, there are several auth methods that allow authentication from trusted platforms such as AWS, Azure, GCP, and Kubernetes.

HashiCorp resources:

External resources:

Centralize secret management

Once you have a process in place to identify leaked secrets, you should verify whether the secret is in use and ensure that you are managing it effectively moving forward. These two steps are important to manage properly so you do not inadvertently rotate a secret used by another system and bring those services down.

When you identify a leaked secret, your solution should determine if the secret is in use and whether it's in your secret manager. Determining whether it's in use and where it's located helps in the next phase of the process — remediation. If the leaked secret is not stored in your secret manager, add the secret before you begin the remediation process.

Another important feature for centralizing secrets management is the ability to copy or sync secrets to other systems. The ability to sync secrets helps with workloads or platforms that may be isolated, or systems that you cannot update to support a centralized secrets management solution.

HashiCorp Vault is a centralized secrets management and security solution with several deployment options. If you are new to secrets management, you can start by storing secrets as key-value pairs, and update your workflows to read the secret directly from Vault. As your secrets management process matures, you can use short-lived, dynamic credentials which are valid for a specified period of time. This further limits the effect if you do leak a secret because Vault will automatically revoke it after the specified time, or you can manually revoke it and request new credentials.

You can prevent storing secrets in your code by securing your secrets in a centralized secrets management system such as Vault, and then referencing these secrets in your code. The following Python example shows how to use Vault client libraries inside your application code to store and retrieve secret values.

read_response = client.secrets.kv.read_secret_version(path='my-secret-password')
password = read_response['data']['data']['password']

HashiCorp resources:

External resources:

OWASP Secrets Management Cheat Sheet

Secure remote access

Securing remote access to your systems is an important part of a defense-in-depth strategy. Traditional remote access solutions such as VPNs often provide access to entire segments of the network, potentially exposing system to users and workloads that do not need to connect. This access is anti-pattern to modern security practices such as separation of duties, and zero trust.

Another challenge is with modern deployment practices. Workloads are often ephemeral, meaning they are created and destroyed as needed. Given the ephemeral nature of modern deployments, this adds challenges to managing remote access and authentication to these systems.

HashiCorp Boundary is a remote access solution that follows zero trust principles and supports dynamic host catalogs which is useful for ephemeral workloads. Boundary lets platform teams specify only the systems that a user requires access to instead of the entire network. This reduces the risk of a data breach and allows organizations to prove compliance relative to separation of duties.

Dynamic host catalog plugins for major cloud providers automate the discovery and configuration of Boundary. As workloads are provisioned and destroyed, the Boundary host catalog remains up to date with the current state of the environment.

Boundary also supports credential brokering and SSH certificate injection. This allows users to connect to systems they have been granted access to without having to pass credentials through the CLI or Boundary Desktop application. In addition to Boundary native credential management, you can also integrate Boundary with HashiCorp Vault. This integration allows you to take advantage of Vault dynamic credentials, limiting the total lifetime of the credential used for a given session.

HashiCorp resources:

Next steps

In this section of how to manage leaked secrets, you learned about how to prevent leaked secrets in your organization. Managing leaked secrets is part of the Secure systems pillar.