Closed hightoxicity closed 6 years ago
Hi @hightoxicity
I believe you can achieve the same result by mounting your certs into /certs/
- the entrypoint script should take care of this.
Is there a reason we need both? I do actually find your PR neater as it keeps the required CA's tied into the config...
I did not see that it was done in the entrypoint... I did it to avoid such tricky operations. It avoid the update-ca-certs before starting, it is more compliant with the only one binary running philosophy of containers, it also permits like you said to have all standing in the config. Maybe we should consider it as a second alternative. It is more usable with k8s without helm even if we could use a mount point from secret or configmap.
thx
@hightoxicity ~Sorry for not merging this soon. Is it possible to re-base this from master as there's a few conflicts now?~
I forked this to test it earlier and it seems good. I actually need this as our setup currently doesn't allow update-ca-certificates
;) I'll merge in my version if that's ok?
Hi guy I just rebased everything, it should be good. Yes I think it is very useful if we are for example in a fully static context, a container image built from scratch for example and the gobinary fully static...
Super - thanks
Thanks to you! It is a pleasure to contribute to this project :-)
Make possible to provide extra trusted root ca (as many you want/need). It can be useful if your distant dex is presenting a certificate signed with an internal rootca, you will not have any alert on tls negociation between dex-k8s-authenticator and dex...
Example: