What is secrets management?

Organizations increasingly use nonhuman identities to automate key business processes and workflows. These identities can include service accounts, continuous integration and continuous delivery (CI/CD) pipelines, containers, microservices and orchestration tools. They can also include robotic process automation (RPA)—software bots that mimic human actions—and, more recently, AI agents. 

Similar to human users, nonhuman entities need credentials, or “secrets,” to authenticate to systems and services and access organizational resources—often with elevated privileges. For example, an automated backup process might read confidential files and modify system settings.

For hackers, these privileged nonhuman accounts are high-value targets. They enable threat actors to abuse access rights to steal data and damage critical systems, all while evading detection. According to the IBM® X-Force® Threat Intelligence Index, hijacking valid accounts is the second most common cyberattack vector, representing 32% of all incidents X-Force responded to last year.

Secrets management systems help combat these cyberthreats, allowing organizations to create, control and secure the secrets nonhuman entities use to access IT resources. With secrets management tools, IT teams can protect nonhuman credentials throughout their lifecycle, streamlining automated workflows while preventing data breaches, tampering, theft and other unauthorized access.

A secret is a digital credential contained within an application or service that permits nonhuman users to communicate with and perform actions on a service, database, application or other IT resource. Secrets help organizations strengthen their security posture by ensuring that only authorized users have access to sensitive data and systems.

Examples of secrets include, but are not limited to:

• Service account credentials: Service accounts allow apps and automated workflows to interact with operating systems. Service account credentials can include passwords, security tokens, Kerberos tickets and other secrets.
  
  
• API keys: API keys allow users, apps and services to verify themselves to application programming interfaces (APIs).
  
  
• Encryption keys: Encryption keys allow users to encrypt and decrypt data.
  
  
• Authentication and authorization tokens: Tokens, such as those used in the OAuth protocol, are pieces of information that can verify a user’s identity and determine the specific resources it can access.
  
  
• SSH (Secure Shell) keys: SSH keys are used by SSH servers to identify a user or device through public-key cryptography.

• PKI certificates and private keys (SSL/TLS/mTLS): Certificates issued by a certificate authority and their associated private keys authenticate endpoints and establish encrypted SSL/TLS certificates and connections, including mutual TLS (mTLS) authentication.

• Arbitrary secrets: Sensitive data, including any type of structured or unstructured data that can be used to access an application or resource.

• Connection strings: A string of text that contains the instructions a computer program needs to connect with a data source, including databases, files or spreadsheets.

• Other cryptographic keys: These can include hash-based message authentication code (HMAC) keys, code-signing keys and other private keys used for signing or verification.

Secrets management is a critical security solution that helps organizations securely store, control and rotate sensitive credentials and other secrets, such as passwords, API keys and tokens. 

It is one of four core capabilities of privileged access management (PAM), a subset of identity and access management (IAM) that focuses on securing privileged accounts and users.

The other three capabilities of PAM include:

• Privileged account and session management (PASM), which handles privileged account lifecycle management, password management and session monitoring. 
  
  
• Privilege elevation and delegation management (PEDM), which involves automatically evaluating, approving and denying privileged access requests. 
  
  
• Cloud infrastructure entitlement management (CIEM), which oversees permissions and entitlements in cloud computing environments.

Secrets management is important to the DevOps methodology, which emphasizes automated, continuous software development and delivery.

DevOps teams often use multiple configuration management or orchestration tools to manage entire digital ecosystems, workflows and endpoints. The tools often use automation and scripts that require access to secrets to initiate. Without an enterprise-grade secrets management service, haphazard use of secrets might increase system vulnerability.

Many organizations integrate secrets management functions into the CI/CD pipeline. This helps ensure that all the moving parts—developers, tools and automated processes—have secure access to the sensitive systems they need when they need it.

Secrets management is considered a core component of DevSecOps, an evolution of the DevOps methodology that continuously integrates and automates security throughout the DevOps lifecycle.

The secrets management process typically relies on secrets management tools. These tools, which can be deployed on-premises or as cloud services, can help centralize, automate and streamline the creation, use, rotation and protection of secrets.

Both commercial and open-source secrets management solutions are available. Open-source options include Infisical while commercial options include CyberArk Conjur (which also has an open-source edition) and HashiCorp Vault (from HashiCorp, an IBM company).

Some common capabilities of secrets management tools include:

• Centralized and standardized secrets management
• Dynamic secret creation and automated secret rotation
• Access controls
• Activity monitoring and auditing

With an enterprise-grade secrets management service, organizations can manage multiple types of secrets in a single pane of glass.

Instead of leaving individual users to manage secrets in small silos, secrets management solutions can store secrets in a secure, central location called a “secrets vault.”

When an authorized user needs access to a sensitive system, they can obtain the corresponding secret from the vault. The secrets management tool can automatically verify and authorize the request and release the secret needed to authenticate for the workflow.

