On using an existing etcd cluster

[Quentin-M]

Hi guys,

First of all, thank you so much for open sourcing the Vault operator. This is a great milestone for the community and the overall security story of Kubernetes!

It seems that the Vault operator leverages the automation provided by the etcd operator for the Vault’s datastore, which seems like a great integration point for most people!

However, for those who deploy Vault as a base Kubernetes service, it seems that it would be beneficial to use the already existing and managed etcd cluster that supports the Kubernetes API, as it is often closely monitored (etcd metrics, node metrics, ...), has alerts set up as well, backups, disaster recovery plan, etc.

Is supporting existing secured etcd cluster something that you may consider adding to the operator in the short term?

Thanks again.

[hasbro17]

@Quentin-M That’s an interesting idea. While I’m not sure of the feasibility and side effects of sharing the API server's etcd store, the general idea of using an existing etcd cluster is definitely useful.

Roughly speaking if the etcd endpoints and the trusted client cert/key are passed in the VaultService CR spec then the operator should be able to reuse the existing etcd cluster for the Vault cluster's storage.

I can't guarantee how soon we can move on this due to other commitments but I’m going to experiment a bit more with this idea in the coming week or so and will try to update with a more detailed proposal.

[philips]

I thought we already had a doc on how to do this but I can't find it.

Regardless I think we could easily add a mode that points to an existing etcd cluster instead of deploying one. Perhaps this is a different resource type vs an option on the existing type.

[hasbro17]

@philips The vault-operator does not support using an existing etcd cluster. You might be thinking of the etcd-backup operator which supported creating backups from an existing etcd cluster. https://github.com/coreos/etcd-operator/blob/master/example/etcd-backup-operator/backup_cr.yaml#L6

And I think that this could be supported as an option in the existing VaultService CR rather than having a new resource type since it's just an extension to override the default. Something like:

apiVersion: "vault.security.coreos.com/v1alpha1"
kind: "VaultService"
metadata:
  name: "example"
spec:
  storage:
    etcd:
      endpoints: <comma separated list of endpoints>
      tlsClientSecret: <secret containing: etcd-client.key etcd-client.crt etcd-client-ca.crt>
  nodes: 2
  version: "0.9.1-0"

So if the user specifies spec.storage.etcd then the operator uses that. Otherwise it creates a new etcd cluster using the etcd operator.

[adarshaj]

I like the sample syntax yaml proposed by @hasbro17. Is there a way to do this now? I cannot find any documentation..

[raoofm]

@hasbro17 any update on this?

[kedare]

I think it would also be interesting to be able to choose another storage that ETCD (I would rather use something else), basically to allow any storage configuration.