Katello/Candlepin integration

The Katello project is integrating Foreman, so that a system can be created in Katello and provisioned under the hood by Foreman.

Once provisioned the system will need its Candlepin registration information in order to communicate with Katello, fetch content from Pulp etc. This page tracks the design and work to automate this.

What's there today

Katello bootstrap RPM

katello-configure generates an RPM containing the Candlepin CA certificate and a postinstall that configures subscription-manager.


subscription-manager is the client tool used to register a system to Candlepin. It has three registration modes:

  • register with username and password, creates new registration
    • subscription-manager register --username=.. --password=..
  • by activation key, creates a new registration, subscribes to pre-defined products
    • subscription-manager register --activationkey=..
  • by consumer ID (UUID) with username and password, uses existing registration
    • subscription-manager register --username=.. --password=.. --consumerid=..

For an existing registration, registering the client with a known UUID is the way forward, though this currently requires a Candlepin user/pass to access the getConsumer API.

Foreman API

Katello can use the Foreman API to trigger creation of new hosts, provided it supplies the hostname, MAC, host group, network, domain, OS etc.

Puppet certificates

Foreman enables autosigning for the system hostname during its build and removes autosigning post-build. This is a second set of certificates that work in a similar way to Candlepin's, they could be combined.

Katello is also planning a certificate redesign to simplify their CA setup and support external trusted CAs.

Spacewalk/redhat_register comparison

Clients can be built from Foreman today and registered to Spacewalk using the supplied redhat_register provisioning template snippet. This calls the legacy rhnreg_ks utility to create a new registration for the host using an pre-created activation key. The host registration doesn't already exist in Spacewalk.

Design options

All design options involve pre-registration in Katello/Candlepin, which is the desired workflow. Similarly, Katello would take responsibility for certificate revokation, rather than Foreman (proxy) invoking this.

Register with UUID and subscription-manager

  1. Register system in Katello, which registers in Foreman
  2. Set host parameter containing UUID and secret value
  3. %post snippet will perform subscription-manager register with UUID and secret value - downloads key and cert
  4. %post runs Puppet, generates key, downloads certificate via CSR
  • Needs ability to register by UUID without user/pass, perhaps addition of a secret value?
  • How to pass secret value? Probably can't, use a one-time token with the UUID to get access.
  • If compromised (the ks is public) then the admin can re-register (or cancel/reinstate build) which would revoke the cert.
  • Are admins used to re-registering builds on failures - will they try and rebuild without it?

Push down existing private key and cert

Same as above really, except rather than using the UUID and a token to gain access to the key and cert from Candlepin, they're pushed down directly during the installation.

  • Less secure as key could be duplicated, better to use a secret value that acts as a one-time password

Autosign mechanism

There's already a workflow for getting a certificate to the Puppet client, so use the same workflow to get a Candlepin certificate:

  1. Generate a private key and CSR on the system
  2. Send CSR to Candlepin
  3. Sign any CSR that comes in with the correct hostname or UUID, but only one
  • Needs autosign interface added to Candlepin
    • significant work
    • increases attack surface of Candlepin (Puppet has had a CVE)
  • Guarantee only one copy of the system's key, since it remains there and is only signed once

Use Candlepin cert for Puppet

In all scenarios, the key and certificate used for Candlepin/Katello could be reused for Puppet. The CA functionality of Puppet could be disabled, the master's server certificate generated (with appropriate aliases) and the keys/certs either copied into place on built systems or the Puppet client reconfigured to read from subscription-manager key/cert locations.