Fork projects for first class Kubernetes support

[JanMa]

Vault has first class Kubernetes support by offering a HELM chart, CSI driver and Agent injector. If OpenBao should also make Vault on Kubernetes a first class citizen, then we need to fork the relevant upstream projects. Otherwise we should remove the relevant Kubernetes docs from the OpenBao documentation.

[djds]

Also, https://github.com/hashicorp/vault-secrets-operator is pretty cool but switched to BSL with hashicorp/vault-secrets-operator@cc1b024

[yuval9313]

I rely on vault secrets operator and would like to see an open source version of it as well, I wish that first-clas k8s support would be maintained

Thank you for all the job you have made this far :)

[jessebot]

Also, https://github.com/hashicorp/vault-secrets-operator is pretty cool but switched to BSL with hashicorp/vault-secrets-operator@cc1b024

I think this means that the fork could start from here though right? (the commit before the license change):
https://github.com/hashicorp/vault-secrets-operator/tree/06bc1738beb805455cc875f1b41e96ec35ecb514

If I'm not wrong, this is the helm chart: https://github.com/hashicorp/vault-helm
The helm chart has a "Mozilla Public License 2.0" license. Can that be forked safely?

[JanMa]

Hey @jessebot you're right regarding both points. The fork can start at the last commit that is still MPL licensed, and those projects are in general save to fork.

[jessebot]

@JanMa awesome, thanks for the quick response! If those repos are forked under the openbao org, I would be happy to pinged for help on the k8s side of things. I maintain a lot of helm charts, so if there's something specific to those, I can help :)

[JanMa]

That's great, thanks a lot @jessebot. I'll let you know once we have those repos available in our org

[AdrianAbraham]

Please also include support for https://github.com/hashicorp/vault-k8s . Our projects rely on the older "Agent Injector" instead of the newer "Vault Secrets Operator" or "Vault CSI Provider."

[JanMa]

@jessebot @AdrianAbraham we have now forked the relevant repos into our org:

• https://github.com/openbao/openbao-secrets-operator
• https://github.com/openbao/openbao-helm
• https://github.com/openbao/openbao-k8s

[zjs]

Vault CSI Provider

Are there plans to fork this as well? Seems like it switched to BSL here: hashicorp/vault-csi-provider@9910eb3

[jessebot]

Vault CSI Provider

Are there plans to fork this as well? Seems like it switched to BSL here: hashicorp/vault-csi-provider@9910eb3

I'm also interested in this as it's one of the official hashicorp images that is currently set as a default for images in the forked helm chart. See openbao/openbao-helm#3 for more info.

[JanMa]

@jessebot @zjs is a fork of the CSI driver really necessary in your opinion? If possible if would like us to only support one way to sync secrets from Vault/OpenBao to K8S long term and I think the Vault/Openbao Secrets Operator is the much more "Kubernetes native" way to do that because in the end it just creates Kubernetes Secrets.

[jessebot]

@JanMa I think we should still support it as it may be a security requirement for some, unless I'm misunderstanding the CSI driver architecture, as some may not want to use k8s secrets due to the data just being base64 encoded rather than encrypted (though k3s offers encryption at rest now, and that's kinda cool). I know a user can also use RBAC to restrict others from creating/viewing secrets too though, so maybe for right now we could avoid forking the csi driver? Snyk is pretty famous in the security space and they use secrets 🤔 We would need to remove the injector stuff from the helm chart though too, and that feels like we're losing that feature.

I do have a question on the secrets operator though, as I haven't used that one. I've only ever used the external-secrets operator. What's the difference?

I'm interested in others' opinions on both points as well since for right now I mostly use secrets with all the caveats I mentioned before via ESO 🤷

[JanMa]

I do have a question on the secrets operator though, as I haven't used that one. I've only ever used the external-secrets operator. What's the difference?

I think conceptually they are very similar. From what I understand, the main difference is that ESO only supports the KV secret engine whereas the Vault/OpenBao Operator supports all secret engines out of the box.

[jessebot]

@zjs, update: openbao/openbao-csi-provider is now available, however it won't be ready until at least the following are resolved:

• Issue 1: update as many references as possible from vault to openbao openbao-csi-provider#2
• Need a docker release workflow openbao-csi-provider#3
• issue 3: get docker release up and running openbao-csi-provider#4

Also, this Issue can probably be closed as all the correct repos are now forked, yes?