Pasword retrievel from external source on node

[Johan De Wit]

Hi, 

Anyone playing with the idea to manage passwords on the node by retrieving them from an externa source like cyberark ?

The idea is to avoid storing passwords in some 'human readable' form in eg. hiera, manifests, catalogs, puppetdb ......
Main concern is security.

We are thinking solving such thing using some custom provider, possible extending existing ones.

Just curious someone has already done some thinking/work about this.

Grts

Johan
--
Johan De Wit

Open Source Consultant  -- Open-Future
 
Red Hat Certified Engineer              (805008667232363)
Puppet Certified Professional 2013/2014/2015 (PCP0000006) 
Puppet Certified Instructor
blog : http://johan.koewacht.net/   gsm: +32 474 42 40 73

 

[Craig Dunn]

On Thu, Mar 10, 2016 at 12:05 PM, Johan De Wit <jo...@open-future.be> wrote:

Hi, 

Anyone playing with the idea to manage passwords on the node by retrieving them from an externa source like cyberark ?

The idea is to avoid storing passwords in some 'human readable' form in eg. hiera, manifests, catalogs, puppetdb ......
Main concern is security.

Why can't you store them in hiera using hiera-eyaml?, which is what most people do - so they are stored inline with the rest of your configuration but are encrypted.  If you want to go the extra mile you could use Vault, there is also a hiera-vault backend, though I've not got first hand experience of that.

Craig

 

[Johan De Wit]

Hi Craig,

They are still stored unencrypted in the catalog, which is an issue for us.

Security is a high priority in this case

grts

Johan

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACxdKhF0Fk6yz%3D3Aw--VFA_DBJ1wGr0Mmfd14SezXUErn4XZNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Müller]

I'm too interested in how people manage credentials without having it in the catalog.

Recently i stumbled upon a puppetlabs blogpost about conjur. There is also a video of a presentation at puppetconf 2015 about this.

Managing credentials out of band ("out of puppet") seems like a good way to solve the catalog problem.

Thomas

[Craig Dunn]

On Thu, Mar 10, 2016 at 3:09 PM, Thomas Müller <tho...@chaschperli.ch> wrote:

I'm too interested in how people manage credentials without having it in the catalog.

The problem as I see it is that there isn't a blanket approach.  If you need a secret value in a template, that template is already compiled into the catalog before the agent receives it, and there are numerous ways to get a file on a system.  One idea would be a kind of "eyaml in reverse" approach, where files could be deployed with inline encrypted data, and then a type and provider to do a pattern substitution on the file on the agent using local keys.   

But the problem isn't just files - what about, for example, exec commands that need to use a secret in the command line?  file_line resources? augeas? - theres a whole host of places the data might end up.

I think the bigger issue to address would be why are your catalogs not considered a safe place to have this data? Access to the catalog should be at the same level of trust as root access to the agent.

[Trevor Vaughan]

One of the main issues is ensuring that the sensitive contents of the catalog do not make their way back into PuppetDB, Foreman, etc....

I've been toying with the idea of adding a special, non-translated function to Puppet core that will provide direction for the agent itself to reach out to a 'trusted' data source regardless of placement in the catalog.

Essentially, this would be a special string, combined with some sort of metaparameter that alters the catalog content on the fly.

It should absolutely be doable and the Conjur FOSS codebase is close to there but doesn't quite hit the mark across the board for what I would like.

If anyone would like to start this, I'd be more than happy to help contribute when I have time. Otherwise, I'll just hack at it when I get the chance.

Thanks,

Trevor

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACxdKhGrdrciDbSnPNAnGSjfspNP7azB%2BvMofR057dODZ9VL2A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --

[Thomas Müller]

As Trevor pointed out its about where do the credentials get logged and saved (Foreman, PuppetDB, Syslog, ...)

Another problem arises if you have to integrate with systems/services not managed by puppet. 

Or if you have compliance policys to work with.  Like (oversimplified): "credentials MUST only be saved in tool xy with fancy hardware crypto and on the target system". This leads to the requirement to have something on the client side which handles the retrieval of the credentials. So it can be ensured that only the tool xy and the target system know about the credential.

- Thomas