Dockerized IdP

[Etienne Dysli-Metref]

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)...

> 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.

  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/attachment.sig>