Helper function for TLS support in database access #357
Conversation
modules/common/tls/tls.go
Outdated
| "ssl-key=/etc/pki/tls/private/tls.key") | ||
| } | ||
| // Client uses a CA certificate that will get merged | ||
| // into the pod's CA bundle by the pod's init container |
There was a problem hiding this comment.
not by the init container, but via kolla_start openstack-k8s-operators/tcib#82
There was a problem hiding this comment.
It's copied during kolla_start, but the idea was that this file was merged with 'update-ca-trust' during the init container.
There was a problem hiding this comment.
but we don't have to do this in the init container as you can see in the tcib change. the deployment get the cacert mounted and kolla does it already.
There was a problem hiding this comment.
I think the plan is to get rid of any init container where possible. for client cert we then should mount the cert and use the kolla config to copy it to the right place. the CA update is handled when we get new images from the above PR. if you need test images, I have built some at quay.io/mschuppe/...
There was a problem hiding this comment.
oh I didn't know that, thanks
| // a common directory for all services | ||
| if t.Service.SecretName != "" { | ||
| conn = append(conn, | ||
| "ssl-cert=/etc/pki/tls/certs/tls.crt", |
There was a problem hiding this comment.
is this for when client certs are used?
There was a problem hiding this comment.
correct, it might be useful in the future if we enable client cert-verification in mariadb.
The idea is that this name is generic, and the real certificate for the service is copied by kolla_start into this generic location.
https://github.com/openstack-k8s-operators/keystone-operator/blob/1e32653ddc594eda8428fc0335608b7befbb1a14/templates/keystoneapi/config/keystone-api-config.json#L35
There was a problem hiding this comment.
We might want to use a similar copy mechanism in kolla_start, and agree on a cert name to use here, rather than updating all service's kolla config to copy them manually?
There was a problem hiding this comment.
yes, we could do that and have pre-defined names for client/server cert
New function to generate the mysql flags read by oslo.db to connect to a mysql database via TLS.
New function to generate the mysql flags read by oslo.db to connect to a mysql database via TLS.
This commit also returns a fqdn for the database hostname, as it is required to validate the mysql database's certificate.