Hacker News new | ask | show | jobs
by moret1979 3568 days ago
> In general, Elastic Beanstalk works fine and has a very gentle learning curve; it didn’t take long for all teams to start using it for their projects.

This is one of the most pressing issues I tend to evaluate on infrastructures. I'm curious to see a few months down the line your opinion on how the dev teams embraced Kubernetes' setups independently or if they kept depending on a dev-ops team to do so.
1 comments
danielmartins 3568 days ago
I believe the reason why people tend to restrict the cluster access to just a handful of people is because - at least for now - these tools lack proper ways to control access to specific resources by specific groups of people. I mean, there are ways to do that in Kubernetes today[1], but the setup is kept as an exercise to cluster operators.

I don't know for sure, but this is less of a problem in some distributions, such as OpenShift[2].

Once this problem is solved, there's no reason to "shield" the cluster from devs.

[1] http://kubernetes.io/docs/admin/authorization/

[2] https://docs.openshift.com/enterprise/3.0/admin_guide/config...

link
erchiang 3568 days ago
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

link
0xCMP 3568 days ago
I like dex a lot. Very cool project. Was gonna use it + k8s for a side project until I realized for the scale I had (1 user) Auth0 + Heroku is still just fine, but dex lets you run Auth0 on your own and completely in your control which is awesome. No more setting up authentication!
link
smarterclayton 3568 days ago
To add to Eric's point - the goal over the long term is to flesh this stuff out and have both flexibility and multi-tenancy in Kube. OpenShift could be opinionated about security (no compromise) while for Kube we wanted to make sure we built first a system that was flexible enough to be used in many ways.

I think that was the correct choice, because most Kube deployments are still single ops team focused, and it was possible for CoreOS to build and integrate Dex without having to face a high bar.

It'll get more opinionated eventually :)

link