Federation Between VMs and Kubernetes

1.8.0+: This feature is available in Consul versions 1.8.0 and higher

This topic requires familiarity with Mesh Gateways and WAN Federation Via Mesh Gateways.

Consul datacenters running on non-kubernetes platforms like VMs or bare metal can be federated with Kubernetes datacenters. Just like with Kubernetes, one datacenter must be the primary.

Kubernetes as the Primary

If your primary datacenter is running on Kubernetes, use the Helm config from the Primary Datacenter section to install Consul.

Once installed, you’ll need to export the following information from the primary Kubernetes cluster:

  1. The certificate authority cert:
  1. kubectl get secrets/consul-ca-cert --template='{{index .data "tls.crt" }}' |
  2.   base64 -D > consul-agent-ca.pem

and the certificate authority signing key:

  1. kubectl get secrets/consul-ca-key --template='{{index .data "tls.key" }}' |
  2.    base64 -D > consul-agent-ca-key.pem

With the consul-agent-ca.pem and consul-agent-ca-key.pem files you can create certificates for your servers and clients running on VMs that share the same certificate authority as your Kubernetes servers.

You can use the consul tls commands to generate those certificates:

  1. # NOTE: consul-agent-ca.pem and consul-agent-ca-key.pem must be in the current
  2. # directory.
  3. $ consul tls cert create -server -dc=vm-dc
  4. ==> WARNING: Server Certificates grants authority to become a
  5.     server and access all state in the cluster including root keys
  6.     and all ACL tokens. Do not distribute them to production hosts
  7.     that are not server nodes. Store them as securely as CA keys.
  8. ==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
  9. ==> Saved vm-dc-server-consul-0.pem
  10. ==> Saved vm-dc-server-consul-0-key.pem

See the help for output of consul tls cert create -h to see more options for generating server certificates.

These certificates can be used in your server config file:

  1. # server.hcl
  2. cert_file = "vm-dc-server-consul-0.pem"
  3. key_file = "vm-dc-server-consul-0-key.pem"
  4. ca_file = "consul-agent-ca.pem"

For clients, you can generate TLS certs with:

  1. $ consul tls cert create -client
  2. ==> Using consul-agent-ca.pem and consul-agent-ca-key.pem
  3. ==> Saved dc1-client-consul-0.pem
  4. ==> Saved dc1-client-consul-0-key.pem

Or use the auto_encrypt feature.

  1. The WAN addresses of the mesh gateways:
  1. $ kubectl exec statefulset/consul-server -- sh -c \
  2.   'curl -sk https://localhost:8501/v1/catalog/service/mesh-gateway | jq ".[].ServiceTaggedAddresses.wan"'
  3. {
  4.   "Address": "1.2.3.4",
  5.   "Port": 443
  6. }
  7. {
  8.   "Address": "1.2.3.4",
  9.   "Port": 443
  10. }

In this example, the addresses are the same because both mesh gateway pods are fronted by the same Kubernetes load balancer.

These addresses will be used in the server config for the primary_gateways setting:

  1. primary_gateways = ["1.2.3.4:443"]
  1. If ACLs are enabled, you’ll also need the replication ACL token:
  1. $ kubectl get secrets/consul-acl-replication-acl-token --template='{{.data.token}}'
  2. e7924dd1-dc3f-f644-da54-81a73ba0a178

This token will be used in the server config for the replication token. You must also create your own agent policy and token.

  1. acls {
  2.   tokens {
  3.     agent = "<your agent token>"
  4.     replication = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
  5.   }
  6. }

  1. If gossip encryption is enabled, you’ll need the key as well. The command to retrieve the key will depend on which Kubernetes secret you’ve stored it in.

    This key will be used in server and client configs for the encrypt setting:

    1. encrypt = "uF+GsbI66cuWU21kiXLze5JLEX5j4iDFlDTb0ZWNpDI="

