Automating Puppet Master Certificate Signing and vRealize Automation

A big part of my job at Varrow is evaluating new technology related to cloudy things and determine if/where said technology might fit into our overall cloud strategy. From there it’s all about taking that technology, integrating it, building demos in our innovation labs and making it a repeatable process. I’ll talk more in-depth about my role in another article and just stick to the technical stuff here. This brings us to Puppet Labs.

In a nutshell this is what Puppet does: “…automates configuration and ongoing management of your machines and the software running on them” That is from their website. Puppet is built on a master/agent relationship where a Puppet master exists and all machines you are managing with Puppet will have an agent running on them (including the master node). I wanted to set this up in our innovation labs in order to fully demonstrate Puppet’s capabilities and integration with vRealize Automation (formerly vCAC). This is where the problem started. By default, anytime a new machine comes online with a Puppet agent it contacts the Puppet master. However, before it can fully communicate and start doing it’s magic a certificate request must be signed. Here’s the generic workflow:

  • New machine comes online with Puppet agent
  • Puppet agent contacts the Puppet master for the first time and a certificate request is generated
  • Puppet master signs the certificate request
  • New machine with Puppet agent can now receive configurations from the Puppet master

Pretty simple workflow. In order for the Puppet master to sign certificate requests from new Puppet agents you have two options: configure the Puppet master to sign ALL certificate requests automatically or manually sign the certificate request by using the puppet cert sign command. The first option isn’t very secure and the second option isn’t very scalable. Yes, I’m setting this up in our lab so the first option would work fine. However, we wouldn’t want our customers to do that. We certainly don’t want them to have manually sign each one either. The answer? vCenter Orchestrator (vCO) and the REST plugin. Luckily for me a fellow who goes by nemski who blogs over at SYSADMIN4LYFE had posted how to setup the vCO workflow to do this, as well as additional Puppet master configuration that is needed. I’ll detail out the steps as well below.

Before we get started

  • You’ll need to have vCenter Orchestrator installed
  • You’ll need to have the REST plugin installed (install document)
  • You need to have Puppet installed
  • Import the Puppet master SSL certificate into vCenter Orchestrator
    • Log into the configuration page of vCO https:<vco-hostname-or-ip>//:8283
    • Navigate to the Network tab on the left > click SSL Trust Manager on the right
    • At the bottom enter in the following URL in the Import from URL section: https://<puppetmaster-hostname-or-ip>:8140
    • Click the Import button > accept the certificate
    • You should now see the Puppet CA and the Puppet hostname show in the list

Configure Puppet Master for vCO Communication

We need to tell the Puppet master that vCO is allowed to talk to it and perform operations on it. We do this by editing the /etc/puppet/auth.conf file

  • SSH or console in to your Puppet master and use your favorite text editor to open /etc/puppet/auth.conf
  • Go to the very bottom of the file. Right above the deny everything else; block enter in the following:
  • Save the file and restart the Puppet master (service restart puppetmaster)

Generate a new REST operation

  • Log into your vCO client and select Run from the dropdown > click the Workflows button

