SOPS stands for Secrets OPerationS. It is free and open software released by the Cloud Native Computing Foundation that encrypts/decrypts text files "automagically." We are listing this here not as a stand-alone solution but as a great way to add security to `.env` files without incurring additional costs. This approach does come with some overhead, as all users must have the software installed and agree on an encryption algorithm.

When used in conjunction with .env files, all needed credentials are called programmatically from the file and not added as plaintext into the code, and SOPS unencrypts the secret just in time. While a lot safer than storing plaintext credentials anyone can read, this approach introduces the issue of managing an encryption key across the team.

Pros: 

• Low cost.
• Secrets are encrypted at rest.
• Easier to sync secrets across internal teams securely.

Cons: 

• The added complexity of securely managing an encryption key.
• No policy enforcement.
• No audit logs (who accessed which secret and when).
• No central reporting is possible.

Resources: 

• SOPS on GitHub
• A Comprehensive Guide to SOPS: Managing Your Secrets Like A Visionary, Not a Functionary
• Use encryption to store secrets within .git repositories

Almost all cloud-based platforms provide some form of built-in secrets management tooling. This approach lets you add your needed credentials directly to the platform where they will be used and invoke them as environmental variables from within your applications. The platform will encrypt and store the secrets safely, removing the complexity of managing encryption keys yourself.

This approach also lets you audit the addition and removal of secrets over time, but it does assume that everyone is bought into this approach, which is harder to enforce.

Using built-in secret managers is straightforward for smaller applications and if all your applications are built upon the same cloud services. For example, if you only use AWS for all your projects, then it makes sense to standardize on AWS Secrets Manager to handle your credentials. If you have very large applications requiring multiple external services or your applications span multiple cloud providers, this approach can add the complexity of remembering where each credential is stored and makes reporting more complex.

Pros: 

• Typically included at no additional costs on most major platforms.
• The service handles encryption and decryption.
• Easy to leverage in code through environment variables.
• Can audit and report on each platform. 

Cons: 

• No policy enforcement.
• Auditing becomes much harder if you move to multi-cloud deployments. 

Resources:

• How to Handle Secrets with Google Cloud Secret Manager‍
• How to Handle AWS Secrets‍
• How to Handle Secrets with Azure Key Vault

Managing your own secrets vault system makes a lot of sense if you have secrets spread among multiple cloud providers or have deployed your applications across cloud-native and on-premises infrastructure. A vault solution will let you store your secrets securely in an encrypted database and retrieve them at run time by calling the service from within the code. Since it works across any service or platform, it is an ideal way to organize secrets across teams and complex projects.

The downside to any self-managed solution is that it brings the overhead of running the infrastructure yourself, which will take additional time and resources. While community support is available, many of these projects are open source or free and offer no official support channels. This approach also requires some specialized knowledge to set up these systems correctly and securely.

An unexpected complexity can arise from multiple teams setting up their systems, making it much harder to audit secrets management across the whole organization.

Pros: 

• Multiple free and open-source solutions are available.
• Easy to leverage in code through environment variables.
• Can audit and report on each platform.

Cons: 

• The setup and maintenance of these systems carries a cost.
• Possibility of multiple vault systems across diverging projects. 
• Auditing becomes much harder if teams have set up multiple instances or solutions for their projects.

Resources: 

• Terraform Project for Managing Vault Secrets in a Kubernetes Cluster
• Data Security — an Introduction to AWS KMS and HashiCorp Vault
• Vault Secrets by HashiCorp
• Keywhiz - by Square
• Knox - by Pintrest
• Confidant - by Lyft

Enterprise secrets managers provide hosted solutions that can easily integrate with multiple platforms simultaneously. Built into these systems are full auditing and reporting mechanisms to quickly see when secrets were added or rotated, as well as when and where they have been accessed. This approach also makes it much simpler to rotate credentials automatically, on a schedule or on-demand.

From the developer's perspective, a well-adopted enterprise solution makes it easy to know how to handle secrets throughout their code. While there is the possibility of teams being non-compliant, it is less likely they will set up their own competing enterprise solution.

As you might expect, though, enterprise features come with an enterprise price and can get very expensive very quickly. While we would love to see everyone using this level of secrets management, we are recommending it here only for large enterprises that can budget for it.

Pros: 

• Centrally managed across the enterprise.
• Easy to leverage in code through environment variables.
• Can audit and report on each platform. 
• Auto-rotation of secrets is a standard feature.
• Straightforward integration for multiple platforms and services.
• Role Based Access Controls are possible.

Cons: 

• Enterprise price tag.

Resources:

• Cyberark Conjur Cloud
• End-to-end secrets security with CyberArk Conjur Cloud and GitGuardian
• Akeyless
• Enterprise Vault by HashiCorp
• Doppler