Anyone scripting around certificate authority? (puppet-dev version)

[Eric Sorenson]

[ sorry for the double-post, I sent this to puppet-users as well, but am posting separately here to keep the threading separate.. Damn reply-to munging ]

Hiya, one of the cool things in the new Puppet Server is a re-implementation of Puppet's certificate authority code. The implementation up to last week's 1.0.0 release is pretty strictly backwards-compatible with the Ruby implementation, using the same filesystem layout, same HTTP endpoints, etc., but early next year we need to start making some changes and I wanted to solicit some feedback to see what y'all are using. So, some questions:

- Are you using scripts which run and parse output from `puppet cert`, `puppet certificate`, `puppet ca`, `puppet certificate_request` and/or `puppet certificate_revocation_list`? If so, what do the scripts do with the commands, and what output do they expect?  (As an aside one of the problems we're aiming to fix is the multiplicity of confusingly overlapping functionality available in these subcommands)

- Are you using the HTTP API around certificates in your own tooling/automation? These are endpoints like `/certificate/ca`, `/certificate/<some host name>`, `/<environment>/certificate_revocation_list/ca` , `/<environment>/certificate_request/`, `/<environment>/certificate_status`  Same question -- what do you use the endpoints to accomplish, and are there particularly important pieces of data in the output for your use-cases?

- Are you using any programs which load the Puppet Ruby code as a library in order to make use of the certificate-related classes/methods directly? Is that because there was something you couldn't do through the command-line or REST APIs? I would be pretty surprised if anyone was doing this but you're going to have to make the deepest changes so it's important for me to understand what you're relying on.

- Are you making use of stuff that lives in the CA filesystem in your own tooling, that does NOT go through any of the Puppet APIs? If so, STOP DOING THAT! Just kidding, sorta. But it would be very interesting to know whether you're using things like the `serial` or `inventory.txt` files in your scripts or workflows.

Feel free to follow-up here or on https://tickets.puppetlabs.com/browse/SERVER-270

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

[Erik Dalén]

I can reply to all these questions I think. But will be a few days before I can write up all the details. Christmas celebrations and stuff :)

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/50D1D662-A11B-4CA6-8A63-0E7240C561B1%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

[Erik Dalén]

On Mon Dec 22 2014 at 9:01:51 PM Eric Sorenson <eric.s...@puppetlabs.com> wrote:

[ sorry for the double-post, I sent this to puppet-users as well, but am posting separately here to keep the threading separate.. Damn reply-to munging ]

Hiya, one of the cool things in the new Puppet Server is a re-implementation of Puppet's certificate authority code. The implementation up to last week's 1.0.0 release is pretty strictly backwards-compatible with the Ruby implementation, using the same filesystem layout, same HTTP endpoints, etc., but early next year we need to start making some changes and I wanted to solicit some feedback to see what y'all are using. So, some questions:

