One mainly would use the AAA server when there isn't a managed CA like the one from Puppet easily available, typically clients in that scenario has a desire to have no certificates at all - just a choria client.
We therefor need to support anonymous TLS where the connection is still encrypted using TLS but it's not verified.
When supporting this mode it's very important that the core Choria network does not run in downgraded security mode, so we will use a NATS technology called leafnodes to create a dedicated Choria Broker these clients would use for access.
There is of course a higher risk of middleman attacks but the use of the AAA server model would mitigate that, messages could be intercepted and observed though without any warning.
Choria does not by default accept connections from Leafnode servers, this should be enabled using:
plugin.choria.network.leafnode_port = 9222This is a Leafnode protocol port that should only allow connections from the Leafnode servers, it will be using TLS the same as Choria - accepting only leafnode connections from servers with certificates issued by the trusted CA
You enable this seting on your core Choria cluster that's currently being used and that is secured using full verified TLS.
Choria broker support being a leafnode out of the box, it requires some configuration. If you are running this
as root on a machine with Puppet certificates it will use that nodes certificates to connect to the Choria network
else you can specify some using the file security provider as here:
loglevel = debug
plugin.choria.broker_network = true
plugin.choria.network.client_port = 7222
plugin.choria.network.peer_port = 0
plugin.choria.network.leafnode_port = 9222
plugin.choria.network.leafnode_remotes = choria
plugin.choria.network.leafnode_remote.choria.url = nats://choria.exmple.net:7422
plugin.security.provider = file
plugin.security.file.certificate = /path/to/cert.pem
plugin.security.file.key = /path/to/key.pem
plugin.security.file.ca = /path/to/ca.pem
# all 3 these are required
plugin.choria.network.client_anon_tls = true
plugin.choria.network.deny_server_connections = true
plugin.choria.network.client_hosts = 192.168.0.0/16The cert here should be issued by the CA managing the choria network. In this scenario
this is the only place where you would need certificate managed by the Choria CA to
gain access to Choria. Do not name these certificates like xx.mcollective, use a
hostname or similar, this makes it clear that the certificate can not be used ever
to make Choria requests should it be leaked.
Runing choria broker run --config leafnode.conf should start Choria Broker and
connect to the core Choria network on choria.exmple.net:7422
To configure a client for anonymous TLS you must have a remote signer configured
loglevel = info
# where the leafnode listens, you can use SRV or whatever you like
plugin.choria.middleware_hosts = localhost:7222
# all 3 are required
plugin.security.client_anon_tls = true
plugin.choria.security.request_signer.token_file = ~/.choria.token
plugin.choria.security.request_signer.url = https://caaa.example.net/choria/v1/signThis client should not need any TLS files to function.
This is only supported in the Go client at present