...
However, in practice this has been cumbersome and easy to get wrong. Getting it wrong can accidentally leak or 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 then, there are some significant limitations—for instance, it's not possible to pool redundant (compile) masters behind a VIP unless site administrators implement their solution to keep the SIMP "extra" environment data in sync across each server.
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.
...
RPM updates andStatus colour Red title SIMP 5.0-6.3 simp_rpm_helper
could modify existing files Puppet and SIMP environment directories
User-initiated tools likeStatus colour Red title SIMP 5.0-6.3 simp config could modify existing files Puppet and SIMP environment directories
Status colour Blue title SIMP 6.4
The user-initiated toolStatus colour Yellow title PARTIAL FIX simp environment new
can ensure that there is a corresponding secondary and writable environments- This is a safety improvement from earlier releases, because it only alters environment files when the user initiates it
- However, the
simp environment
tool is only partially implemented, and the remaining actions cannot be implemented safely. - As things stand, this means that SIMP 6.4.0:
- Safely supports SIMP extra data in the Local (Puppetfile-only) deployment scenario with a single environment (production)
- Does not safely support SIMP extra data 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:
...
- (Red lines) The
modulepath
setting inenvironment.conf
still points to production.- Puppet catalogs compiled in new_env still source secondary module data (FakeCA PKI, Kerberos) from
production
! - Any pki/krb3 files under
/var/simp/environments/new_env/site_files
are never used.
- Puppet catalogs compiled in new_env still source secondary module data (FakeCA PKI, Kerberos) from
- (Blue lines) the SIMP "extra" ("secondary" and "writable") environment directories don't exist for new_env yet!
- 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)
- (The
-
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.
- This breaks authentication with passgen-configured accounts/services still in production.
- Puppet code using SIMP's
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.
...
Anchor | ||||
---|---|---|---|---|
|
Status | ||||||
---|---|---|---|---|---|---|
|
Status | ||||
---|---|---|---|---|
|
simp environment new
Site admins must ensure that SIMP "extra" environment directories exist for every Puppet environment. There are basically three strategies for this:
...
During the development of SIMP 6.4.0, it became apparent that the simp environment
workflow would have problems down the road:
Requiring a SIMP writable and secondary environment to exist for every Puppet environment was 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
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 in linked environments
Anchorse02 se02
SE02. Status colour Blue title SIMP 5.0-6.3
(Good:) Using hiera-eyaml in the control repo to replace Writeable environment data
se02 | |
se02 |
colour | Blue |
---|---|
title | SIMP 5.0-6.3 |
Site admins can prevent SIMP from using the Writable
environment directory by overriding all uses of simplib::passgen()
with the Hiera eyaml backend.
...
- Site administrators are responsible to manage and distribute the hiera-eyaml key files (independently of SIMP)
- key files must exist at the paths
hiera.yaml
expects them on compile masters
- key files must exist at the paths
- simp_apache, when
$simp_apache::web_root
is true: https://github.com/simp/pupmod-simp-simp_apache/blob/6.2.0/manifests/init.pp#L140 - This approach is not possible for some SIMP users
- The SIMP codebase doesn't expose every use of of
simplib::passgen()
as an overridable parameter - Depending on the way your site is configured, you may not be avoid SIMP code
- The SIMP codebase doesn't expose every use of of
Suggested improvements
Expose all uses ofStatus colour Red title FUTURE simp::passgen()
in SIMP classes as parameter defaults, so users can override them viahiera-eyaml
...
Example encrypted data in `data/secrets/site.eyaml`:
No Format --- simp::puppetdb::database_password : > ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==] krb5::kdc::config::kdb5_password: > ENC[PKCS7,Y22exl+OvjDe+drmik2XEeD3VQtl1uZJXFFF2NnrMXDWx0csyqLB/2NOWefv NBTZfOlPvMlAesyr4bUY4I5XeVbVk38XKxeriH69EFAD4CahIZlC8lkE/uDh jJGQfh052eonkungHIcuGKY/5sEbbZl/qufjAtp/ufor15VBJtsXt17tXP4y l5ZP119Fwq8xiREGOL0lVvFYJz2hZc1ppPCNG5lwuLnTekXN/OazNYpf4CMd /HjZFXwcXRtTlzewJLc+/gox2IfByQRhsI/AgogRfYQKocZgFb/DOZoXR7wm IZGeunzwhqfmEtGiqpvJJQ5wVRdzJVpTnANBA5qxeA==] # ...
- For more details, see:
- The Puppet Hiera hierarchy level documentation at https://puppet.com/docs/puppet/5.5/hiera_config_yaml_5.html
- The hiera-eyaml project documentation at https://github.com/voxpupuli/hiera-eyaml
Better:
...