Kubernetes Auth and Access Control Eric Chiang Software Engineer, CoreOS @erchiang | github.com/ericchiang

Why a talk about auth? ● Assumption: ○ You’re all going to try to set up clusters and have to deal with this. ● “Dealing with this” can range from: ○ Whitelisting some set of nodes. ○ Multi-tenant environments.

Agenda 1. Overview of API server auth 2. Understanding users in Kubernetes 3. Authorization and RBAC 4. Fun stuff: dex demo

kubelet proxy Internet Kubernetes Worker 1/n Control Plane API Server Scheduler Controller kubeclt

kubelet proxy Internet Kubernetes Worker 1/n Control Plane API Server Scheduler Controller kubeclt

API server auth: request flow Request comes in: ● Authentication ○ Credentials determine who’s talking to the API server. ● Authorization ○ API server then determines if that user can perform that action.

Users in Kubernetes

Users in Kubernetes ● Kubernetes doesn’t have users* ○ Not really true, but I find it easier to think this way.

Users in Kubernetes ● Kubernetes doesn’t have users* ○ Not really true, but I find it easier to think this way. ● “Users” are just strings associated with a request through credentials. ○ Username=eric ○ Groups=[“developer”, “gopher”]

Users in Kubernetes: plugins Admins choose which credential strategies they support: ● x509 client auth ● Password files ● Bearer token webhooks ● etc

/usr/bin/kube-apiserver \ --client-ca-file=/etc/kubernetes/ca.pem \ ... Users in Kubernetes: x509 certs

$ openssl x509 -in hi.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 7920032060917626532 (0x6de99b3280b336a4) Signature Algorithm: sha256WithRSAEncryption Issuer: O=kube-cluster, CN=kube-ca Validity Not Before: Nov 1 19:50:23 2016 GMT Not After : Nov 1 19:50:24 2017 GMT Subject: O=kubelet, CN=kubelet-1 Users in Kubernetes: x509 certs

$ openssl x509 -in hi.crt -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 7920032060917626532 (0x6de99b3280b336a4) Signature Algorithm: sha256WithRSAEncryption Issuer: O=kube-cluster, CN=kube-ca Validity Not Before: Nov 1 19:50:23 2016 GMT Not After : Nov 1 19:50:24 2017 GMT Subject: O=kubelet, CN=kubelet-1 Users in Kubernetes: x509 certs

Users in Kubernetes: x509 certs ● Does this client have a valid client cert? ○ No: reject request. ○ Yes: determine username and groups based on certificate attributes.

99403c9f-8bf1,eric,3,"developer,gophers" a56ee84a-f41c,andrew,5,"human" Users in Kubernetes: token files

Users in Kubernetes: Webhook API Server kubeclt User management system Authorization: Bearer (token) (token)

What do these all have in common? ● No objects in the API to interact with these plugins. ● Complete managed outside Kubernetes.

Users in Kubernetes: service accounts ● Service accounts are credentials managed by k8s. ● Only users that can be accessed through the k8s API.

$ kubectl create serviceaccount do-the-robot Users in Kubernetes: service accounts

$ kubectl create serviceaccount do-the-robot $ kubectl get serviceaccount do-the-robot -o yaml apiVersion: v1 kind: ServiceAccount metadata: name: do-the-robot # ... secrets: - name: do-the-robot-token-hlfte Users in Kubernetes: service accounts

$ kubectl get secrets -o yaml do-the-robot-token-hlfte apiVersion: v1 data: ca.crt: ( LOT OF DATA ) namespace: ZGVmYXVsdA== token: ( JSON web token signed by API server) kind: Secret type: kubernetes.io/service-account-token metadata: # ... Users in Kubernetes: service accounts

apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 template: spec: containers: - name: nginx image: nginx:1.7.9 serviceAccountName: do-the-robot Users in Kubernetes: service accounts

spec: containers: # ... - mountPath: /var/run/secrets/kubernetes.io/serviceaccount name: do-the-robot-token-hlfte readOnly: true # ... volumes: - name: do-the-robot-token-hlfte secret: defaultMode: 420 secretName: do-the-robot-token-hlfte Users in Kubernetes: service accounts

