Background
Acceptance Testing
simp-beaker-helpers has several fun abilities with PKI certs. It can:
- generate PKI certificates for each SUT
- install a working keydist/ onto a Puppet Master (for testing profiles)
- install PKI certificates for each host without keydist/ from pki::copy (for testing modules)
However, acceptance testing for PKI has exposed that each module handles PKI certs differently with parameters and logic.
Parameters
In various modules that deal with PKI, parameters such as the following have been observed:
$enable_pki = true
Does this turn PKI on/off, turn PKI management on/off, turn the SIMP-specific PKI system on/off (see: The New Layout for all SIMP Modules)?
$use_simp_pki
= true
Okay, this looks like it explicitly means "Use SIMP's PKI system (e.g., FakeCA, keydist/, pki::copy)"
$cert_source
= '/absolute/path/to/dir'
- simp-apache & simp-rsyslog: Defines what directory look for certs in a
Suggested Alternative Name:
$pki_cert_dir = '/same/as/cert_source/w/a/better/name'
Individual cert files (names differ between examples, but basically):
$pki_cert_file = "${::modulename::cert_source}/public/${::fqdn}.pub"
$pki_key_file = "${::modulename::cert_source}/private/${::fqdn}.pem"
$pki_ca_file = "${::modulename::cert_source}/cacerts/cacerts.pem"
NOTE: The fact
$::fqdn
is used instead of$::trusted['certname']
because masterless environments such as "puppet apply"
must be honored.
- Various tweaks (probably vary from:
$enable_ssl = true # Turn SSL on or off
$validate_ssl = true # vsftpd setting
- $validation_depth = 2 # example of app-specific setting; apache uses this for SSL
- There are variations and permutation of these parameters across all modules; and we should standardize them
Responsibilites
- MANAGE: How should we tell a SIMP module to manage PKI (at all)?
- The opposite of "manage" is "leave it alone."
- Examples of management:
- where to look for certs, cacerts
- ensure that PKI/SSL is on or off
- ensure that PKI/SSL is validated
- These may all be controlled by subsequent parameters
- Examples of something other than management:
- Distributing certificates on the filesystem
- This is EXTRA because it needs additional information and can change
- Distributing certificates on the filesystem
- current param:
$enable_pki (bool)
- suggested param:
$manage_pki (bool or see below)
- QUESTION what should the type be?
- QUESTION what should the type be?
ASSETS: What resources does the module need to know about to integrate PKI?
PKI assets = key, cert, cacert
file-based: x509+RSA files
simp-pki module's
pki::copy
from FakeCAsimp-beaker-helpers gem's
pki_copy_to
function.IMPORTANT: Independent file delivery mechanism
The files get there, but in a way SIMP (and possibly Puppet) doesn't manage
probably no need to do anything
QUESTION: Is it reasonable to always expect PKI cert/key/cacert to be present in the same directory structure as pki::copy?
- file-based: java keystore / truststore
- moonshots (probably not feasible):
PKI stored in LDAP
PKI stored in TPM
DISTRO: What PKI asset distribution methods should SIMP manage?
SIMP has the pki::copy function, which copies the host's cert+key+cacert into a local directory
the structure:
HOST_PKI_DIR/
cacerts/cacerts.pem
public/fdqn.pub
private/fdqn.pem
- This supports individual PKI distribution per-application
- accommodates SELinux
- some applications (particularly in multi-homed environments) some use separate PKI certs/CAs
- current param:
$use_simp_pki (bool)
suggested param:
$use_simp_pki or $manage_pki
(if "Stroolean")
Questions
- How do we tell a SIMP module to use a given distribution method?
- Additional question: will (should) we manage distribution methods other than SIMP?
- Some modules use an extra parameter,
$use_simp_pki
, to turn onpki::copy
- Additional question: will (should) we manage distribution methods other than SIMP?
- How do we tell a SIMP module to use a given distribution method?
- WTF is a Stroolean?
- A parameter that is either the boolean
false
or a String that determines the source (e.g., 'simp
',
something else we might manage in the future) - Pros:
- It collapses manage_pki and use_simp_pki into a single parameter
- It models the idea that if the SIMP module supports PKI integration, it must be expecting a particular distribution method.
- Cons:
- It's confusing
- It complicates validation logic and usage
- PuppetForge will probably ding us on the logic
- MANAGE and DISTRO are conceptually different responsibilities:
- It is true that DISTRO being on or off isn't relevant if MANAGE if off, but they are separate concepts.
- It is true that DISTRO being on or off isn't relevant if MANAGE if off, but they are separate concepts.
- A parameter that is either the boolean
- What parameters should we standardize on?
- $manage_pki:
- Formerly named
enable_pki
. - Type: We have a choice:
- boolean
- true = manage PKI integration for this module
- false = do not manage PKI aspects of this module
- "Stroolean:
- The most Trevor
- It will either be the boolean
false
or a String that determines the source (e.g., 'simp
', 'simp
', - Pros:
- It collapses manage_pki and use_simp_pki
- boolean
- Formerly named
- $pki_source (String) or $use_simp_pki (boolean)
- $manage_pki:
Action items
- Decide (record decisions/reasoning):
- whether or not to rename all "$enable_*" parameters to "$manage_*"
- $manage_pki : Boolean or Stroolean?