search

redhat-cop / vault-config-operator

An operator to support Haschicorp Vault configuration workflows from within Kubernetes
Apache License 2.0
108 stars 49 forks source link

[RFE] Support for additional authentication #43

Open aelbarkani opened 2 years ago

aelbarkani commented 2 years ago

Thanks for this awesome operator!

I would like to suggest adding extra authentication methods in addition to Kubernetes one. Maybe using a Vault token can be enough in a first step (like here in cert-manager: https://cert-manager.io/docs/configuration/vault/#authenticating-with-a-token)

raffaelespazzoli commented 2 years ago

If I get it correctly, you mean additional methods to authenticate to Vault, not additional auth engines. What would the use case be? the kubernetes method is designed to use the pod identity to authenticate to Vault.

aelbarkani commented 2 years ago

Yes exactly. We use SPIFFE to authenticate to Vault, either through OIDC/JWT or through TLS client certificates by using an identity federator which gives identities to Kubernetes workloads (something similar to what is done here: https://cloud.redhat.com/blog/fine-grained-iam-roles-for-openshift-applications). The reason for that is the difficulty to manage Vault's Kubernetes authentication at scale : if you have dozens of Kubernetes clusters to manage and also dozens of Vault instances, it means that every time you add cluster you need to change Vault configuration in order to add the additional cluster. That can be OK if the team who manages the Vault instances is the same as the one who manages the Kubernetes clusters. But if they are different it can be a mess. And it's even a bigger mess if you have several teams managing several fleets of Kubernetes clusters and several fleets of Vault instances. So having an identity federator enables us to configure only one identity provider for every Vault instance, no matter how many Kubernetes clusters we have. And that identity federator can only provide OIDC/JWT tokens or TLS client certificates according to SPIFFE standard. In addition, it seems to me that using Kubernetes service account tokens has some weaknesses (lack of scoping, lack of TTL) as described here: https://tanzu.vmware.com/developer/guides/platform-security-workload-identity/.

aelbarkani commented 2 years ago

P.S: the reason why I proposed Vault token authentication instead of OIDC/JWT or TLS is that Vault token is more universal/flexible and leaves the choice of getting Vault token to the user by using any authentication method he wants.

raffaelespazzoli commented 2 years ago

LDAP authentication has been added.