##(see the SpecSpec for an explanation) * '''Launchpad Entry''': UbuntuSpec:server-maverick-puppet-bootstrap * '''Created''': * '''Contributors''': * '''Packages affected''': == Summary == ## This should provide an overview of the issue/functionality/change proposed ## here. Focus here on what will actually be DONE, summarising that so that ## other people don't have to read the whole spec. See also CategorySpec for ## examples. The puppet client registration process will be extended to include information proving that the puppet client request is legitimate. == Release Note == ## This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) ## It is mandatory. == Rationale == ## This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. In the context of Cloud, puppet client running on instances come and go. == User stories == == Assumptions == == Design == ## You can have subsections that better describe specific parts of the issue. === X509 PKI === {{attachment:pki.png}} === Registration process === {{attachment:registration.png}} ==== Cloud conductor ==== ===== Extended Key usage attribute in Conductor certificates ===== Cloud conductor certificates include an extended key usage attribute to note that they can be used to sign the extended attributes included in a csr request from a puppet client: {{{ # Allowed to create new instances 1.3.6.1.4.1.34380.2.0 }}} ===== Extended attributes for puppet client CSR ===== Whenever a puppet client asks to be registered additional attributes from the conductor are added to the CSR to legitimate the request: {{{ # Signature (base64 encoded) 1.3.6.1.4.1.34380.2.1 = # Signature version (integer) 1.3.6.1.4.1.34380.2.2 = 1 # expiration date (rfc3339) 1.3.6.1.4.1.34380.2.3 = 2010-05-07T23:31:03+00:00 # Cloud conductor certificate (PEM format) 1.3.6.1.4.1.34380.2.4 =-----BEGIN CERTIFICATE [...] ----- # Node classification (yaml base64 encoded) 1.3.6.1.4.1.34380.2.5 = }}} Version 1 signature: 1. Create the string to be signed: {{{ 1.3.6.1.4.1.34380.2.2=1\n 1.3.6.1.4.1.34380.2.3=2010-05-07T23:31:03+00:00\n 1.3.6.1.4.1.34380.2.4=-----BEGIN CERTIFICATE [...] -----\n 1.3.6.1.4.1.34380.2.5=\n }}} 1. Sign it with the private key of the conductor. ==== cloud-config support ==== Cloud-config puppet syntax is extended to support csr attributes: {{{ puppet: csr_attributes: "1.3.6.1.4.1.34380.2.1": "aaaaabbbbb" "1.3.6.1.4.1.34380.2.2": "1" "1.3.6.1.4.1.34380.2.3": "2010-05-07T23:31:03+00:00" "1.3.6.1.4.1.34380.2.4": "-----BEGIN CERTIFICATE [...] -----" "1.3.6.1.4.1.34380.2.5": "aaaabbbbbbb" }}} ==== Puppet client ==== The puppet client supports an additional option to be able to specify a list of extended attributes to be added to the csr: In puppet.conf: {{{ csr_attributes_file = /etc/puppet/csr_attributes.txt }}} Example ``/etc/puppet/csr_attributes.txt``: {{{ 1.3.6.1.4.1.34380.2.1 = aaaaabbbbb 1.3.6.1.4.1.34380.2.2 = 1 1.3.6.1.4.1.34380.2.3 = 2010-05-07T23:31:03+00:00 1.3.6.1.4.1.34380.2.4 = -----BEGIN CERTIFICATE [...] ----- 1.3.6.1.4.1.34380.2.5 = aaaabbbbbbb }}} The Puppet client validates the puppet master certificate by checking the complete certificate path up to the Puppet Root CA. ==== Puppet master ==== ===== CSR checking and certificate issuance ===== For each CSR the puppetmaster: 1. verifies that the certificate included in the CSR is from the trusted Puppet Root CA. 1. verifies that the conductor certificate included in the CSR extended attribute has the AllowedToCreateInstance attribute as an extended key usage. 1. validates the signature of the extended attributes in the CSR. 1. issues a certificate to the puppet client that includes the node classification as an extended attribute: {{{ # Node classification (yaml base64 encoded) 1.3.6.1.4.1.34380.2.5 = }}} 1. sends the new certificate *and* its own certificate to the puppet client. === Run process === {{attachment:run.png}} ==== Puppet client ==== The Puppet client validates the puppet master certificate by checking the complete certificate path up to the Puppet Root CA. ==== Puppet master ==== ===== 1. Client authentication ===== Every puppet client sends its own certificate *and* the puppet master certificate that issued its certificate. The puppet master validates the complete certificate chain up to the Puppet Root CA. ===== 2. Node classification ===== The node classification is extracted from the client certificate and used to compute the client manifest. == Implementation == ## This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: See Work Items definition in the [[https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-puppet-bootstrap|blueprint whiteboard]]. == Test/Demo Plan == ## It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. ## This need not be added or completed until the specification is nearing beta. == Unresolved issues == ## This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == ## Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. === UDS Lucid discussion notes === {{{ Support for multi masters (ie a puppet client can request its certificate (CSR) from a master out of multiple ones (HA/Load balanced)) and multi cloud conductors (multiple components can start new instances which will be accepted by all puppetmasters): best practices == one server used for cert requests, cert chaining Michael would like to talk about Riak implementation :) - Root CA - puppetmaster1 CA - puppetclient1 cert (started by cloud_conductor1) - puppetclient3 cert (started by cloud_conductor2) - puppetmaster2 CA - puppetclient2 cert (started by cloud_conductor2) - puppetclient4 cert (started by cloud_conductor1) - cloud_conductor1 cert - cloud_conductor2 cert Extend csr format to include specific attributes to ensure the csr is genuine (ie started by a authorized/recognized/trusted cloud conductor): [ req_attributes ] # Signature (base64 encoded) 1.3.6.1.4.1.34380.2.0 = # Signature version (integer) 1.3.6.1.4.1.34380.2.1 = 1 # expiration date (rfc3339) 1.3.6.1.4.1.34380.2.2 = 2010-05-07T23:31:03+00:00 # Cloud conductor certificate (PEM format) 1.3.6.1.4.1.34380.2.3 =-----BEGIN CERTIFICATE [...] ----- Puppetmaster hooks for csr signing (dynamic client registration in cloud): * pupptca command to get the waiting csr * Can we add arbitrary data? - http://ruby-doc.org/ruby-1.9/classes/OpenSSL/X509.html < Documentation of OpenSSL:X509 Library, which puppet uses to generate CSR (daemon calling puppetca ?) Puppet client csr hook: add specific attributes to the csr generated by the puppet client: (implementation thoughts? how to get data into CSR?) (freeform JSON acceptable? -- sounds like we are embedding cloudmaster cert in CSR) Other puppet related topics: - initctl (upstart) service provider: http://projects.puppetlabs.com/issues/3747 - status support - disable/enable support - review upstream test suite: * fix all tests * enable tests during package build (ie get rid of puppet-testsuite) It would be more user friendly to use hostnames over UUIDs, before reinstall/reprovision of existing hostname, revoke/remove existing cert. (Helps logs). Some Conclusions - need to check if CA chaining works with common root (multiple puppet CA from common master) - need to find out does ruby ssl libs allow injecting of extra data in CSR ? + http://ruby-doc.org/ruby-1.9/classes/OpenSSL/X509.html < Documentation of OpenSSL:X509 Library, which puppet uses to generate CSR - want puppetd flag --extra-csr-info=, embeds data into CSR - if not embeddable in CSR could store it on puppetmaster in parallel - script or web service to call out to say "should I autosign this?" (script most likely, outputs log messages, returns pass/fail ?) configurable as --autosigner-hook= or equivalent - intent is to NOT have to have admins approve any systems manually }}} ---- CategorySpec