Consul TLS verification from k8s cluster to Consul Server

Consul
6

@andriktr I did. Thank you for reminding me to update.

I resolved it by creating a new CA with

sudo consul tls ca create -name-constraint -additional-name-constraint=<SAN1> -additional-name-constraint=<SAN2> --additional-name-constraint=<SAN3>

SAN1 is the DNS name of the cluster, SAN2 is the IP of the CA server, SAN3 is the hostname of the CA server. I’m not sure if using the IP as a SAN was really needed, but it didn’t hurt.

then I created a san.cnf file with

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
[ req_distinguished_name ]
countryName                 = <country>
stateOrProvinceName         = <state>
localityName               = <locale>
organizationName           = <org>
commonName                 = <CN>
[ req_ext ]
subjectAltName = @alt_names
[alt_names]
DNS.1   = <SAN1>
DNS.2   = <SAN2>
DNS.3   = <SAN3>

and the certificate + key for each server, which I put into /etc/consul.d and chowned to consul:consul

sudo openssl x509 -extensions req_ext -req -in <server hostname>.csr -CA consul-agent-ca.pem -CAkey consul-agent-ca-key.pem -CAcreateserial -extfile san.cnf -out <server hostname>.crt

finally the consul.hcl

ca_file = "/etc/consul.d/consul-agent-ca.pem"
cert_file = "/etc/consul.d/<server hostname>.crt"
key_file = "/etc/consul.d/<server hostname>.key"
verify_incoming = false
verify_outgoing = false
verify_server_hostname = false
auto_encrypt = {
  allow_tls = true
}
ports = {
  http = 8500
  https = 8501
  grpc = 8502
  serf_lan = 8301
  serf_wan = 8302
  server = 8300
}

TLS between the cluster and Consul servers now works, and I can spin up Consul Connect and CatalogSync sidecars (although we’re having severe issues with Connect causing pod evictions that I haven’t been able to gather enough data on to fully troubleshoot). I haven’t yet tried full verification or disabling http, but will try and report back.