Puppet Enterprise Answers file install and Policy based autosign

[Adam Clark]

Hi all,

  I am trying to proof of concept an automated install of Puppet Enterprise using policy based autosign.

I have read the following documents and understand what I need to do

http://docs.puppetlabs.com/puppet/latest/reference/ssl_autosign.html#policy-based-autosigning

http://docs.puppetlabs.com/puppet/latest/reference/ssl_attributes_extensions.html

I would like to include some vmware attributes as extensions for verification.  These attributes are identified by facter.

The problem arises in that the automated installer creates and attempts to contact the master as part of the installer operation.

I need to interrupt the installer and update the csr_attributes.yaml file prior to the CSR is created.

I can't create the file prior to PE install as I need facter.

Is there a way to break this chicken/egg situation?

Cheers

Adam

[Eric Sorenson]

Hi Adam, this is really interesting work, thanks for trying out this feature.

I'm a little confused though, the certificate autosigning just entered upstream open-source Puppet in 3.4.0 and there's not a Puppet Enterprise version that ships it yet. Did you install it separately or something? 

Version numbers aside, as you found out, you need some way to build the csr_attributes file before you run puppet for the first time. Even a pluginsync isn't going to work as it requires a certificate. Can you 'bake' the custom fact code into a package that gets installed at provisioning time? 

Also, can you share more information about the vmware facts you're interested in using? Since this feature is really new I'm very interested in gathering use cases and integrations to potentially ship with Puppet Enterprise once it incorporates this functionality.

--eric0

[Adam Clark]

HI Eric,

  Thanks for the reply.  I'm using PE 3.3.1 with naive autosigning which works well, I just assume policy based was working too. 

I'm new to Puppet and just doing some proof of concept work.

One thing I haven't got a good grip on is when does facter go out and gather the facts?  Can it gather them independently of or puppet agent being run?  Are they available before puppet agent is run for the first time?

I can't really answer this question as puppet is always run as part of the install script.

What I would like to do is this:

* Create a website in which takes request that have a vmware uuid (or ec2 instance id) and certname and returns a csr_attributes.yaml file with an autogenerated PSK

   * the website stores all of this in a DB with a timestamp so I can age them out.

* Create an autosign script that validates a CSR against the DB and the cloud provider

My puppet bootstrap process is:

1 update system

2 download PE tarball and answers file

3 extract tarball

4 run installer with anwsers files

What would be great is if there was an empty hooks directory that could contain some well-known named scripts that are run at certain times.  pre_agent.sh or something could be downloaded between steps 3 and 4 and placed into the hooks directory.

This would allow me to use facter post install, but pre-agent run to get my data.

What do you thing?

Adam

[Eric Sorenson]

Adam Clark wrote:
> HI Eric,
> Thanks for the reply. I'm using PE 3.3.1 with naive autosigning
> which works well, I just assume policy based was working too.
> I'm new to Puppet and just doing some proof of concept work.
>
> One thing I haven't got a good grip on is when does facter go out and
> gather the facts? Can it gather them independently of or puppet agent
> being run? Are they available before puppet agent is run for the
> first time?
> I can't really answer this question as puppet is always run as part of
> the install script.

Puppet runs facter after it pluginsyncs but before it requests the
catalog from the master. It doesn't execute /usr/bin/facter directly but
rather uses facter as a library, so puppet can't easily use a
pre-existing cache of facts. Because custom facts could be
pluginsync'ed, to get the same behavior without actually running the
agent you'd need to run "puppet plugin download" then "facter -p" (both
as root) so it uses the correct config file and directories.

>
> What I would like to do is this:
> * Create a website in which takes request that have a vmware uuid (or
> ec2 instance id) and certname and returns a csr_attributes.yaml file
> with an autogenerated PSK
> * the website stores all of this in a DB with a timestamp so I can
> age them out.
> * Create an autosign script that validates a CSR against the DB and
> the cloud provider

This should be totally doable and indeed is exactly the kind of thing I
was hoping to see happen with the autosign policy + cert attributes.
Sounds like an awesome PuppetConf talk in the making, actually :-D

Let me restate your requirements for that web service a bit, to make
sure I understand -- this is the part that's probably the most
complicated. It would...

- provide an endpoint that accepts requests for attributes from unknown
IPs who provide a uuid
- match the uuid against the cloud service api to determine whether a
psk should be issued
- if it should, generate + store a timestamped [uuid,psk] tuple and
return a valid csr_attributes.yaml

- provide a second endpoint whose access is restricted to just your
puppetmasters
- take requests that present a [uuid,psk] tuple, and check whether
there's a matching record *
- if yes, delete the record and reply affirmative to the autosign request

* does this step really also need to call out to the cloud service API?
Vsphere at least is pretty slow/expensive in my experience, and if
there's a valid record in the DB it should be safe to skip a call on
every signing request...

> My puppet bootstrap process is:
> 1 update system
> 2 download PE tarball and answers file
> 3 extract tarball
> 4 run installer with anwsers files
>
> What would be great is if there was an empty hooks directory that
> could contain some well-known named scripts that are run at certain
> times. pre_agent.sh or something could be downloaded between steps 3
> and 4 and placed into the hooks directory.
> This would allow me to use facter post install, but pre-agent run to
> get my data.
>

> What do you think?
>
I agree some hooks would be nice; the PE installer is currently under
heavy revision for PE3.2 so I wouldn't want to hack too much into it
just now. But again, if you're relying on custom facts, you need a
certificate in order to get them pluginsync'ed so it wouldn't help this
situation.

However, you can pre-seed the csr_attributes.yaml in step 1, if you can
put a little stand-alone implementation of your fact code and the script
that calls out to the web service in a %post kickstart scriptlet or use
cloud-init. The installer won't flip out if there's already an
/etc/puppetlabs/puppet/ directory in place on the system when it runs.

Pretty interesting!

--
Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles