Cloud Native Computing Foundation Cloud Native Security Conference North America 2021, 30 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Pinniped: A Unified Framework for User Authentication to Kubernetes Cluster- Mo Khan & Anjali Telang

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Pinniped: A Unified Framework for User Authentication to Kubernetes Clusters- Mo Khan & Anjali Telang, VMware

If you are a Kubernetes Administrator, IT Administrator or Community User, who manages user access to multiple Kubernetes clusters, you not only understand the pain of configuring user authentication to multiple clusters, but also the pain of managing and supporting multiple Identity Providers (IDPs). For user authentication, there are various cluster providers that offer vertically integrated solutions but there is still a need for a generic solution that can work across kubernetes clusters. Further, many IDPs offer Web-based administration interfaces that are not command-line/kubectl friendly. In this talk, we introduce Pinniped, a One-size-fits-all, completely Open Source User-Authentication solution to all Kubernetes clusters! Our architecture is designed to not only support Day0 Ops for configuring clusters during deployments but also Day2 Ops for managing user access after clusters are deployed. During our session we will elaborate on the various configurations supported by Pinniped,such as multiple Identity Providers, multiple kubernetes platform providers and different deployment configurations (Edge, Core).

A

Hey everyone today I'll be talking to you about pinup head the unified framework for user authentication to kubernetes clusters.

A

So today I'm joined by anjali the pm for the project myself, uh one of the engineers on the pinniped team.

A

So let's imagine that you use kubernetes and you've started to get used to using cube's retail and I'm really enjoying it, and it's now time to start deploying it for real in your environment, where you happen to use active directory to provide identities. For your end users, it seems like a fairly common thing to want to do um so. Let's think about how much you might imagine doing that, we might start off with a google search, and it appears that the first result for the most obvious google search is somebody's blog post.

A

So, let's see where that takes us now, if you've used q, ttl and kubernetes for a while you'd imagine, it would be a series of qc telephi commands.

A

Instead, what you encounter is a very complex set of configuration using two components: dex and gangway.

A

That is unexpected. There's a lot of ammo a lot of construction and it's not really clear what you're getting yourself into here.

A

So maybe, let's back up, maybe that was a bad search result, let's back up and see what the second thing is, that appears to be some official programs documentation. Maybe that can help us find a way to use active directory for kubernetes.

A

And so we looked through the official authentication documents for kubernetes and they refer to client certificates, tokens and proxies nothing specific about using active directory.

A

And so here we start learning some of the problems. Kubernetes is very pluggable.

A

It does not have direct integration with active directory, you're kind of on your own on that. So this is beneficial if you want to build custom integrations, but not so fun. If you just want to get some work done, so maybe let's head back to the blog post and see what it entails.

A

So we have to deploy two components: dex and gangway and concert. We have to configure various cli flags on the api server.

A

um We have to learn some oauth semantics have some very specific, coordinated state between these components and the reality is these components were not built together, they're, open source projects important in their own right and certainly there's not necessarily anything wrong with this setup. It's just not curated and it can be difficult to understand. What's happening is really really per single cluster and it doesn't really scale out.

A

You know you can imagine a ton of extra work to add these components to every single cluster you use and that doesn't necessarily lead to the most convenient or secure deployment.

A

So pinpat attempts to solve these types of problems by providing a much more kubernetes native approach to authentication via comic providers such as oibc and ad, and allows you to configure these at runtime.

A

It is an open source project that you can use on any kubernetes distribution.

B

So you want to start installing piniped. The first steps are really easy. You just keep ctl apply the manifest and install the two core components which are the pinniped supervisor and the pinniped concierge.

B

The pinniped supervisor is just a web server, so it will require you to configure the ingress and tls for it. Here's an example of how we've done it in on a gke cluster, with sort manager and, let's encrypt. So we start off by creating load balancer as a service for the supervisor.

B

Next, we configure google cloud dns to point to the service.

B

We install cert manager and then we request certificates from cert manager for the particular host name that you intend to use.

B

So if we finally come to the configuration steps that are more pinniped specific, so all previous steps that you saw were just configuring, the web server and you've probably done that for other applications that you may be using.

B

So the first core step is to create federation domain and configure it with the issuer url that you created in the previous steps, so federation domain, what this means or what this entails is in this case the issuer, for example supervisor.mycompany.com.

B

This represents the set of kubernetes clusters that are going to trust this particular pinniped supervisor.

B

Now, let's go to active directory configuration; well, it's as easy! As you can imagine you create an active directory custom resource. uh You point it at the host name of your directory server and you provide it with bind credentials. So that's it.

B

So there are other configuration options that you can do, for example, user search and group search with custom attributes, but the default configuration that we provide is very well curated for most of the active directorate deployments.

B

Okay, so now the next step is to configure the pinniped considerage, so we wanted to trust the pinniped supervisor as an identity issuer, and this is going to be for a specific cluster audience. In this case it is the dev cluster, so this is likely going to be used by developers.

B

So now you're ready to get the cube, config and distribute this to your developers uh notice here that there are no credentials in the cubeconfig, so it is safe to distribute to users.

B

Now your developers can take that cube, config and start accessing the cluster with cube. Ctl commands here's an example of a developer that may be using a cube. Ctl get namespaces command on the cli. They get prompted for user name and password because of course, we've done active directory configuration. So they get prompted for the username and password here and once they are successfully logged in then they can see the namespaces on the cluster.

B

Now your developers may want to send more cube, ctl commands to the cluster, but of course they are not going to be prompted again for username and password because all of their credentials are cached, so we provide some helpful commands, for example, the whoa command that helps. You understand how you are logged into the cluster. Now, in the previous example, you had put in penny as the username, but kubernetes will display the full user principle name. The flexibility that we offer to the id administrator is to configure the user name.

B

However, they want, for example, using sam account, name user, principal name or the mail attribute. Also by default. We give you all of the direct and nested groups. You can easily change and customize this based on your needs and we provide ample documentation. Examples to support this.

B

Okay, so you logged into uh one cluster with the supervisor and consideration. Now you may want to add another cluster and you may want to give access to another cluster to your user. Well, it's as simple as installing the concierge on the second cluster, with just two cube ctl commands and then configuring the jot authenticator to trust the supervisor and give it a unique audience.

B

So we don't need to install supervisor or any other configuration again.

B

So now you can get config for the second cluster and pass it to your users and developers. Also, users don't get prompted a second time as the credentials are safely cached and can be used across the clusters as long as they are part of the same federation domain.

A

So, to recap allows you to add and remove identity providers at runtime using standard programs resources. It supports multiple different types of identity providers. It allows easy logging across many clusters with single sign-on support and, of course, it's open source so, looking to the future, we're looking to add multiple idp support.

A

uh If folks are interested in this community interest, we would like to add kerberos support for active directory, so you no longer even have to type in your password uh additional ide types like github and google could be implemented and we're looking at various security hardening efforts such as more frequent and automatic rotation of all signing keys and we're really looking to have community members provide input on our roadmap. So we can prioritize things that people are looking to have in their kubernetes environments.

A

We welcome your feedback and look forward to working with you. You can find us in the kubernetes slack as well as on github. Everything here is apache apache license 2.0, just like the rest of the brand's ecosystem and we look forward to working. Thank you.