On 2014-12-23 at 16:05 -0700, Yves Dorfsman wrote: > The former is simple and doesn't need human intervention but creates a > security issue if the host gets compromised, the latter limits automation. > > What other strategies have you seen successfully implemented?
Environment variables. It used to be true that any process on a system could see the environment of any other process, but these days any modern Unix will restrict that to only the processes of the same uid. It's the least bad solution. You can also then have a wrapper script write out a config file templated from the environment, which gets you compatibility with a broader selection of applications. This helps with things like stopping a web-server from propagating the secrets to less trusted scripts. Pimping Time: our company (Apcera) has a cluster scheduler (Continuum) which can do this, and also make sure that the credentials available to the application are only valid for talking to the application protocol proxy, which only accepts those credentials from that instance and rewrites the credentials for the backend connection, so individual apps do not get the real password for access to a PostgreSQL/MySQL/whatever backend. Designed to protect against apps leaking credentials. Back to env: yes, there are still OSes which don't protect the environment. So just don't use those OSes. -Phil _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/