Storing Credentials for Cloud Services

Your webservers usually have to connect to various services, like your database and cache servers. To do this, they will usually need to have credentials on hand to authenticate themselves. How should you store these?

Best practices

The Need to Know (Least-Access Privilege)

When it comes to storing credentials on the webserver itself: you should ideally never do this, but for one or two services it can be unavoidable. For example, you might store credentials in a cache server, but your webserver can't access that cache server without the credentials to do so - so it would need one set of credentials physically present on the server itself.

Outside of that, you should avoid storing credentials physically on servers, and make absolutely sure it is never within the DocumentRoot of Apache or similar, even if you are using htaccess files to restrict access. Never keep sensitive files in the document root, and make sure the permissions of those files are as restrictive as they can be whilst allowing the webserver to access them.

Use a dedicated credentials manager

Cloud services providers usually have some form of credentials and secure parameter management, e.g. the Systems Manager -> Parameter Store area in AWS, that allows you to securely store credentials with two-way encryption. You can use this to store credentials securely, and then give the webservers the credentials to access the Parameter Store instead of all the separate credentials for each service they need.

It's also not a bad idea to cache these credentials in your cache server, providing it is properly secured, as they are not going to change that often and requests to decrypt secure parameters can rack up a lot of costs if it's happening on every page request. Make sure that the Redis key or equivalent that you store parameters in has a unique prefix, so that it can't accidentally be accessed or overwritten when looking for something else like user content. Many keys for cache server entries are generated dynamically for e.g. user session IDs or other cached information about an entry, so you want to be sure there is no overlap (or else your credentials could be leaked, or overwritten).