erchiang

More intended as a fun intro to the basics than an opinion about container runtimes. I think understanding the common, underlying things provided by the kernel helps me work and evaluate higher level tools. E.g. when considering Docker vs LXC.

Like how a compiler class might have you write your own toy compiler for the sake of demonstration, I don't think anyone is advocating rolling your own runtime.

I'd love to see more articles about things like LXC. We where looking into using it at my last job but didn't have the bandwidth to do the proper exploration.

Disclaimer - I work at CoreOS and on the Kubernetes auth sub systems

Today, most of the auth-N plugins[0] (the upstream equivalent to the OpenShift doc you linked to) are relatively minimal. Most of these are aimed at providing pluggability for other apps that focus on ease of use. Google uses the webhook implementation for its GKE auth-N and we (CoreOS) continue to try to make our OpenID Connect server federate to more backends (LDAP, GitHub, etc.).[1]

With these kind of tooling, it's completely possible to map auth-Z policies to, say a group of LDAP users. But yes, there's a lack of canonical documentation on how to go about this. We're always trying to negotiate how much of this should live in core Kubernetes and how much should be provided by third party services (and what the upstream docs should endorse).

But today I'd still (perhaps because I'm biased) recommend giving your CEO different credentials for your prod cluster :)

[0] http://kubernetes.io/docs/admin/authentication/ [1] https://github.com/coreos/dex