vault.hcl should be in a Secret and not a ConfigMap

[linkdd]

I am using Vault with a PostgreSQL storage backend. The connection URL is passed to the VaultServer resource as a secret (and it should be because it contains credentials).

But the configuration (vault.hcl file) is then generated as a ConfigMap when it should also be a Secret (which can also be mounted as volume inside pods).

[cabrinha]

https://kubevault.com/docs/v0.3.0/concepts/vault-server-crds/vaultserver/#specconfigsource

This shows that the configSource can also be a secret.

spec:
  configSource:
    secret: # for example `configMap` or `secret`
      name: vault-config

[CosmoMyzrailGorynych]

@cabrinha Don't read issues diagonally.

The configMap is generated by vault-operator in an open form, as a config map with a vault.hcl field. This is not the configMap the user provides; the user is using secrets already.

In a more visual form,

By creating a VaultServer that uses a secret,

vault-operator creates a config map that puts all the connection data in the open:

It also disrespects my other configs, btw.

[mhamann]

This is a huge security issue. Yes, in a well-run deployment of kubernetes etcd is encrypted, but from an RBAC perspective, secret access is much more tightly controlled than configmap access. This has caused me to question the entire trustworthiness of this project. I would never consider deploying this into production in the current state.

Honestly, it seems like a huge misfire to have allowed this through any sort of code review.