Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • module/manifests/
    • init.pp 
    • params.pp
    • install.pp
    • config.pp
    • service.pp
    • simp/firewall/simp.pp
    • simp/logging/simp.pp
    • simp/audit/simp.pp
    • simp/selinux/simp.pp
    • simp/pki/simp.pp
    • simp/tcpwrappers/simp.pp

Each of these items in bold must adhere to the following:

...

This will look something like the following

$manage_firewall = defined($::manage_firewall) ? $::manage_firewall : hiera('manage_firewall',false)

...

SIMP Subsystems

The bold files above correspond with optional security subsystems that SIMP can integrate with the module's resources. 

  • SIMP subsystems rely on environmental conventions that cannot be assumed to be present outside of SIMP.
  • They are opt-in, so Forge users can use SIMP modules within non-SIMP infrastructures.
  • A full SIMP ecosystem's hiera will enable each subsystem by default in simp_def.yaml
  • IMPORTANT:  These subsystem only manage SIMP-related resources and integrations for the module.
    • Each module may naturally have its own way of configuring PKI, tcpwrappers, etc.  That belongs within the conventional module structure.
      • Examples: enabling SSL or TCP wrappers in a config file, setting SELinux contexts (QUESTION: are the contexts we use SIMP-specific?), 

Class Parameters in  init.pp

Each module willl have the following class parameters in init.pp (when applicable):

  • client_nets
    • Array of Strings/String = subnets to permit, generally in CIDR notation.  This may be required by the module regardless of whether any SIMP subsystems are used.
  • simp_firewall
    • true = includes simp-iptables (NOTE: simp-iptables should be renamed for SIMP6) and  and sets up rules to permit the application
    • false = Firewall settings for the application are not managed; use a profile to make your own arrangements
  • simp_logging
    • true = QUESTION: what will this do?  
  • simp_auditd
    • true
  • simp_selinux
    • true  = includes simp-selinux (which effectively manages the SELinux enforcement and mode) and configures the SELinux booleansmanages SIMP-specific SELinux configurations (QUESTION: like what?)
      • NOTE:  Many SElinux configurations are handled as attributes of native puppet resources.
      •   SIMP. module and are  part of Puppet resources
      • Should one , however, any and will not be featured in this file
      • SE boolean flipping should probably be done here, especially if they rely on the SIMP environment (NOTE: this is pretty vague)
    • false = ???
  • simp_pki
    • true / 'simp' = includes simp-pki and uses pki::copy to distribute PKI certificates to the correct locations
    • false = PKI certificates are not distributed by SIMP; make your own arrangements to get them in place
  • simp_tcpwrappers
    • true = includes simp-tcpwrappers and uses tcpwrappers::allow to permit the application to the subnets in $::client_nets
    • false = TCP wrappers (/etc/hosts.*) entries for the application are not managed; use a profile to make your own arrangements

Each of these parameters must adhere to the following:

  1. The parameter must be disabled (false) by default.
  2. The parameter must honor booleans and Strings where the Boolean true and the String 'simp' amount to the same action.
    1. Welcome to the Trevorian type "Stroolean." (big grin)
    2. The String value such as 'simp' will translate into the filename in the subsystem  path simp/<subsystem>/simp.pp 
      1. This is intended to permit backwards compatibility between SIMP versions if they require mutually exclusive logic.
      2. QUESTION: what is the benefit of these files over the ::params pattern? 
      3. ANSWER
        1. it allows n parallel configs to exist without conflicting
        2. it separates SIMP-specific settings from the rest of the module.
  3. The parameter must allow for an ENC or Hiera or straight parameter, since we want maximum module uptake where possible.
    1. This will look something like the following

      $simp_firewall = defined($::simp_firewall) ? $::simp_firewall : hiera('simp_firewall',false)
      1. QUESTIONShould we make this defined->hiera->default logic a function in simplib? 

Advanced Module Structure

...