This is a bit of a tough question to ask so bear with me a bit. I'll try to be brief if I can.
I'm looking for a modern best practice for managing and deploying the trusted root CA certificate list of Docker containers. I know I can bake the certificates into each container through a Dockerfile. However, that is a new docker image for each container every time we need to make a certificate or CRL change. Ideally in the spirit of "cloud native" (see 12 factor apps) our containers would have no certificates and CRLs baked into them and this would all come from the environment somehow.
To give a bit more context. I'm running these containers in Kubernetes, but they could run in any container platform such as OpenShift, AWS, etc. and ideally my objective here is to come up with a single solution that allows for true container portability.
Some ideas I have toyed with:
1) create another container that has all of the certs and CRLs and volume mount that to each container. - This is a common approach but requires the container to be saved to a new image every time a new cert or CRL has been updated. Not awful, but it doesn't feel very "cloud native".
2) Use the Spring Config Server and build a little Spring Boot sidecar that installs all of the certs at startup. - The external centralized config feels cloud native. - May require heavy modification to the start order of services in the container that may require those certs. - Feels too complicated for a container.
3) Use a proxy where all certs are managed. - Feels like a hack to force all traffic through the proxy. - Possible throughput and contention issues when there is heavy loads to HTTPS resources. - May not be feasible to route everything over straight HTTP.
4) Use environment variables and have a start up script that installs them - Simple and generalized approach for any type of container deployed anywhere. I'm not sure if it's appropriate to do it this way. Those would be a lot of big environment variable values. Can you imagine what a "printenv" will look like?
5) Use Kubernetes Secrets (not sure this can work yet) - It's a kubernetes only solution which is a downer for write once, use anywhere.
I know this is a bit long winded. I apologize for that. I didn't know how to compress it any further. I am looking forward to the discussion on this.