Dockerized IdP

[John Gasper]

>
>Message: 3
>Date: Wed, 9 Mar 2016 13:27:47 +0100
>From: Etienne Dysli-Metref <etienne.dysli-metref at switch.ch>
>To: Shib Users <users at shibboleth.net>
>Subject: Re: Dockerized IdP
>Message-ID: <56E016C3.3050701 at switch.ch>
>Content-Type: text/plain; charset="utf-8"
>
>On 08/03/16 21:59, Greg Haverkamp wrote:
>> The nice thing about that is that we can quickly crank up a new
>> container with a fully working image, and the only thing we have to
>> provide is metadata.  The downside is the import step.  We'll probably
>> eliminate it as a requirement, and instead map the external volume from
>> the repository we already keep on the host.  That way, we can still
>> deploy anywhere without getting a repository cloned, but we can also, if
>> we so desire, keep changes in the local git repository for the primary
>> systems.
>
>How do you handle secret configuration elements? (private key files,
>passwords for LDAP and database access, etc.) If your image contains
>such elements then it becomes just as sensitive as those and is hard to
>distribute (enough to get it where it needs to be run without exposing
>it)...
One can either overlay them in the image or mount them from the external
host. It's also trivial to retrieve them at startup, but one would need to
enhance the container start script. Docker does not negate the need to
secure one secrets and hosting environment.
>
>> If you can quickly spin up VMs, perhaps not much.  However, if you have
>> a set of oversized hosts hosting containers, it permits you to do things
>> like running identical servlet containers in parallel with varying
>> Shibboleth configurations.  We use it as a staging process.  Make our
>> changes, crank up the "staging" container.  Then, using the load
>> balancer-based selection process I've written about before, select the
>> staging container, and we can even let user readily test to see if the
>> changes we've made fix whatever issue they might have been having.
>
>Our "get a new VM" process has at least one manual step so it's not
>instantaneous, but once Puppet takes over we can quickly deploy changes.
>I agree that having less VMs to maintain is a benefit though.
>
>Your load balancers do terminate the TLS connections I guess, since they
>look at cookies for routing. This removes the keys needed for HTTPS from
>Docker images.
The image requires a TLS key to start, so that TLS is maintained end to
end. So the adopted decides whether the associated cert used by the
container is self-signed and a load balancer terminates user-agent TLS or
the cert is signed by a trusted CA. But over all, I'd argue that in the
SAML world the response signing key is just as important as the TLS key,
so if one does provide the same protection to the signing key as the TLS
key they've lost... So externalizing the TLS key only does not provide any
real security to the system as a whole.
>
>  Etienne
>
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: signature.asc
>Type: application/pgp-signature
>Size: 836 bytes
>Desc: OpenPGP digital signature
>URL: 
><http://shibboleth.net/pipermail/users/attachments/20160309/fb4068f4/attac
>hment-0001.sig>
>
>------------------------------