Standardization can help prevent secret sprawl. Secret sprawl is when secrets are stored in various places throughout an organization, often hardcoded into applications or as plain text in a shared document. Secret sprawl makes it hard to protect secrets from malicious actors and track how secrets are used.  

Secrets created in a secrets manager can be either static or dynamic. A static secret is a secret that stays valid for a long time, usually until it is manually changed or hits a predetermined expiration date.

In contrast, a dynamic secret is created by the secrets manager on demand, at the moment it is needed. Dynamic secrets expire fairly quickly. They can even be single-use.

A use case for a dynamic secret would be to protect a confidential resource—such as a database or cloud environment like AWS or Microsoft Azure—by dynamically generating API keys each time that resource is read or accessed. This helps ensure that malicious actors cannot steal and reuse API keys.

Many secrets managers can also automate secret rotation—that is, the act of changing secrets regularly. Secret rotation can be automated on schedule or on demand without the need to redeploy or disrupt applications. Time-to-live (TTL) or a lease duration can be defined for a secret at its creation to shorten the amount of time the secret exists.

Secrets can be granted only to specific entities or groups to organize and tighten access. Access to secrets is often granted by using the principle of least privilege—that is, each process is granted only the most restrictive set of privileges needed to perform a task. Users can access only those secrets that are required to perform their authorized tasks.

Zero trust architectures—which “never trust, always verify”—often govern access to secrets management systems. This helps ensure that every request for a secret is authenticated and authorized, even if it originates from inside the network.

Many secrets managers can track how users and applications interact with and use secrets to verify that secrets are handled appropriately throughout their lifecycles. This allows the organization to conduct near real-time monitoring of secret access events, including authentications and authorizations to the secrets manager.

Secrets managers can quickly deny unauthorized attempts to view or use secrets and revoke access when needed. This can help enable faster remediation before hackers, insider threats and other bad actors can cause damage.

A powerful secrets automation tool will retain detailed audit logs that track user authentication and secret access events.

Secrets monitoring is often much easier to achieve once an organization begins using dynamic secrets automation tools. These detailed audit trails help validate approved use of secrets or detect and track down potential threats.

Beyond using secrets management solutions, many organizations follow common core practices in their secrets management processes. These practices include:

• Secrets are generated, stored and accessed within their appropriate environment (for example, separate dev, test and production environments). Some organizations use different secrets management tools for each environment. Others use one central solution and isolate each environment’s secrets in a dedicated segment. The secrets never leave their environments and are secured by using strict access control measures.
  
  
• User access to secrets is granted at the minimum level required for any user to fulfill their responsibilities. Overentitlement—whether intentional or not—can lead to data breaches.
  
  
• Secrets are rotated regularly in accordance with system requirements.
  
  
• Users do not store secrets in source code, configuration files or documentation.
  
  
• Security policies can be enhanced by requiring encryption of all sensitive data. The encryption keys can be protected with a key management service (KMS).
  
  
• The organization continually monitors secrets, with audit logs tracking every request: who asked for the secret, for which system, whether the request was successful, when it was issued or retrieved, when it expired and when and if the secret has been updated. Anomalies should then be promptly investigated. 

As IT ecosystems become more complex, secrets management becomes increasingly difficult to control effectively. Common secrets management challenges can include:

Decentralized ecosystems where admins, developers and users manage their secrets separately can introduce risks, as security gaps and secrets use might not be properly monitored or audited.

Centralized secrets management solutions can offer organizations more visibility into and control over secrets.

When passwords or other secrets are embedded as plain text in source code or scripts, attackers can easily discover them and use them to access sensitive information.

Hardcoded secrets can appear in many places, including CI/CD toolchains, code repositories, Internet of Things (IoT) devices, container orchestration platforms such as Kubernetes, application servers, vulnerability scanners and robotic process automation (RPA) platforms.

Regular rotation of secrets can help prevent theft and abuse, but rotation can be inconsistent or ineffective without a secrets management system. If a secret remains unchanged for too long, a hacker might be able to unlock it by trial-and-error guesses or a brute-force attack.

The longer a password is used, the more users have access and the greater the chance of a leak.

Growing IT systems can lead to secret sprawl, with secrets spread across many siloed parts of the system. Secret sprawl can be especially concerning in hybrid multicloud ecosystems, where organizations mix public and private cloud environments delivered by multiple cloud providers.

Organizations might have thousands, even millions, of secrets across all their cloud-native applications, containers, microservices and other IT resources. This sprawl creates a massive security burden and expands the potential attack surface.

Across services, visibility might be limited, and secret management can quickly become unwieldy if tracked manually or by disparate systems. The lack of a centralized secrets management service might make enforcing proper secrets hygiene more difficult or impossible.

When an organization lacks a secrets management system, secrets might be shared manually—such as through emails or texts—where threat actors can intercept them.