Use HashiCorp Vault for OSH deployment

[pratik705]

This commit will replace Kubernetes secrete creation step and consume the secrets from HashiCorp Vault using vault-secretes-operator for the OSH deployment.

[cloudnull]

LGTM @pratik705 will you convert the rest of the services within this PR?

[sulochan]

One issue with mariadb secret and a few nitpicks.

Overall I think if we are changing this then we need to change this for all secrets generated on the command line. Just have 2 into vault and not having others is more confusing?

[sulochan]

This link will take us to github .md page ... we can link back to mkdocs /vault/ page ?

[sulochan]

same as above.

[sulochan]

there is one extra \ here ?

[sulochan]

Changing this key will break all the service deploy? Example: glance, neutron, etc will do something like:

--set endpoints.oslo_db.auth.admin.password="$(kubectl --namespace openstack get secret mariadb -o jsonpath='{.data.root-password}' | base64 -d)" \

which will look for mariadb secret with root-password. Will this work ?

[pratik705]

as per my understanding, if we update the password in the vault then its required to update helm charts to populate the correct password in the openstack services. I haven't validated it though.

[cloudnull]

For infra services I don't think we can change the password references; most of them are not goverened by helm.

[pratik705]

I am facing some issue with my lab. I will work on other osp services once the lab is up

[pratik705]

@cloudnull @sulochan All the OSH services[1] have been updated with Vault integration. Please let me know if anything is pending.

[1]
mariadb-cluster
postgresql
Keystone
Glance
Placement
Nova
Cinder
Heat
Horizon
Ironic
Designate
Skyline
Octavia
Gnochi
Ceilometer

[pratik705]

In the lab I created local users in the vault for testing. We can either go with local users or use ldap to integrate with vault. I have added an example to create local user with policy providing access to the secret path.

[aedan]

I am confused as to why we are doing this at all. I understand that we need vault for barbican, but why are we adding it into the infrastructure? Kubernetes already encrypts the secrets. So there is no need to vault in the infrastructure. All it really does in add a moving part and increase the chances of failure. While also making it harder for support to troubleshoot and fix. If you want to make kubernetes more secure. All you need to do is remove the /etc/kubernetes/admin.conf file and the ~/.kube/config file. Place it in password safe and if you want to access kubernetes. You will have to check it out.

my 2 cents.

[cloudnull]

@pratik705 @sulochan - given the state of the Hashicorp licensing drama that is currently unfolding, I think we should revisit this change with OpenBao; a fork of the last open-source licensed release of vault.

[pratik705]

I have created a script to generate and push the secrets required by OpenStack services to Vault, which will eliminate the manual steps needed to interact with Vault to create the required secrets. However, due to licensing issues with Vault, I am holding the work until we get some clarity on OpenBao, as it appears its in the development stage.