[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Problem creating applications from in-house git



I'm not sure I'm comfortable with auto-elevating the master CA to a system trusted CA for images in general... trusting a CA of unknown provenance for API connections only is a lot less concerning.

On Mon, Aug 24, 2015 at 10:43 AM, Clayton Coleman <ccoleman redhat com> wrote:
We don't have to solve all distros, just hte ones our images come on.  Does the rehash require the certificate to be present?  

https://www.mankier.com/8/update-ca-trust

Doesn't make it clear whether the extracted file is mutated or not.  But seeing that Stef is on that man page, let's ask him :)

Stef, is it possible to create a symlink from the extracted trust directory to an arbitrary folder (that will have a ca.crt bind mounted into it when running as a container)?  OpenShift will automount the cluster CA into /var/run/secrets/kubernetes.io..../ca.crt. We're trying to determine if there is an easy way for the image to be crafted so that when that directory is bind mounted in with the right file, that trusted CA is available to apps.  Since CAs tend to be infrastructure wide, we were looking for an alternative to having to have image authors bake in their trusted CA (although that's not the end of the world).

Any thoughts?

On Aug 24, 2015, at 10:01 AM, Jordan Liggitt <jliggitt redhat com> wrote:

I think the only foolproof way to trust additional root certs is to append them to the system trusted certs bundle file (whose path varies by OS varient)

There's a mix of support for trusting multiple files containing CA bundles... https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos has good steps but requires running additional commands, is targeted at Fedora/CentOS/RHEL, and ends with this:

The caveat is that this only works for things that use OpenSSL and use its default trust store locations. It won’t work for apps that use OpenSSL but directly use the bundle file instead of using OpenSSL’s ‘default trust store’ function, and it won’t work for anything based on GnuTLS (whereas editing the bundle file often will, as we often have those patched to load the bundle file directly).

So sometimes you just have to edit the bundle file – but in some cases you might be able to avoid it.

"Sometimes this will work" doesn't sound like something we'd want to do indiscriminately in all containers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]