RFC: Redesign Certificate Handling within Foreman Deployments

I am posting an update here with a proof of concept based off the CLI proposal. This is intended to test the simple design, identify any modifications and use it as a basis for how to proceed.

Proof of Concept

I built a clamp-based Ruby CLI named foreman_pki to generate a certificate authority and a set of certificates based on the needs of the installation.

The set of certificates desired are pre-defined bundles that define the standard set of needed certificates for an installation. In the proof of concept, this includes the bundle for Foreman, Katello and a Smart Proxy. Bundles can be enabled via a configuration file.

The implementation places all certificates under a common structure as seen below. The common structure was designed to make it easy to locate all certificates for an installation, easy to understand with a common naming structure and allow installer/puppet modules to control permissions on the certificates per the needs of a given service. There is an additional naming scheme introduced for client certificates to better understand what a certificate is used for. For example, when Katello is present and needs to communicate with Pulp a foreman-pulp certificate is generated. This is different than Foreman needing to talk to smart-proxies which get a foreman-to-smart-proxy certificate name.

root@foreman foreman_pki (master)$ tree /etc/foreman_pki/certs/
/etc/foreman_pki/certs/
├── apache
│   ├── apache.crt
│   └── apache.key
├── artemis
│   ├── password
│   └── truststore
├── ca
│   ├── ca.crt
│   └── ca.key
├── candlepin
│   ├── ca.crt
│   └── ca.key
├── foreman
│   ├── foreman-to-candlepin.crt
│   ├── foreman-to-candlepin.key
│   ├── foreman-to-pulp.crt
│   ├── foreman-to-pulp.key
│   ├── foreman-to-smart-proxy.crt
│   └── foreman-to-smart-proxy.key
├── smart-proxy
│   ├── smart-proxy.crt
│   └── smart-proxy.key
└── tomcat
    ├── keystore
    ├── password
    ├── tomcat.crt
    └── tomcat.key

Usage

Usage:
    foreman-pki [OPTIONS] SUBCOMMAND [ARG] ...

Parameters:
    SUBCOMMAND    subcommand
    [ARG] ...     subcommand arguments

Subcommands:
    generate      Generate certificates
    view          View a certificate
    list          List all certificates
    verify        Verify all certificates
    import-ca     Import a CA
    export        Export certificate bundle as a tarball
    import        Import certificate bundle

Options:
    -h, --help    print help

From the installer’s perspective, the foreman-pki generate command can be ran by the installer to create all of the certificates after laying down a config.yaml file. Let’s look at a few examples running this outside the context of the installer:

Foreman Install:

$ cat <<EOT >> /etc/foreman_pki/conifg.yaml
Bundles:
foreman
EOT
$ foreman-pki generate
$ foreman-installer --scenario foreman

Now if one were to add Katello:

$ cat <<EOT >> /etc/foreman_pki/conifg.yaml
Bundles:
Foreman
katello
EOT

$ foreman-pki generate
$ foreman-installer --scenario katello

Notes

The current proof of concept can import a certificate if pointed to a CA certificate and private key pair on disk. There is currently no integration with an HTTP based CA such a Puppet CA or Vault. The goal was to nail the simple use cases while considering how Katello installations handle certificates today. The current implementation can importa Puppet CA but using the import-ca command pointed at the Puppet CA cert and key on disk.

Thoughts and discussion are encouraged so that I can figure out next steps.

4 Likes