Upgrade to Pro — share decks privately, control downloads, hide ads and more …

KubeCon 2016: Kubernetes Auth and Access Control

9a5b28c1bf706b9138017bf0fd23ac45?s=47 Eric Chiang
November 09, 2016
610

KubeCon 2016: Kubernetes Auth and Access Control

9a5b28c1bf706b9138017bf0fd23ac45?s=128

Eric Chiang

November 09, 2016
Tweet

Transcript

  1. Kubernetes Auth and Access Control Eric Chiang Software Engineer, CoreOS

    @erchiang | github.com/ericchiang
  2. 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.
  3. Agenda 1. Overview of API server auth 2. Understanding users

    in Kubernetes 3. Authorization and RBAC 4. Fun stuff: dex demo
  4. kubelet proxy Internet Kubernetes Worker 1/n Control Plane API Server

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

    Scheduler Controller kubeclt
  6. 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.
  7. Users in Kubernetes

  8. Users in Kubernetes • Kubernetes doesn’t have users* ◦ Not

    really true, but I find it easier to think this way.
  9. 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”]
  10. Users in Kubernetes: plugins Admins choose which credential strategies they

    support: • x509 client auth • Password files • Bearer token webhooks • etc
  11. /usr/bin/kube-apiserver \ --client-ca-file=/etc/kubernetes/ca.pem \ ... Users in Kubernetes: x509 certs

  12. $ 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
  13. $ 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
  14. 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.
  15. 99403c9f-8bf1,eric,3,"developer,gophers" a56ee84a-f41c,andrew,5,"human" Users in Kubernetes: token files

  16. Users in Kubernetes: Webhook API Server kubeclt User management system

    Authorization: Bearer (token) (token)
  17. What do these all have in common? • No objects

    in the API to interact with these plugins. • Complete managed outside Kubernetes.
  18. Users in Kubernetes: service accounts • Service accounts are credentials

    managed by k8s. • Only users that can be accessed through the k8s API.
  19. $ kubectl create serviceaccount do-the-robot Users in Kubernetes: service accounts

  20. $ 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
  21. $ 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
  22. 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
  23. 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
  24. None
  25. Users in Kubernetes: service accounts • Have weird usernames: ◦

    system:serviceaccount:kube-system:default • Just JWTs (signed JSON payloads)
  26. • 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
  27. Users in Kubernetes: other options

  28. Users in Kubernetes: other options • Bearer token webhook ◦

    Used by GKE • OpenID Connect (will talk about later) • Static files (for bootstrapping)
  29. Authorization

  30. Authorization and RBAC • Authorization uses usernames and group names

    to create policy. • Ported from RedHat’s OpenShift.
  31. 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)
  32. Authorization and RBAC • Role • RoleBinding • ClusterRole •

    ClusterRoleBinding
  33. Roles vs Bindings • Roles declare a set of powers.

    • Bindings allow users or groups to have those powers.
  34. kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1alpha1 metadata: name: secret-reader rules: - apiGroups:

    [""] # v1 namespace resources: ["secrets"] verbs: ["get", "watch", "list"] RBAC: Roles
  35. 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
  36. 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.
  37. 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.
  38. RBAC: ClusterRoles vs Roles Namespace Namespace ClusterRole “Read Only” ClusterRole

    “Admin” Role “Pod Deleter” ClusterRole w/ ClusterRoleBinding ClusterRole w/ RoleBinding Role w/ RoleBinding
  39. 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.
  40. 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.
  41. Authorization: other plugins • Webhook! • ABAC policy file. ◦

    Another one extremely useful for bootstrapping.
  42. Dex

  43. 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.
  44. Dex v2

  45. Dex: OpenID Connect app

  46. Dex: OpenID Connect app

  47. Dex: OpenID Connect app

  48. Dex: OpenID Connect app

  49. Dex: OpenID Connect - ID Token app User:eric

  50. { "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
  51. { "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
  52. { "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
  53. Dex: OpenID Connect - ID Token app User:eric

  54. Dex: OpenID Connect app User:eric

  55. Dex: OpenID Connect app User:eric

  56. Dex • Automatic signing key rotation. • Revocation through refresh

    tokens. • Lots of login options!
  57. Dex v2

  58. 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.
  59. Dex v2 • Runs natively on your cluster. • Can

    authenticate through backends like Google, GitHub, LDAP, etc with the API server.
  60. Dex v2 Open source github.com/coreos/dex

  61. Dex v2 Demo time

  62. eric.chiang@coreos.com @erchiang QUESTIONS? Thanks! We’re hiring: coreos.com/careers Let’s talk! IRC

    More events: coreos.com/community LONGER CHAT?