image

  • Expand Library > expand HTTP-REST > expand Configuration > right-click Add a REST host and select Start Workflow…
  • Enter in a name for, such as the name of your Puppet master > enter in the same URL you used when adding the Puppet master certificate to vCO (https://<puppetmaster-hostname-or-ip:8140)
  • Click Next

image

  • Leave at No for the Use Proxy (unless you are) > click Next
  • Ensure Host Authentication Type is set to NONE > click Submit

Create vCO Workflow

We need to create the initial vCO workflow to execute the REST operation we just created. This workflow will get wrapped in the final workflow being called during vRA machine provisioning.

  • In the vCO client, expand the HTTP-REST folder
  • Right-click Generate a new workflow from a REST operation > click Start Workflow…
  • In the Operation field click the Not Set hyperlink > expand the tree until you see the Sign certificate request operation you created earlier > select the operation and click the Select button

  • The Content field should be text/pson > click Next
  • In the Folder field click the Not Set hyperlink and select a folder for the workflow to reside
  • Click the Submit button

Modify the Workflow

Before we can create the final workflow we need to edit the one that we just generated. We are editing this in order to make the content parameter an attribute instead of it being an input parameter that needs to be inputted each time the workflow runs

  • In the vCO client, navigate to the folder you set when you created the workflow
  • Right-click on the workflow you just created and click Edit
  • Click the Inputs tab > from the parameter list right-click the content parameter > click Delete Selected
  • Click the Schema tab > highlight the Scripting task and click the pencil icon to edit it

  • A window will now popup, select the IN tab
  • Find the content parameter and next to not set click that row. This should open up a new window that looks like this: (if it doesn’t look like this, close whatever opened and try again)

  • Click the Create parameter/attribute in workflow hyperlink
  • In the Value field type {“desired_state”:”signed”}
  • click OK

  • Click the Close button
  • Click the Save and Close button in the bottom right
  • If you want to add it to the version history click Increase Version, otherwise click Continue anyway

Create Overall vCO Workflow

This has been a long post, but stick with it, just a few more steps to go. Now we need to create the overall workflow that will allow the hostname provided in the vRA machine request to be passed into our new workflow

  • In the vCO client expand the following folder structure:
  • vCloud Automation Center > Infrastructure Administration > Extensibility
  • The last workflow listed there is Workflow Template > right-click that and select Duplicate Workflow…
  • Change the name to something meaningful, such as Sign Puppet Request > select a location for this duplicate workflow to something outside the default folders

  • Click the Submit button
  • Right-click the newly create workflow and click Edit
  • Click on the Inputs tab
  • Delete the additionalnputFilledByBlueprintProperty parameter and the vCloudVApp parameter

  • On the left-hand side click the Generic hyperlink
  • Find the item that says Workflow elem… > click and drag it to the right and place it after Display Inputs
  • A box pops up where you can search for the workflow name to add. Search for the workflow you just modified and select it > click the Select button

  • Select the workflow you just added
  • In the upper right, click the Setup… button

  • Expand the window so you can read everything > you should see hostname selected in the first dropdown with options to the right of it > select the Value radial button
  • From the Value column click the Input Value hyperlink and type in hostname
  • Click Ok
  • In the Promote Workflow Output Parameters click the Skip radial button in the Reset all bindings to:

  • Select the Display Inputs task > click the Setup… button in the upper right
  • Next to Reset all bindings to: choose the Skip radial button
  • Click Promote
  • Click the Display Inputs task and click the pencil icon to edit it
  • Click the IN tab > remove the vCloudVApp parameter
  • Click the Scripting tab > on the left, Action should be select > on the right, delete everything
  • Enter in the following:
  • Go back to the IN tab. If the local parameters have NULL for their Source parameter edit the Source Parameter to match the Local parameter. See below

  • Click the OUT tab > click the Bind to workflow attribute/parameter button
  • Place a check int he checkbox for hostname > click Select

  • Click the Close button
  • Click the Save and close button to save the new workflow > decide whether or not to add to the version history

So we’re all done, right? No, not just yet! First we need to make sure that if you’re running vCAC/vRA 6.1 that you’ve applied a patch that is needed. We also need to setup vRA to allow the WorkFlow (WF) stubs to be executed from vCO instead of internally. Lastly we need to tell vRA that once a machine from one or more blueprint has been provisioned that it will invoke the new workflow we just created

Install Patch

I’m not going to go over instructions on how to install the patch (it’s a vCO package, just import it) but this is the patch you’ll need. The picture below shows you the file you need

Install vCO Customization

  • n the vCO client expand the following folder structure:
  • vCloud Automation Center > Infrastructure Administration > Configuration
  • Right-click the Add a vCAC host workflow and select Start Workflow…
  • Enter in the name of you IaaS host and the URL in the format of https://<iaas-hostname-or-ip>
  • Click Next
  • Enter in your Tenant name and username and password > click Submit
  • In the vCO client expand the following folder structure:
  • vCloud Automation Center > Infrastructure Administration > Extensibility > Installation
  • Right-click the Install vCO customization workflow and click Start Workflow…
  • Click the Not set hyperlink > expand vCAC Infrastructure Administration > select the IaaS server you just added
  • Click the Select button > click Next
  • Select Yes for every option and click Submit

Configure your new workflow to execute during a state change

Here you will select which state you want the workflow to run at, which blueprint(s) you want it to apply to and which workflow you want to run

  • In the vCO client expand the following folder structure:
  • vCloud Automation Center > Infrastructure Administration > Extensibility
  • Right-click Assign a state change workflow to a blueprint and its virtual machines > click Start Workflow…
  • Select MachineProvisioned for the workflow stub
  • Set your vCAC host (should be the IaaS host you added earlier)

  • Click Next
  • Click the Array hyperlink > if there is a blueprint already added with no name, select it and remove it
  • Click the Insert value hyperlink
  • Use the left and navigate to the blueprint you want this new workflow to apply to > click Add > repeat this process for any more blueprints you want to add. Keep in mind these blueprints should have the puppet agent loaded on it or this won’t work
  • Click the Select button
  • You should see your blueprint(s) show up > click Accept

  • If you want to apply this to existing virtual machine that have been provisioined from the selected blueprint(s) select Yes > click Next
  • Click the Workflow template hyperlink and search for the workflow you want to add. Make sure this is the OVERALL workflow you created and not the one that was automatically generated
  • Click Select
  • Click Submit

Congrats! You’ve successfully went through the necessary steps to allow VMs being provisioned from vRA to have their Puppet certificates automatically signed and ready to have manifests applied without having to manually log in to the Puppet master and manually sign them and without comprimising security!

I want to give a HUGE shoutout to Steve Kaplan. Steve is a vCO genius and helped me with the passing of the hostname property from the vRA blueprint into the REST workflow. I think I’d still be stuck without his help. Thanks again Steve!

Leave a Reply to Anonymous Cancel reply

Your email address will not be published. Required fields are marked *

*