A final example server config file might look like:

  1. # From above
  2. cert_file = "vm-dc-server-consul-0.pem"
  3. key_file = "vm-dc-server-consul-0-key.pem"
  4. ca_file = "consul-agent-ca.pem"
  5. primary_gateways = ["1.2.3.4:443"]
  6. acl {
  7.   enabled = true
  8.   default_policy = "deny"
  9.   down_policy = "extend-cache"
  10.   tokens {
  11.     agent = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
  12.     replication = "e7924dd1-dc3f-f644-da54-81a73ba0a178"
  13.   }
  14. }
  15. encrypt = "uF+GsbI66cuWU21kiXLze5JLEX5j4iDFlDTb0ZWNpDI="
  17. # Other server settings
  18. server = true
  19. datacenter = "vm-dc"
  20. data_dir = "/opt/consul"
  21. enable_central_service_config = true
  22. primary_datacenter = "dc1"
  23. connect {
  24.   enabled = true
  25.   enable_mesh_gateway_wan_federation = true
  26. }
  27. verify_incoming_rpc = true
  28. verify_outgoing = true
  29. verify_server_hostname = true
  30. ports {
  31.   https = 8501
  32.   http = -1
  33.   grpc = 8502
  34. }

Kubernetes as the Secondary

If you’re running your primary datacenter on VMs then you’ll need to manually construct the Federation Secret in order to federate Kubernetes clusters as secondaries.

Your VM cluster must be running mesh gateways, and have mesh gateway WAN federation enabled. See WAN Federation via Mesh Gateways.

You’ll need:

  1. The root certificate authority cert placed in consul-agent-ca.pem.
  2. The root certificate authority key placed in consul-agent-ca-key.pem.
  3. The IP addresses of the mesh gateways running in your VM datacenter. These must be routable from the Kubernetes cluster.
  4. If ACLs are enabled you must create an ACL replication token with the following rules:
  1. acl = "write"
  2. operator = "write"
  3. agent_prefix "" {
  4.   policy = "read"
  5. }
  6. node_prefix "" {
  7.   policy = "write"
  8. }
  9. service_prefix "" {
  10.   policy = "read"
  11.   intentions = "read"
  12. }

This token is used for ACL replication and for automatic ACL management in Kubernetes.

If you’re running Consul Enterprise you’ll need the rules:

  1. acl = "write"
  2. operator = "write"
  3. agent_prefix "" {
  4.   policy = "read"
  5. }
  6. node_prefix "" {
  7.   policy = "write"
  8. }
  9. namespace_prefix "" {
  10.   service_prefix "" {
  11.     policy = "read"
  12.     intentions = "read"
  13.   }
  14. }
  1. If gossip encryption is enabled, you’ll need the key.

With that data ready, you can create the Kubernetes federation secret:

  1. kubectl create secret generic consul-federation \
  2.     --from-literal=caCert=$(cat consul-agent-ca.pem) \
  3.     --from-literal=caKey=$(cat consul-agent-ca-key.pem)
  4.     # If ACLs are enabled uncomment.
  5.     # --from-literal=replicationToken="<your acl replication token>" \
  6.     # If using gossip encryption uncomment.
  7.     # --from-literal=gossipEncryptionKey="<your gossip encryption key>"

Then use the following Helm config file:

  1. global:
  2.   name: consul
  3.   datacenter: dc2
  4.   tls:
  5.     enabled: true
  6.     caCert:
  7.       secretName: consul-federation
  8.       secretKey: caCert
  9.     caKey:
  10.       secretName: consul-federation
  11.       secretKey: caKey
  13.   # Delete this acls section if ACLs are disabled.
  14.   acls:
  15.     manageSystemACLs: true
  16.     replicationToken:
  17.       secretName: consul-federation
  18.       secretKey: replicationToken
  20.   federation:
  21.     enabled: true
  23.   # Delete this gossipEncryption section if gossip encryption is disabled.
  24.   gossipEncryption:
  25.     secretName: consul-federation
  26.     secretKey: gossipEncryptionKey
  28. connectInject:
  29.   enabled: true
  30. meshGateway:
  31.   enabled: true
  32. server:
  33.   extraConfig: |
  34.     {
  35.       "primary_datacenter": "<your VM datacenter name>",
  36.       "primary_gateways": ["<ip of your VM mesh gateway>", "<other ip>", ...]
  37.     }

NOTE: You must fill out the server.extraConfig section with the datacenter name of your primary datacenter running on VMs and with the IPs of your mesh gateways running on VMs.

With your config file ready to go, follow our Installation Guide to install Consul on your secondary cluster(s).

Next Steps

Read the Verifying Federation section to verify that federation is working as expected.