...

Outside of SIMP, git-based control repositories have become  are the dominant technology to manage and deploy Puppet code.

...

Defining everything needed to create a Puppet environment enables allows Puppet Environments to be handled like code:

...

SIMP + Multiple Puppet environments

Image Added

Limitations and conflicts

It has been technically possible to use multiple Puppet environments and control repositories since SIMP 5.0 (

However, in practice this has been cumbersome and easy to get wrong.  Getting it wrong risks  can accidentally leaking leak or losing lose site data (such as passgen secrets and PKI files).  Getting it right requires an in-depth knowledge of Puppet environments and SIMP's "extra" environments.  Even when handled wellthen, there are still some significant limitations—for instance, it still won't be feasible to host 's not possible to pool redundant (compile) masters behind a VIP unless site administrators arrange some method implement their solution to keep the SIMP "extra" environment data in sync across each server.The recent

Issue 1: SIMP RPMs and tools interfere with files under the Puppet and SIMP environment directories 

The specifics of this issue have changed over the years, and were largely "solved" when SIMP 6.4+ stopped deploying RPMs into environment directories.

Starting with 6.4.0 release (

However, there are still two major problems when using SIMP 6.4.0 with multiple Puppet environments and control repositories:

Issue 1: SIMP automatically interferes with files under the Puppet and SIMP environment directories 

This issue is effectively fixed in 6.4+,

1. Status
   colour Red title SIMP 5.0-6.3

    RPM updates and simp_rpm_helper could modify existing files Puppet and SIMP environment directories

2. Status
   colour Red title SIMP 5.0-6.3

    User-initiated tools like simp config could modify existing files Puppet and SIMP environment directories

3. Status
   colour GreenBlue title SIMP 6.4

    

   Status
   colour Yellow title PARTIALLY FIXED

    The user-initiated tool simp environment new can  new can ensure that there is a corresponding secondary and writable environments
   1. This is a safety improvement from earlier releases, because it only alters environment files when the user initiates it
   2. However, the the simp environment tool  tool is only partially implemented, and the rest remaining actions cannot be implemented safely.
   3. As things stand, this means that SIMP 6.4.0:
      1. Safely supports SIMP extra data with in the Local (Puppetfile-only) deployment scenario with  with a single environment (production)
      2. Does not safely support SIMP extra data with in the Control Repository deployment scenarios (without additional conventions and limitations)

Issue 2: SIMP expects

...

Secondary and Writable

...

asset paths for each Puppet environment

...

SIMP has always assumed

...

that each Puppet environment directory will be accompanied by two SIMP-specific "environment" data directories

...

:

1. Status
   colour Red title SIMP (ALL)

    "Secondary" data/assets under /var/simp/environments/$environment/.  
   These are files too sensitive and/or too large to check into git in plaintext, maintained by site admins.
   1. "Site Files" modules, like pki_files (keydist) and krb3_files. 
   2. The FakeCA support script, including the FakeCA's private key
   3. RSync directories, used by the simp::server::rsync_shares profile to serve files for various modules.
      
      

2. Status
   colour Red title SIMP (ALL)

    "Writable" data/assets under under /opt/puppetlabs/server/data/puppetserver/simp/environments/$environment/
These are secrets, read by certain special SIMP Puppet functions while compiling catalogs (and automatically generated if they are missing).
   There are currently only two Puppet functions in SIMP that use the writeable environment directory:
   1. simplib::passgen()
      • a popular function, used to generate secret passwords
      • Used in 14 SIMP modules—usually modules
      • Usually (but not always) exposed as a parameter default
      • Secrets read by this function can also be generated by the simp passgen CLI tool
   2. ssh::autokey()—this function is unused by the stock SIMP modules, but .  It is provided to allow local admins a way to automatically set up SSH keys as needed.arrange SSH keys for service accounts.

SIMP running a single Puppet environment (safe)

A stock SIMP install starts with a unified SIMP Omni-Environment, production.

Image Added

Issues with SIMP and multiple Puppet environments

After deploying a new Puppet environment (new_env, forked from production), there are several problems:

Image Added

1. (Red lines) The modulepath setting in environment.conf still points to production.
   1.  Puppet catalogs compiled in new_env still source secondary module data (FakeCA PKI, Kerberos) from production!
   2. Any pki/krb3 files under /var/simp/environments/new_env/site_files are never used.
      
      
2. (Blue lines) the SIMP "extra" ("secondary" and "writable") environment directories don't exist for new_env yet!
   
   1. Puppet code using SIMP's rsync type will fail in the new_env environment, because the source path will not exist.
      • (The rsync type is used in 14 SIMP modules)
   2.  simplib::passgen() will silently create new and different secrets for each identifier in the new_env environment
      
      • This breaks authentication with passgen-configured accounts/services still in production.
        • e.g., TPM/TPM2 owner authentication, kdb5 passwords, rsync servers, SIMP GitLab auth
      • This is especially destructive to Canary nodes'—after successfully testing a new account/service that uses passgen-configured credentials, authentication will break after the node is returned to production.
        

Environment safety improvements in SIMP 6.4.0

...

SIMP 6.4.0 addressed many of SIMP's tool and RPM-related problems by making Puppetfile-based module deployments the preferred method to deploy modules.

• Puppetfile-based deployment tools like r10k or Code Manager and now preferred to deploy SIMP's Puppet modules
  • To prevent conflicts with these tools, SIMP no longer interferes with any files under the Puppet or SIMP environment directories, unless directed to by the user.
• SIMP module RPMs now install tagged versions into local git repositories, for use in local Puppetfiles
  • The simp puppetfile tool was introduced to automatically generate Puppetfiles based on the current module RPMs.
• The simp environment new tool was introduced to help users ensure that corresponding SIMP and Puppet environments are created.

Improvements focused on making it simple to use Puppetfiles in a single environment, with multiple 

...

Safely Referencing SIMP assets from multiple Puppet Environments

Okay: Ensuring new SIMP extra environments with simp environment new

Site admins must ensure that SIMP "extra" environment directories exist for every Puppet environment.  There are basically three strategies for this:

1. Create a new "clean" SIMP extra environment directories for the new environment
2. Link to another SIMP extra environment to keep all assets the same
   1. pros: keeps environments' 
   2. cons:  linked directories can fool admins into thinking it is safe to alter/remove data from a 
3. Copy directories from another SIMP extra environment

These choices in have been automated in SIMP 6.4.0 by the simp environment new tool.

Problems

During the development of SIMP 6.4.0, it became apparent that the simp environment workflow would have problems down the road:

• Making Requiring a new SIMP writable and secondary environment to exist for ever every Puppet environment was arbitrary The dependence on $environment made it necessary to adopt a mistake. 
  • It requires coarse workarounds like `simp environment new [--copy|--link]`
    • every time a new Puppet environment is deployed
    • even when environments used the same (or similar) resources
  • Linked 
  It would be
  • It prevents referring to a mix of the same assets in some cases
  • It adds a source of truth that is independent from the control repository
  • Linked SIMP extra environments make it easy to assume that it is safe to alter/delete assets, because the path shows an unimportant name
• The proposed simp environment rm command would make it too easy to permanently lose data from in linked environments with the proposed simp environment rm command

Image Removed

Proposed SIMP 6.5+

Image Removed

Legacy 6.4 assets in SIMP 6.5+

Image Removed

...

Good: Using GPG+EYAML in the control repo to replace Writeable environment data

Problems

• Not all uses of simplib::passgen() in the SIMP codebase are exposed as parameters

Better: Define the site_files directory.independently of the environment

Better yet: 

Image Added