No content

Users in Kubernetes: service accounts ● Have weird usernames: ○ system:serviceaccount:kube-system:default ● Just JWTs (signed JSON payloads)

● Automatically mounted into pods. ○ Gives each pod credentials (and an associated user) for talking to the API server. ● Only way to create users through the API. ○ Credentials stored in secrets, be careful! ● Can be used from outside the cluster. Users in Kubernetes: service accounts

Users in Kubernetes: other options

Users in Kubernetes: other options ● Bearer token webhook ○ Used by GKE ● OpenID Connect (will talk about later) ● Static files (for bootstrapping)

Authorization

Authorization and RBAC ● Authorization uses usernames and group names to create policy. ● Ported from RedHat’s OpenShift.

Authorization and RBAC ● Default: deny all ● Contain a subject, verb, resource, and namespace. ○ User A can create pods in namespace B. ● Cannot: ○ Refer to a single object in a namespace. ○ Refer to arbitrary fields in a resource. ● Can: ○ Refer to subresources (e.g. nodes/status)

Authorization and RBAC ● Role ● RoleBinding ● ClusterRole ● ClusterRoleBinding

Roles vs Bindings ● Roles declare a set of powers. ● Bindings allow users or groups to have those powers.

kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1alpha1 metadata: name: secret-reader rules: - apiGroups: [""] # v1 namespace resources: ["secrets"] verbs: ["get", "watch", "list"] RBAC: Roles

kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1alpha1 metadata: name: read-secrets subjects: - kind: Group # May be "User", "Group" or "ServiceAccount" name: manager roleRef: kind: ClusterRole name: secret-reader apiVersion: rbac.authorization.k8s.io/v1alpha1 RBAC: Role Bindings

ClusterRoles vs. Roles ● Roles can either exist in a cluster level or a namespace level. ● Cluster role: ○ Manage one set of roles for your entire cluster. ● Role: ○ Allow “namespace admins” to admin roles just for a namespace.

ClusterRoleBindings vs. RoleBindings ● ClusterRoleBindings grant a user power throughout the entire cluster. ○ Can’t refer to a role, only a cluster role. ● RoleBindings grant a user power within a namespace.

RBAC: ClusterRoles vs Roles Namespace Namespace ClusterRole “Read Only” ClusterRole “Admin” Role “Pod Deleter” ClusterRole w/ ClusterRoleBinding ClusterRole w/ RoleBinding Role w/ RoleBinding

Authorization and RBAC ● BIGGEST GOT YA: you must have the power of a role to bind a user to that role. ○ If you don’t have the ability to create secrets, you can’t give someone else that power. ● Currently get around this with a bootstrapping flag that lets a user sidestep this.

Authorization and RBAC: 1.6 ● Lots of work done by @deads2k (RedHat). ● Biggest highlight: default roles and role bindings! ○ Extremely helpful for bootstrapping. ○ Can mint x509 cert for “cluster-admin” to bootstrap cluster.

Authorization: other plugins ● Webhook! ● ABAC policy file. ○ Another one extremely useful for bootstrapping.

Dex

Dex ● Open source: https://github.com/coreos/dex ● OpenID Connect server ○ Protocol is supported as a Kubernetes authentication plugin. ● Federated logins ○ Can login to dex through other identity providers.

Dex v2

Dex: OpenID Connect app

Dex: OpenID Connect app

Dex: OpenID Connect app

Dex: OpenID Connect app

Dex: OpenID Connect - ID Token app User:eric

