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

Re: Problem creating applications from in-house git



You mean API connections to the thing running your production
infrastructure?  If you can't trust your master CA you can't trust
anything the master runs.

Isn't the master CA part of a chain anyway?   The chain was mostly
what I was interested in, because I assume that the CA chain you set
on the master leads back to your corporate CA.  What sorts of use
cases would you have to have multiple root CA's in your organization?

On Tue, Aug 25, 2015 at 10:04 AM, Jordan Liggitt <jliggitt redhat com> wrote:
> 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
>>
>>
>



-- 
Clayton Coleman | Lead Engineer, OpenShift


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