- Are you using scripts which run and parse output from `puppet cert`, `puppet certificate`, `puppet ca`, `puppet certificate_request` and/or `puppet certificate_revocation_list`? If so, what do the scripts do with the commands, and what output do they expect?  (As an aside one of the problems we're aiming to fix is the multiplicity of confusingly overlapping functionality available in these subcommands) 

- Are you using the HTTP API around certificates in your own tooling/automation? These are endpoints like `/certificate/ca`, `/certificate/<some host name>`, `/<environment>/certificate_revocation_list/ca` , `/<environment>/certificate_request/`, `/<environment>/certificate_status`  Same question -- what do you use the endpoints to accomplish, and are there particularly important pieces of data in the output for your use-cases?

We use this to revoke certificates when we decomission hosts in our provisioning tool chain. So mostly the certificate_status endpoint is used.

We also have some puppet code to get a request from some other puppet master than the current one, that uses all the endpoints the agent uses to request a certificate.

- Are you using any programs which load the Puppet Ruby code as a library in order to make use of the certificate-related classes/methods directly? Is that because there was something you couldn't do through the command-line or REST APIs? I would be pretty surprised if anyone was doing this but you're going to have to make the deepest changes so it's important for me to understand what you're relying on.

Yes, we do this to request the certificate as part of running masterless puppet. So this is mostly this code snippet:

    require 'puppet/ssl/host'

    Puppet::SSL::Host.ca_location = :remote

    host = Puppet::SSL::Host.new

    host.wait_for_cert(0)

This is inside of a Puppet application so made sense to reuse the same code as the agent does.

- Are you making use of stuff that lives in the CA filesystem in your own tooling, that does NOT go through any of the Puppet APIs? If so, STOP DOING THAT! Just kidding, sorta. But it would be very interesting to know whether you're using things like the `serial` or `inventory.txt` files in your scripts or workflows.

Yes, we do this as well, have a script that will figure out which certificates (serial numbers) should be active, and revokes everything else. So it can from the inventory.txt and a list of active hosts rebuild the CRL from scratch. Needed every time PUP-2189 happens.

The script can be seen in all its ugliness here: https://gist.github.com/dalen/82461936d4d3af17b695 

 

Feel free to follow-up here or on https://tickets.puppetlabs.com/browse/SERVER-270

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

[Dominic Cleal]

On 22/12/14 20:01, Eric Sorenson wrote:
> [ sorry for the double-post, I sent this to puppet-users as well, but am
> posting separately here to keep the threading separate.. Damn reply-to
> munging ]
>
> Hiya, one of the cool things in the new Puppet Server is a
> re-implementation of Puppet's certificate authority code. The
> implementation up to last week's 1.0.0 release is pretty strictly
> backwards-compatible with the Ruby implementation, using the same
> filesystem layout, same HTTP endpoints, etc., but early next year we
> need to start making some changes and I wanted to solicit some feedback
> to see what y'all are using. So, some questions:
>
> - Are you using scripts which run and parse output from `puppet cert`,
> `puppet certificate`, `puppet ca`, `puppet certificate_request` and/or
> `puppet certificate_revocation_list`? If so, what do the scripts do with
> the commands, and what output do they expect? (As an aside one of the
> problems we're aiming to fix is the multiplicity of confusingly
> overlapping functionality available in these subcommands)

Foreman's smart proxy (a management agent) uses `puppet cert`. You can
find it here:
https://github.com/theforeman/smart-proxy/blob/develop/modules/puppetca/puppetca_main.rb

It uses "puppet cert --list --all", "puppet cert sign" and "puppet cert
clean". sign/clean are just basic execution, but listing appears to
parse the output very precisely, so I expect any change in output format
would break it.

"puppet cert --generate" is also used to generate a CA and certificate
when setting up a Puppet master in this module:
https://github.com/theforeman/puppet-puppet/blob/2.3.1/manifests/server/config.pp#L62-L66
(usually run from puppet apply).

> - Are you using the HTTP API around certificates in your own
> tooling/automation? These are endpoints like `/certificate/ca`,
> `/certificate/<some host name>`,
> `/<environment>/certificate_revocation_list/ca` ,
> `/<environment>/certificate_request/`,
> `/<environment>/certificate_status` Same question -- what do you use
> the endpoints to accomplish, and are there particularly important pieces
> of data in the output for your use-cases?

I'd prefer to reimplement it against the API, incidentally. A change in
the CLI might be a good reason to do it.

> - Are you using any programs which load the Puppet Ruby code as a
> library in order to make use of the certificate-related classes/methods
> directly? Is that because there was something you couldn't do through
> the command-line or REST APIs? I would be pretty surprised if anyone was
> doing this but you're going to have to make the deepest changes so it's
> important for me to understand what you're relying on.

Not for certificates.

> - Are you making use of stuff that lives in the CA filesystem in your
> own tooling, that does NOT go through any of the Puppet APIs? If so,
> STOP DOING THAT! Just kidding, sorta. But it would be very interesting
> to know whether you're using things like the `serial` or `inventory.txt`
> files in your scripts or workflows.

By default, Foreman re-uses Puppet certificates and keys, so the
locations are important, however they're not modified.

Cheers,

--
Dominic Cleal
Red Hat Engineering