{ "access_token": "HK6E_P6Dh8Y93mRNtsDB1Q", "token_type": "Bearer", "expires_in": 86400, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjhiNWI2ZjdmNmQ2YWRiODdkMjRmYWViYzFmZjNmMWEwODk4M jU1MjgifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiMDhhODY4NGIt ZGI4OC00YjczLTkwYTktM2NkMTY2MWY1NDY2IiwiYXVkIjoiZXhhbXBsZS1hcHAiLCJleHAiOjE0Nz gzMjA0NTEsImlhdCI6MTQ3ODIzNDA1MSwiZW1haWwiOiJhZG1pbkBleGFtcGxlLmNvbSIsImVtYWls X3ZlcmlmaWVkIjp0cnVlLCJuYW1lIjoiYWRtaW4ifQ.GQaNO0BAB6PGptumTZAwzHs_JiwLMT_AUkV wRXZhXI0rfj9kn0qC4Z9elXik074kho61FIFiqFRmj-ipP037a1WyGjoNZvZuzlhGqtFNBuOmg0qe5 tYDwAcBQ5UvHMLyiQvBDicEw-SblwBCE67Tl6yPTTMMvXzcw87NbxVSGmAL1njDJ94b1LniwazncAy tdMDTwQSdo3fZi-9mNcFf4UTFvKuhbMxTcjKgMlFx8TnFEFP8qFg5MZoGnclHMlEAjAp5S56xJhYUB D44Ui7H5T6UkiYM8mEtm62mIszQ6FT3ZBoSdyxZTtdJNaHaAmWe8WzQ3eaLrH1ytHDwjzLU4Q" } OpenID Connect Token Response

{ "access_token": "HK6E_P6Dh8Y93mRNtsDB1Q", "token_type": "Bearer", "expires_in": 86400, "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjhiNWI2ZjdmNmQ2YWRiODdkMjRmYWViYzFmZjNmMWEwODk4M jU1MjgifQ.eyJpc3MiOiJodHRwOi8vMTI3LjAuMC4xOjU1NTYvZGV4Iiwic3ViIjoiMDhhODY4NGIt ZGI4OC00YjczLTkwYTktM2NkMTY2MWY1NDY2IiwiYXVkIjoiZXhhbXBsZS1hcHAiLCJleHAiOjE0Nz gzMjA0NTEsImlhdCI6MTQ3ODIzNDA1MSwiZW1haWwiOiJhZG1pbkBleGFtcGxlLmNvbSIsImVtYWls X3ZlcmlmaWVkIjp0cnVlLCJuYW1lIjoiYWRtaW4ifQ.GQaNO0BAB6PGptumTZAwzHs_JiwLMT_AUkV wRXZhXI0rfj9kn0qC4Z9elXik074kho61FIFiqFRmj-ipP037a1WyGjoNZvZuzlhGqtFNBuOmg0qe5 tYDwAcBQ5UvHMLyiQvBDicEw-SblwBCE67Tl6yPTTMMvXzcw87NbxVSGmAL1njDJ94b1LniwazncAy tdMDTwQSdo3fZi-9mNcFf4UTFvKuhbMxTcjKgMlFx8TnFEFP8qFg5MZoGnclHMlEAjAp5S56xJhYUB D44Ui7H5T6UkiYM8mEtm62mIszQ6FT3ZBoSdyxZTtdJNaHaAmWe8WzQ3eaLrH1ytHDwjzLU4Q" } OpenID Connect Token Response

{ "iss": "https://auth.example.com/dex", "sub": "08a8684b-db88-4b73-90a9-3cd1661f5466", "aud": "example-app", "exp": 1478320451, "iat": 1478234051, "email": "admin@example.com", "email_verified": true, "groups": ["developers", "developers"], "name": "admin" } OpenID Connect Token Response

Dex: OpenID Connect - ID Token app User:eric

Dex: OpenID Connect app User:eric

Dex: OpenID Connect app User:eric

Dex ● Automatic signing key rotation. ● Revocation through refresh tokens. ● Lots of login options!

Dex v2

Dex v2 ● Complete rewrite. ● Dramatically simpler deployments. ○ Single scalable binary. ● Reworked storage layer. ○ Can now store state in the Kubernetes API through Third Party Resources.

Dex v2 ● Runs natively on your cluster. ● Can authenticate through backends like Google, GitHub, LDAP, etc with the API server.

Dex v2 Open source github.com/coreos/dex

Dex v2 Demo time

eric.chiang@coreos.com @erchiang QUESTIONS? Thanks! We’re hiring: coreos.com/careers Let’s talk! IRC More events: coreos.com/community LONGER CHAT?