Page Comparison

...

• 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 FakeCA

      • simp-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

• What PKI-related parameters should we standardize on?
   
• 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 parametera boolean parameter, $use_simp_pki, to turn on pki::copy
  • Any alternative delivery mechanism is currently not managed by SIMP
     
    How do we tell a SIMP module to use a given distribution method
    • • Additional question: will (should) we manage distribution methods other than SIMP?
    
    
  • 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.
          
    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 
      $pki_source (String) or $use_simp_pki (boolean)

  
  

  Action items

  •  Decide (record decisions/reasoning):
    
    •   whether or not to rename all "$enable_*" parameters to "$manage_*" 
    •  $manage_pki : Boolean or Stroolean?
  •