Closed guillaumevillemont closed 4 months ago
Thanks for the report @guillaumevillemont you are right we should publish the library chart, it was our initial idea but the task went through the cracks.
If I understand it correctly you want the chart deployment to be deterministic without setting the jwtServerPrivate and jwtServerPublic values?
you want the chart deployment to be deterministic without setting the jwtServerPrivate and jwtServerPublic values?
That would be ideal and should be the long-term goal here, but I doubt it's easy and quickly fixed.
On the short-term, since I can set jwtServerPrivate|Public this part is not an issue (once I've set them explicitly, the rendered template is determined)
But I can not set the tls.crt
, tls.key
, server.crt
, server-key.pem
, ca.crt
,ca.pem
. That's my issue mainly. So at least, exposing those variables from the library to this chart should solve the problem (the same way as jwtServerPrivate|Public)
And I think long-term and short-term fixes are not exclusive, so we can do both :)
Alright so I pushed a fix into https://github.com/passbolt/charts-passbolt/tree/feature/GH_32 here is the diff https://github.com/passbolt/charts-passbolt/compare/main...feature/GH_32
Introducing new values: app.ssl.key, app.ssl.cert and app.ssl.k8sCerts (k8sCerts is not a great choice but I didn't come up with anything better as of now).
These will be injected in /etc/ssl/certificate.key and /etc/ssl/certificate.crt which are used by passbolt nginx config. (which was not the case before so we are fixing a bug at the same time)
As I'm not using argocd would you mind testing in your environment to ensure the fix works for you or if you have any other feedback let us know.
Instead of app.ssl...
values, I suggest referencing a Secret by secretName (a secret of type kubernetes.io/tls
).
then people can generate their own Secret or use a tool like cert-manager.
kubernetes.io/tls
has 3 fields :
tls.key
/ tls.crt
: the private key and certificateca.crt
: the cert of the CA that signed the certsYeah, that sounds good! I guess we can keep the values and add another values option to reference an already-created secret.
an example in bitnami/kibana chart: https://github.com/bitnami/charts/tree/85f0b50e32d81f4720af678ff096ff3d1907472a/bitnami/kibana#kibana-server-tls-configuration :)
Hi, ability to load external secrets for ingresss and passbolt volume mounts has been added (see tls.existingSecret). This should make the chart deterministic along with the JWT workaround.
I will keep this issue open till we solve the JWT one completely that is also related with #33
What's happening
I'm deploying this chart through ArgoCD with sync and self-healing enabled.
Once deployed, Argo keeps complaining about out-of-sync changes and wants to recreate
passbolt-sec-tls
andpassbolt-sec-jwt
.The later is due to https://github.com/passbolt/charts-passbolt/blob/1106086de7ebfc1e04ff735df06a21abfae7f848/templates/secret-jwt.yaml#L21 which is non-deterministic, so Argo can't match what's deployed and what's templated before sync. It can be worked around by setting the existing values
jwtServerPrivate
andjwtServerPublic
. Though it could be good to force the user to set those explicitly to avoid this hiccups.The former is due to the function helper "gen-certs" from passbolt-library (which I didn't find the code on github, but I found that snippet in my helm dependency folder) :