Setting up consul secret engine?

[hashicorp]

Setting up consul secret engine?

[Skaronator]

Maybe creating a loopback interface before vault starts which will map the Node IP to 127.0.0.2 or something like that could work as well?

[jasonodonnell]

Hi @Skaronator!

I think Consul's service should be reachable from the Vault pods:

[~] kubectl get services | grep consul
consul-consul-dns      ClusterIP   10.102.183.216   <none>        53/TCP,53/UDP                                                             7m30s
consul-consul-server   ClusterIP   None             <none>        8500/TCP,8301/TCP,8301/UDP,8302/TCP,8302/UDP,8300/TCP,8600/TCP,8600/UDP   7m30s
consul-consul-ui       ClusterIP   10.100.48.130    <none>        80/TCP

[~] kubectl exec -ti vault-0 -- ping consul-consul-server
PING consul-consul-server (10.32.0.6): 56 data bytes
64 bytes from 10.32.0.6: seq=0 ttl=64 time=0.064 ms
64 bytes from 10.32.0.6: seq=1 ttl=64 time=0.061 ms
64 bytes from 10.32.0.6: seq=2 ttl=64 time=0.061 ms

Thoughts?

[jasonodonnell]

After speaking with Consul folks, it might be better to create a service that load balances the agent nodes for this particular use case:

---
apiVersion: v1
kind: Service
metadata:
  name: consul-agent-service
spec:
  selector:
    app: consul # This might be different for you
    component: client
  ports:
    - protocol: TCP
      port: 8500
      targetPort: 8500

Then configure Vault to use it:

vault write consul/config/access \
    address=consul-agent-service:8500 \
    token=xxxx-xxxx-xxxx-xxxx-xxxx

[Skaronator]

Shouldn't Vault talk to the consul agents instead of talking with the server directly?

[Skaronator]

Just saw the other email... Wouldn't it be better for Vault to talk with the agent on the same node? Instead of load balancing to a different instance?

[jasonodonnell]

@Skaronator Agreed that is ideal and what we would like, however, it would require some sort of loop back like you are suggesting. Without a loop back something like node IP could be used but that has limitations: node ip is persisted in Vault config and if the node goes down it's no longer accessible. By using an agent service, we can ensure an agent always responds.

Going to think more on this but these are my initial thoughts.

[Skaronator]

Thanks for your input, I think this is enough for now.

[chancez]

I managed to get vault to connect to consul as deployed via the consul-helm chart by adding a service accessing the consul client agent, but then there's TLS issues.

/ $ vault write consul/config/access address=consul-client.consul:8501 scheme=https token=$VAULT_CONSUL_TOKEN
Success! Data written to: consul/config/access
/ $ vault read consul/creds/my-role
Error reading consul/creds/my-role: Error making API request.

URL: GET http://127.0.0.1:8200/v1/consul/creds/my-role
Code: 400. Errors:

* Put https://consul-client.consul:8501/v1/acl/token: x509: certificate is valid for localhost, not consul-client.consul

[chancez]

Well, setting global.tls.httpsOnly let me access it over 8500 at least. I can work on how to share the client CA to vault, but overall I'd love a prescribed/automated way to do all this.