Best practice for storing credential in data center

Question

I have a cache warming script I want to start in response to a certain server-side event. That script needs user credentials to perform its job (read-only account). So far I have avoided automating this process because I didn't want to store ANY credentials on the server, but I've come to a point where I really need to automate the process. The server is CentOS 6.

I know storing any credential is a risk, so I'm curious what the industry standard is if I can't be at a terminal to enter a credential every time I need this process to run.

Update The root question: If it is NOT ok to have credentials stored in the clear, what are the other options?

Answer 1

To avoid using the credentials completely, decouple the trigger of the cache warming script from the server-side event.

The concept is:

• server-side event sets a flag in a shared location
• persistent process run by cache warming script user monitors that shared location
• if persistent process sees flag is set, flag is cleared and cache warming script is run

Since the persistent process can be run via cron or as a daemon owned by the cache warming script user, you just set that up once, never need to pass user account credentials.

Shared Location:

Decide on a shared location that can be accessed and written to both by the server-side event and the user that needs to run the cache warming script. In a system with a database, this could be a variable in a configuration table. But this could also be just a file in a directory that is +rw by both users and is touch'd by the server-side event.

Setting the flag:

If you are using a database, an example of setting a flag would be if you have a variables table that has key and value columns, setting a particular key's value to 1. If its a file, it would be the existence of a file.

Side benefits:

If you need to restrict how often the cache warming script is run, you can always implement logic in the persistent process to keep track of the last time the script was run to prevent overuse if something goes bad.

You can easily add multiple triggers of the cache warming script from other server-side events because the method of triggering the script is hidden behind the shared location interface.

Answer 2

Regarding the update: If it is NOT ok to have credentials stored in the clear, what are the other options?

Generally once an entity wants to authenticate itself to a service, the entity must have an authentication token. That said, if you are using password authentication and want to do it automatically, you must make the password accessible somehow somewhere in plaintext - otherwise you'd need another token to transform it from safe" form to plaintext.

Getting back to your original problem, it's always good to consider who, why and how somebody might (want to) misuse the credentials (if they were in plaintext file readable only by the user running the cache warm-up script for example). It may turn out that securing it doesn't make much sense or that the overall security concept of the project is flawed.

You might want to ask on Security SE - chances are you'll more in depth answer there.