Config Management Camp 2024 Ghent

Since the beginning of the project, salt has used a custom cryptographic implementation based on RSA to encrypt messages between masters and minions over what is called the transport. I will present a new scheme that uses a standard implementation of mTLS. Although salt is supremely modular, the crypto backend was never made pluggable. The builtin crypto implementation is spread across several source files and is closely interconnected with both the ZeroMQ and TCP transports. Rather than insert a new crypto backend alongside the existing crypto implementation at each point across the several files, the new crypto backend uses a new, simpler design, mainly because mTLS can be used out of the box in contrast to custom RSA key management, trust on first use, static auth token seed (for reals), etc. Because of the close mixing of transport and crypto code, the opportunity was taken to introduce WebSockets as a new transport as well. Great, so what about post quantum crypto? Since the mTLS backend is not implemented in the source code, crypto algorithms and primitives, including those certified for PQC, FIPS, etc. can now be easily swapped in with no change to the user code.

In a small environment a single devops engineer or team of engineers can automate changes to production with a well tuned configuration management system. In a large production environment that spans the globe and contains more functional parts than a single team could manage, running config management as continuous delivery is practically untenable. Risky changes need to be incremented by smaller deployment steps or separated into smaller deliverables. High risk services and locations need more validation time before accepting changes. With many teams pushing dozens of changes to production daily, there is a need for health-mediated deployment. Ideally, service owners self-serve change management+health metrics with state enforcement completely decoupled and below the API.