Secrets and credentials management is widely considered to be the most overlooked aspect of software development. Many teams struggle daily to organize and sync secrets between environments, with manually maintained .env files being one of the most common sources of frustration for developers and DevSecOps.
Not only does this impact developer productivity, but without a centralized data store with fine-grained access control and audit logs, secrets like APIs and login credentials are at risk of exploitation.
Security teams want developers to “shift left” and incorporate security best practices into the application development lifecycle and tooling. Still, too often, .env files fall into the “if it ain’t broke, don’t fix it” category” simply because it appears to be the best solution available.
The good news is that a relatively new breed of security infrastructure tooling known as “Secrets Managers” are here to make .env files and other insecure secrets storage practices a thing of the past.
In this article, we’ll unpack Secrets Managers, what they do, why they matter, and what to look for when choosing a Secrets Manager for your team and organization.
For example, a developer is working on an infrastructure-as-code solution that requires access to database credentials and API keys as part of the application deployment process.
A straightforward solution could be to store the required secrets in a plain text file that the deployment code can consume. The developer knows it’s not ideal, but it works, and they’re under pressure to finish the job so they can get back to shipping new features. At that moment, it’s the simplest solution. And sometimes, simplicity wins out, but for the wrong reasons.
Some organizations consider the simplicity of .env files to be its strength, but the underlying maintenance issues such as the manual syncing of changes between environments, as well as the security risk from unencrypted secrets storage on application servers, often go unnoticed or ignored.
In the same way, we learned that storing secrets unencrypted in application code was insecure; we need to apply that same thinking to the storage of unencrypted secrets on the file system.
This is why forward-thinking organizations are embracing Secret Managers, so let’s now focus on what they are and how they work.
Today, organizations depend on commercial, open-source, and internally developed applications, automated IT infrastructure, and DevOps methodologies to support innovation and business growth. Regardless of your development environment, every automation tool, script, and application you use consumes data of a sensitive nature in order to perform its job.
A Secrets Manager is a storage and management solution for storing any type of sensitive data your application requires, such as:
- Database credentials
- API keys
- SSH Keys
- TLS Certifications
A Secrets Manager provides a centralized source of truth that empowers organizations to securely and efficiently store and control access based on role, machine identity, environment, and other factors to apply the principle of least privilege.
Cybercriminals often seek to exploit vulnerabilities in plain text methods such as .env files as they are easy to scan for. The initial breach of stealing credentials is often only the beginning of a broader, more devastating attack.
Failing to use the protective powers of a Secrets Manager puts you further at risk from the following security challenges.
Cybercrime is big business, with successful breaches costing companies upwards of $200,000, on average. Without a Secrets Manager, your organization’s external threat mitigation strategy is severely lacking.
For example, if you don’t have a centralized secrets repository, how do you know who can access specific credentials? Can you guarantee that all your secrets are encrypted at rest? Can you say with confidence that you have done everything in your power to prevent your secrets from falling into the wrong hands?
It’s much better to acknowledge immediate improvements are possible and act on them now instead of later in the aftermath of a breach.
Secrets are widespread across your application deployment environments, platforms, and cloud infrastructure. Without a single source of truth for secrets storage, tracking secret usage becomes ad hoc, making operations such as mandatory rolling of credentials at set time intervals difficult and time-consuming.
A secrets manager can provide answers to questions every engineering leader should be asking from a risk management perspective, such as:
- How do we roll back a secret change in the event of a production outage caused by misconfiguration?
- Which applications are using a shared secret such as an API key?
- How fast can we roll a compromised credential and reload applications to pick up the change?
- Where is the audit log for tracking secret access and value changes?
- How are we sharing secrets with external contractors?
Secrets contain highly sensitive information, and without a Secrets Manager, anyone that can access .env files, Slack messages containing secrets, or other internal documentation where secrets may be stored, risk unintended access by unauthorized users or, worse, threat actors with malicious intent.
To mitigate this risk, you need tight access controls that enable you to select who can manage secrets for each environment (e.g. only DevSecOps for live environments) and assign appropriate permissions and policies to groups, individual users, and machines.
A Secrets Manager also provides a detailed audit log, critical when reviewing secret change history and administrative operations that document what users and machines accessed secrets and when.
In Gartner’s round-up of security risks and trends for 2021, the management of machine identities as an integral security capability was listed in the top eight.
Through cloud automation and infrastructure as code, organizations are grappling with greater numbers of non-human entities – containers, servers, applications, and devices – meaning the management of machine identities is becoming increasingly important to overall security.
Gartner notes that “establishing an enterprise-wide strategy for managing machine identities, certificates and secrets will enable the organization to better secure digital transformation.”
A Secrets Manager should be a foundational component of that management strategy.
You shouldn’t be sharing secrets via IM, zip files, git, or email, embedding credentials in code or databases, or using simple, albeit insecure, .env files. That much is clear. Secrets Managers are fundamental to streamlined workflows and security best practices, but how can organizations be sure that teams will use the chosen solution?
In short, the selected Secrets Manager must be easy and intuitive to use, as any anticipated friction can hurt widespread adoption.
Teams can manage secrets via an access-controlled dashboard, CLI, or language-specific SDKs. Accessing secrets is then performed at runtime, ensuring an application always has the latest version of the secrets when deployed.
And assuming application developers are following the industry best practice of using environment variables to access secrets in memory (not the file system), the security benefits are instant and significant.
Organizations seeking to replace .env files with a secrets manager should ensure it has built-in support for injecting secrets as environment variables, eliminating the need for application code changes for a fast and painless migration.
Environment variables have the benefit of being language and framework agnostic, which is why platforms such as AWS Lambda, Heroku, Vercel, Netlify, and others have standardized on environment variables for compatibility and because they require no third-party packages to consume.
Your security is only as good as your Secrets Manager. When weighing your options, consider the following factors:
Speed of implementation
Leading Secret Managers allow you to hit the ground running, minimizing migration time to secure your secrets sooner rather than later.
Versatility across environments
Your team works in all environments – from development to production and your secrets manager should as well.
What do your team’s favorite developer tools have in common? They solve a specific problem exceptionally well while providing a delightful developer experience. Choose a secrets manager that meets your security standards that your developers will love to use.
A quick and streamlined onboarding process makes it easy to add teams and applications. A secrets manager should make life easier for development teams, not harder.
Choose a secrets manager that meets your access policy requirements without additional overhead and complexity. The most secure secrets management implementation is the one that’s most widely adopted.
Secrets Injected via environment variables
If possible, choose a Secrets Manager that supports injection via environment variables to ensure secrets access is language and framework agnostic without the need for third-party libraries or SDKs.
The security risks posed by ad hoc and insecure secret storage and access are too pressing to ignore. Secrets stored in encrypted formats such as .env files with no centralized source of truth to control access are putting themselves at risk unnecessarily.
A Secrets Manager empowers your team to apply the principle of least privilege with fine-grained access controls for restricting what secrets and environments are accessible based on user groups and machine identities. All of which can be automated.
Using environment variables to inject secrets into applications at runtime maximizes language and framework compatibility, and the easier your chosen secrets manager solution is to implement, the better chance it will be adopted organization-wide.
Don’t leave your organization’s security to chance.
Start your Secrets Manager journey today by signing up for Doppler—The Multicloud Secrets Manager your team will love that takes minutes, not hours to use.