The one i've most often seen is a simple user account. User registers with an external service or throught the app itself and the app runs as the user's account. Permission is controlled by that account. On Dec 23, 2014 8:38 PM, "Phil Pennock" <lopsa-t...@spodhuis.org> wrote:
> 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/ >
_______________________________________________ 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/
