Are Vault Reference Architecture documents ambiguous

Vault
1

…or am I missing something?

Hi Guys

I am currently trying to follow the recommendations in the vault reference architecture. Specifically the creation of separate consul clusters for storage and service discovery.

I have successfully created a storage cluster and connected it to a vault cluster as shown in the hcl files below. However I am struggling to understand how the service discovery cluster gains knowledge of the vault cluster as they are gossiping on different ports.

The docs state the service registration stanza in the vault configuration is used when

“The service_registration stanza is designed for use cases where you would like to use a system like Consul for service discovery, but use a different system for the storage backend.”

I am assuming that by running the storage cluster on serf_lan 7300/7301 that this makes it a separate cluster from the one I have created for storage which runs on the default serf_lan ports. Does this qualify the consul storage cluster as " a different system for the storage backend"

I have tried using the following stanza to register the vault cluster with the service discovery consul cluster - but this has not worked (note all the servers in my environment are on same subnet and can ping each other)

service_registration "consul" {
  address = "<ip_of _one_of_the_service_discovery_servers>:8500"
}

Even if it did work it would not be ideal as it involves a hard-coded ip address.

If I were to try and solve this by using the same consul cluster for vault storage and service discovery (which I got to work BTW) then this flies in the face of the advice in the reference architecture regarding separating storage and discovery.

You can see my confusion

Any pointers you have to assist would be great.

Many thanks in advance
regards
Ian Carson

vault.hcl ->

storage "consul" {
  address = "127.0.0.1:7500"
  path    = "vault/"
}

ui = true
disable_mlock = true

acl {
  enabled = true
  default_policy = "allow"
  enable_token_persistence = true
}

listener "tcp" {
  address          = "0.0.0.0:8100"
  cluster_address = "0.0.0.0:8101"
  tls_disable      = "true"
}

seal "transit" {
  address = "http://xxx.xxx.xxx.xxx:8200"
  token = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  disable_renewal = "false"
  key_name = "autounseal"
  mount_path = "transit/"
  tls_skip_verify = "true"
}

with

consul-client.hcl ->

datacenter = "warrimoo-vault"
data_dir = "/opt/consul/data"
advertise_addr = "{{ GetInterfaceIP \"eth1\" }}"
bind_addr = "{{  GetInterfaceIP \"eth1\" }}"
retry_join = ["x.x.x.x", "x.x.x.x", "x.x.x.x"]
log_level = "DEBUG"
enable_syslog = true
encrypt = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

ports {
    http = 7500
    server = 7300
    serf_lan = 7301
}

and

consul-server.hcl ->

datacenter = "warrimoo-vault"
data_dir = "/opt/consul/data"
advertise_addr = "{{ GetInterfaceIP \"eth1\" }}"
bind_addr = "{{ GetInterfaceIP \"eth1\" }}"
client_addr = "0.0.0.0"
retry_join = ["{{ GetInterfaceIP \"eth1\" }}"]
log_level = "DEBUG"
enable_syslog = true
encrypt = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

ports {
    http = 7500
    server = 7300
    serf_lan = 7301
}

server = true
ui = true
bootstrap_expect = 3
2

How to successfully use a separate consul storage cluster while still automatically registering with the service discovery cluster remains a mystery. Unfortunately the (otherwise excellent) documentation around this topic is opaque when it comes to a workable implementation.

For the sake of expedience I instigated the use of the integrated raft storage and had a working, service discoverable, Consul/Vault/Nomad platform up and running in a morning.

Hope this pointer is of use to someone.
Regards
Ian Carson