HashiConf 2025 Don't miss the live stream of HashiConf Day 2 happening now View live stream
Well-Architected Framework

Prevent leaked secrets with access controls

Organizations face constant risk from leaked secrets and exposed credentials. Insider threats cause a substantial amount of data breaches, and shared credentials increase the breach impact across environments. Identity and access management (IAM) strategies limit who can view, modify, and use secrets by implementing separation of duties, least-privilege policies, single sign-on authentication, and zero trust principles.

Prevent secret leaks with the following access control strategies:

  • Separation of duties: Distribute security responsibilities across teams
  • Least-privilege access: Grant access only to required secrets
  • Single sign-on (SSO): Centralize authentication across systems
  • Zero trust network access: Apply identity-based access controls

Why implement access controls for secrets

Reduce insider threats: Organizations that grant broad secret access to users and teams face significant risk from both malicious insiders and accidental exposure. Without access controls, a single compromised account can expose all organizational secrets.

Implement compliance mandates: Regulations like SOX, PCI-DSS, and HIPAA require separation of duties and least-privilege access to sensitive data. Organizations must prove they limit secret access to authorized personnel only.

Discourage credential sharing: When teams share service accounts and API keys, you cannot trace secret usage to specific users or revoke access granularly. Sharing credentials makes incident response difficult.

Implementing access controls—separation of duties, least privilege, SSO, and zero trust access—reduces your attack surface by ensuring only authorized users and systems can access specific secrets.

Implement 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. Government or industry regulations like Sarbanes-Oxley (SOX) in the United States require separation of duties.

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.

Implement separation of duties for secret management with the following role assignments:

  • Security teams define and manage secret access policies
  • Development teams consume secrets through approved interfaces
  • Operations teams monitor secret access and usage
  • Audit teams review access logs independently

Separating these responsibilities ensures no single person can create, access, and audit secrets without oversight.

Restrict access to secrets with least-privilege controls

Apply least privilege principles when managing secrets by granting users and teams access only to the specific secrets they need to perform their jobs. This separation reduces risk by limiting who can view sensitive credentials.

Least privilege aligns with zero trust security models, which treat all users, devices, and networks as untrusted until you verify them. Traditional remote access solutions like virtual private networks (VPNs) violate least privilege by granting broad network access once you authenticate. Instead, grant users and devices access only to the specific resources they need for their work. This restriction reduces your attack surface and limits the potential damage from compromised credentials or insider threats.

Implement least-privilege secret access with the following practices:

  • Create role-based access policies that grant access to specific secret paths
  • Use namespaces to isolate secrets between teams and projects
  • Require approval workflows for access to production secrets
  • Regularly review and revoke unnecessary secret access
  • Audit all secret access attempts and policy changes

The following example shows a HashiCorp Vault policy that implements least-privilege access. The policy grants developers full access to development secrets while restricting production access to read-only:

# Development team policy - full access to dev secrets
path "secret/data/app/development/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

# Production team policy - read-only access to prod secrets
path "secret/data/app/production/*" {
  capabilities = ["read", "list"]
}

# Deny access to admin secrets
path "secret/data/admin/*" {
  capabilities = ["deny"]
}

The policy demonstrates separation by environment, development vs. production, and grants only necessary permissions for each role, and explicitly denies access to administrative secrets. This separation lets teams access only the secrets required for their work while preventing accidental or unauthorized access to sensitive credentials.

Use single sign-on

You can use single sign-on to prevent leaking secrets. Single sign-on (SSO) is a process that lets users or workloads 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.

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 enable authentication from trusted platforms such as AWS, Azure, GCP, and Kubernetes.

SSO for secret management provides the following benefits:

  • Users authenticate once with their corporate identity
  • Security teams manage access through a centralized identity provider
  • Access revocation happens immediately across all integrated systems
  • Audit logs connect secret access to specific user identities
  • Multi-factor authentication (MFA) applies consistently across all tools

Secure remote access with Boundary

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 systems to users and workloads that do not need to connect. This access violates 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 creates challenges for 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 lets organizations 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 lets users 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 lets you take advantage of Vault dynamic credentials, limiting the total lifetime of the credential used for a given session.

Zero trust access reduces secret exposure through the following mechanisms:

  • Eliminate shared credentials for system access
  • Provide session-specific credentials that expire automatically
  • Create audit trails that connect access to specific user identities
  • Prevent lateral movement if credentials become compromised
  • Support just-in-time access provisioning and deprovisioning

HashiCorp resources

Related WAF guidance:

Authentication and SSO:

Vault policies and access control:

Boundary for secure access:

External resources

Next steps

In this section of Managing leaked secrets, you learned how to prevent leaked secrets through access controls including separation of duties, least-privilege access policies, single sign-on authentication, and zero trust network access principles. Preventing leaked secrets with access controls is part of the Secure systems pillar.

Continue to the following document to complete your prevention strategy:

Edit this page on GitHub