Inicio Explorar Axuda
Iniciar sesión
fszontagh
/
smartbotic
1
0
Fork 0
Ficheiros Incidencias 1 Pull Requests 0 Wiki
Árbore: 88e787784b
Ramas Etiquetas
smartbotic
/
deploy
/
zeus
/
ca
fszontagh 649757a3c7 fix: give the containers the trust the host used to provide implicitly hai 3 semanas
..
README.md 649757a3c7 fix: give the containers the trust the host used to provide implicitly hai 3 semanas
build-bundle.sh 649757a3c7 fix: give the containers the trust the host used to provide implicitly hai 3 semanas
mulan-sdcpp.crt 649757a3c7 fix: give the containers the trust the host used to provide implicitly hai 3 semanas

README.md

Extra CA certificates for the containers

Certificates this deployment must trust that a public CA does not vouch for. Currently just mulan's SD.cpp service, which is self-signed.

build-bundle.sh concatenates the runtime image's own CA bundle with everything here and writes bundle.crt, which compose mounts and points SSL_CERT_FILE at. Run it again after changing this directory or rebuilding the image on a newer Debian.

Why not the app's own trusted-certificate store?

That exists and works, but it is opt-in per workflow (workflow.settings.certificateIds) - which is right for a certificate that belongs to one integration. Reaching mulan's SD.cpp is infrastructure for this whole deployment, so it belongs here rather than repeated in every workflow that happens to touch it. Before the move to containers this was zeus's own system store doing the same job.

Why not bake it into the image?

The image should not carry one host's certificate - it would have to be rebuilt to add or rotate one, and the same image should run in a deployment that has never heard of mulan.