Closed zugao closed 2 years ago
I'd go with idea 2 for a first iteration. Using Vault to generate certificates is probably an epic on its own.
There are much easier ways for Openshift: https://docs.openshift.com/container-platform/4.10/security/certificates/service-serving-certificate.html (also supports patching Webhook configs) And since our first target platform is Openshift anyway, that's good enough for now.
My vote is for going that route with service certificates, no need to script something in an ArgoCD job when not yet needed.
All we'd need to do is setting some annotations in the Helm values (see https://github.com/vshn/appcat-service-postgresql/pull/81 and https://github.com/vshn/appcat-service-postgresql/pull/85)
I agree, but let's keep this open for when we want to support plain k8s.
To support plain K8s in the future, we may consider https://github.com/projectsyn/k8s-service-ca-controller which is hopefully released by then.
As discussed internally, we'll only support OCP4 for now using the certificate provisioning feature as mentioned, so this story is superseded with https://github.com/projectsyn/component-appcat-service-postgresql/issues/13.
Closing this issue for now, might become relevant in the future again, or maybe not.
The latest version of appcat-postgresql uses validation webhooks which require certificates to work. Currently the chart is being installed with predefined certificates (step 4). This step has to be managed by the component.
Implementation ideas: 1) Component crafts a secret which references certificates from Vault. ArgoCD will populate that sensitive information from Vault to valid secret data during deployment. This new secret
webhook.existingSecret
needs to be available in the Helm Chart. 2) Add a pre-installation job for Argo to create the secret with self-signed certificates. We will still needwebhook.existingSecret
for that matter.Acceptance Criteria
Notes
we need: