It’s been almost 5 months since our last release, not because nothing has been happening but because so much has been happening, good problems to have!
So this is a bit of a massive release, however I think the bulk of the changes will not affect our typical Puppet based users.
This introduces first work of a new Choria Registry. We have a long-standing pain point around managing DDL files on clients, it’s a technical
requirement to describe remote services but it’s just a pain to maintain, Puppet helps but for clients in CI, desktops etc, the DDL requirement
is just too much.
Choria Server now has an option to act as a Registry where it can read it’s local DDL directory and serve that up to clients on demand.
When a client tries to access a new agent it has never accessed before it will ask the registry for the DDL describing that agent. It will
also do so regularly to ensure the local cache is still accurate.
This means that we can now have truly single-file client deployments. With just the
choria binary and a running Registry that choria client
can interact with the entire fleet and do everything it wants. This is a great improvement for deployment of client machines and making Choria
more generally useful without Configuration Management.
The Choria Server can be a Registry, running multiple Servers with registry enabled will create a failure tolerant HA cluster of registry servers.
This is a brand-new feature, so I am not yet documenting it publicly, but I am keen to talk to users who wish to help in validating this before
we look to supporting this more widely.
Non mTLS communications
The major work here that contributed to the 20 000 line code change in Choria Server is that we now support a secure non mTLS mode
of communication. This is of no consequence for Puppet users so if that’s you feel free to skip this section.
With a typical deployment we use the Puppet CA to create a fully managed and closed mTLS based network. For some enterprises replicating
that with their internal PKI infrastructure is nearly impossible. So we looked to, optionally, move away from a pure mTLS mode to a mixed
setup where we use ED25519 keypair and signed JWTs to provide equivalent security.
Essentially we now have formalized our use of JWT into a new
tokens package where servers and clients have their own JWT. We hope to
move entirely over to this model in time as we were able to create a greatly enhanced security model:
- Servers are restricted to only certain collectives, attempting to enter non defined collectives will be denied by the broker
- Servers are restricted to only server traffic flows. A server token cannot make a request to any other server, enforced by the broker
- Servers have a default deny permission set allow specific access to Streams, Governors, Hosting Services and being able to be a Submission Server
- Clients have private reply channels, clients cannot view each others replies
- In addition to Open Policy Agent a set of default deny permissions allowing access to use Streams, administer Streams, use Elections, view Events, use Governors etc
Using these settings moves us to a much more secure and private setup where even between 2 Choria Users traffic is now isolated and secure and this
introduces the first of a security model around our adoption of Choria Streams. We cannot replicate these policies using just certificates. We hope
to move even Puppet users to this model in future but that’s a big undertaking to get right without additional services.
To enable these features one needs to deploy AAA Service and Provisioner - and both of those had recent releases supporting this mode.
As mentioned this is not really a thing that Puppet users should worry about however those in large enterprises who deploy in non-Puppet ways should
keep an eye out for incoming documentation around this feature.
Package Repository Changes
As notified back in September we are moving away from Packagecloud to our own package hosting infrastructure. I am keeping the Packagecloud
infrastructure up for a while but this release and all future ones will not be uploaded there to promote users moving to the new infrastructure.
Thanks to Romain Tartière, Steffy Fort, Tim Meusel and Alexander Olofsson for their contributions to this release