Manage your secrets securely

An application has to talk to databases, managed services and other third party applications, for its successful operation. And every outgoing request has to be secured with some or the other way. If you have ever built an application, you would know that managing the secrets (passwords, keys and tokens) for all these services/applications is really challenging. Also as your application grows, it becomes difficult to manage them for multiple environments (dev, staging, prod etc.)

In this blog I will explain how developers usually go about managing the secrets in step by step manner. Towards the end of the blog, I will talk about the optimum way to manage your secrets.

Storing secrets in code

Developers usually start with prototyping the application and usually provide all the secrets in the source code itself like this -

# app/process.py
DB_PASSWORD = "a3d!9FS2309"
API_ACCESS_TOKEN = "jgradxasd4526d3nvtgu2zgv"

It’s the quickest and easiest approach to have the secret written in code, but it’s not a good idea mainly because of following reasons.

1. Every team member, who has the access to the repository, can see the secrets.
2. In case of changing any password, you need to commit the code, restart the application etc.
3. Difficult to manage secrets for various environments

Storing secrets in Config file

In this approach all secrets are moved out of the source code and put into config file. A separate config file is created for each environment and kept on those application servers. And these config files are not checked in to the repository. Of course you can have masked version of config file as a part of repo.

# app/config.txt
DB_PASSWORD = "a3d!9FS2309"
API_ACCESS_TOKEN = "jgradxasd4526d3nvtgu2zgv"

This approach has few pros and cons over storing secrets in source files as

1. Access to secrets reduces from all repo users to all VM users
2. Managing secrets for multiple environment is eased out
3. To change secrets, you don’t need any commits, but you still need to restart the application

Storing secrets in Environment variables

In this approach secrets are stored as environment variables. Depending on the environment, you can set the values of each environment variables. This is the concept of many configuration management tools. In simple terms, you can set the secrets using this approach as below

# app/set_env.sh
#!/bin/sh
if [ $1 = 'dev' ];
then
 export DB_PASSWORD=a3d!9FS2309
 export API_ACCESS_TOKEN='jgradxasd4526d3nvtgu2zgv'
fi
if [ $1 = 'prod' ];
then
 export DB_PASSWORD=h6@fj451q
 export API_ACCESS_TOKEN='djsiue31092fgqwedhgn1k9b'
fi

This approach is quite similar to previous approach. The additional benefit is you do not need to maintain multiple copies of config files for different environments.

Using Key Management Services

This is a very clean and secure approach of managing your secrets. Majority of the cloud providers provide Key management service. These services allow you to create, use, rotate and destroy cryptographic keys. These keys are used to encrypt the secrets and then you can store the encrypted version of these secrets in your file system or repo. Since the secrets are encrypted, humans can not make sense of the content. Only authorized user or application (service account), with appropriate permissions, can decrypt the content and use it as needed.

Permission management is handled by IAM services which provides a fine grained permission control. You can either give permission for using of keys for encryption and decryption or permit admin activities like managing key or key rotation.

The advantages of this approach are

1. You can control who or which application can access the secrets
2. Managing secrets for multiple environment is eased out
3. Flexibility of rotating the keys with version control without any downtime

Conclusion

Using the KMS gives the most secured way of managing the secrets. It’s a good approach to maintain secrets if your application is running in cloud and is sufficiently large application, otherwise managing through environment variables should suffice.