See https://github.com/schmichael/nomad-tls for sample configs.
- Consul uses
sslinstead oftlsconfig parameters - Consul uses
verify_sslinstead ofverify_tls consul.cert_fileshould specify that it's the client certificate used for mutual authentication.consul.{ca,cert,key}_fileshould default totls.{ca,cert,key}_file
verify_ssldocs should specify that theconsul.addressmust include a host/IP -- this seems like a bug as everywhere else we validate that the certificate is valid for{client,server}.{datacenter,region}.{consul,nomad}- There should be a facility to configure Nomad's CLI to use TLS by default (with the proper CA)
- Environment variable?
- Config file(s)? (eg
/etc/nomad/*.hcloverridden by$HOME/.nomad/*.hcl?)
All servers must have a certificate valid for server.. or the client will reject the handshake.
I couldn't find a definition of <domain>. It seems to mean nomad or consul. However traditionally certificates are issued to "domains" in the DNS sense of the word, so it's quite confusing.
Similar to the <domain> issue, the reason to use TLS to communicate from Nomad to Consul is a bit non-intuitive.
The first benefit people usually associate with TLS is encryption across the wire. However Nomad communicates with Consul locally (the integration doesn't even work entirely with a shared Consul instance) -- you don't need TLS to communicate securely with localhost.
The reason why TLS is still beneficial locally is to ensure what Nomad is talking to is actually Consul. Any unprivileged process can bind to 127.0.0.1:8500 and impresonate Consul. Using TLS means in order to impersonate Consul the process has access to Consul's certificate+key which (should) require privileged access.