Kubernetes 1.6 New Feature Learning: RBAC Authorization

Posted by morris520 on Wed, 03 Jul 2019 21:44:48 +0200

Summary

The access control process of API Server in Kuberntes is illustrated as follows:

In Kubernetes, authorization is a step after authentication. Authorization is to determine whether a user (ordinary user or Service Account) has the right to request the Kubernetes API to do something.

Previously, the authorization strategy in Kubernetes was mainly ABAC(Attribute-Based Access Control). For ABAC, Kubernetes is difficult to implement, and requires SSH and root file system access rights of Master Node. API Server needs to be restarted after the authorization policy changes.

In Kubernetes 1.6, RBAC(Role-Based Access Control) entered the Beta phase of role-based access control. RBAC access control policies can be configured using kubectl or Kubernetes API. Using RBAC, users can be authorized directly to have authorization management rights, so that they no longer need to touch Master Node directly. RBAC is mapped to API resources and operations in Kubernetes.

Resource object of RBAC API

In Kubernetes 1.6, RBAC is enabled for API Server by starting parameter - authorization-mode=RBAC.API Overview.

The 1.6 version of Kubernetes cluster initialized with kubeadm has opened RBAC by default for API Server. You can view the static Pod definition file of API Server on Master Node:

    

  1. cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep RBAC
    2. 

  2.     - --authorization-mode=RBAC
    3.

The RBAC API defines four resource objects to describe the connection privileges between users and resources in RBAC:

  • Role
  • ClusterRole
  • RoleBinding
  • ClusterRoleBinding

Role and Cluster Role

Role is a collection of permissions. Role is a resource defined under a Namespace and used under this specific Namespace. Cluster Role is similar to Role, but Cluster Role is used throughout the cluster.

Let's use kubectl to print Role and CulturRole in the Kubernetes cluster:

    

  1. kubectl get roles --all-namespaces
    2. 

  2. NAMESPACE     NAME                                        AGE
    3. 

  3. kube-public   system:bootstrap-signer-clusterinfo         6d
    4. 

  4. kube-public   system:controller:bootstrap-signer          6d
    5. 

  5. kube-system   extension-apiserver-authentication-reader   6d
    6. 

  6. kube-system   system:controller:bootstrap-signer          6d
    7. 

  7. kube-system   system:controller:token-cleaner             6d
    8. 

    

  1. kubectl get ClusterRoles
    2. 

  2. NAME                                           AGE
    3. 

  3. admin                                          6d
    4. 

  4. cluster-admin                                  6d
    5. 

  5. edit                                           6d
    6. 

  6. flannel                                        5d
    7. 

  7. system:auth-delegator                          6d
    8. 

  8. system:basic-user                              6d
    9. 

  9. system:controller:attachdetach-controller      6d
    10. 

  10. ......
    11. 

  11. system:kube-aggregator                         6d
    12. 

  12. system:kube-controller-manager                 6d
    13. 

  13. system:kube-dns                                6d
    14. 

  14. system:kube-scheduler                          6d
    15. 

  15. system:node                                    6d
    16. 

  16. system:node-bootstrapper                       6d
    17. 

  17. system:node-problem-detector                   6d
    18. 

  18. system:node-proxier                            6d
    19. 

  19. system:persistent-volume-provisioner           6d
    20. 

  20. view                                           6d
    21.

You can see that many Roles and Cluster Roles have been built in or created in the Kubernetes cluster created previously.

Next, create a Role named pod-reader in the default namespace. The role-pord-reader.yaml file is as follows:

    

  1. kind: Role
    2. 

  2. apiVersion: rbac.authorization.k8s.io/v1beta1
    3. 

  3. metadata:
    4. 

  4.   namespace: default
    5. 

  5.   name: pod-reader
    6. 

  6. rules:
    7. 

  7. - apiGroups: [""] # "" indicates the core API group
    8. 

  8.   resources: ["pods"]
    9. 

  9.   verbs: ["get", "watch", "list"]
    10. 

    

  1. kubectl create -f role-pord-reader.yaml
    2. 

  2. role "pod-reader" created
    3. 

    4. 

  4. kubectl get roles
    5. 

  5. NAME         AGE
    6. 

  6. pod-reader   1m
    7.

Note that RBAC is still in Beta phase in Kubernetes 1.6, so the API belongs to rbac.authorization.k8s.io, and the apiVersion above is rbac.authorization.k8s.io/v1beta1.

Here's another definition file for ClusterRole:

    

  1. kind: ClusterRole
    2. 

  2. apiVersion: rbac.authorization.k8s.io/v1beta1
    3. 

  3. metadata:
    4. 

  4.   # "namespace" omitted since ClusterRoles are not namespaced
    5. 

  5.   name: secret-reader
    6. 

  6. rules:
    7. 

  7. - apiGroups: [""]
    8. 

  8.   resources: ["secrets"]
    9. 

  9.   verbs: ["get", "watch", "list"]
    10.

Role Binding and Cluster Role Binding

RoleBinding binds Role to Subject, the main body of the account, so that Subject inherits Role's permissions under namespace. Cluster Role Binding binds Cluster Role to Subject, allowing Subject to integrate the privileges of Cluster Role across the cluster.

Account Subject is still called "user" here, including group, user and Service Account.

    

  1. kubectl get rolebinding --all-namespaces
    2. 

  2. NAMESPACE     NAME                                   AGE
    3. 

  3. kube-public   kubeadm:bootstrap-signer-clusterinfo   6d
    4. 

  4. kube-public   system:controller:bootstrap-signer     6d
    5. 

  5. kube-system   system:controller:bootstrap-signer     6d
    6. 

  6. kube-system   system:controller:token-cleaner        6d
    7. 

    

  1. kubectl get clusterrolebinding
    2. 

  2. NAME                                           AGE
    3. 

  3. cluster-admin                                  6d
    4. 

  4. flannel                                        6d
    5. 

  5. kubeadm:kubelet-bootstrap                      6d
    6. 

  6. kubeadm:node-proxier                           6d
    7. 

  7. system:basic-user                              6d
    8. 

  8. system:controller:attachdetach-controller      6d
    9. 

  9. system:controller:certificate-controller       6d
    10. 

  10. ......
    11. 

  11. system:controller:ttl-controller               6d
    12. 

  12. system:discovery                               6d
    13. 

  13. system:kube-controller-manager                 6d
    14. 

  14. system:kube-dns                                6d
    15. 

  15. system:kube-scheduler                          6d
    16. 

  16. system:node                                    6d
    17. 

  17. system:node-proxier                            6d
    18.

In fact, a RoleBinding can refer to either a role under the same namespace or a Cluster Role, and when RoleBinding refers to Cluster Role, the user's inherited rights are limited to the namespace where RoleBinding resides.

    

  1. kind: RoleBinding
    2. 

  2. apiVersion: rbac.authorization.k8s.io/v1beta1
    3. 

  3. metadata:
    4. 

  4.   name: read-pods
    5. 

  5.   namespace: default
    6. 

  6. subjects:
    7. 

  7. - kind: User
    8. 

  8.   name: jane
    9. 

  9.   apiGroup: rbac.authorization.k8s.io
    10. 

  10. roleRef:
    11. 

  11.   kind: Role
    12. 

  12.   name: pod-reader
    13. 

  13.   apiGroup: rbac.authorization.k8s.io
    14. 

    

  1. kind: RoleBinding
    2. 

  2. apiVersion: rbac.authorization.k8s.io/v1beta1
    3. 

  3. metadata:
    4. 

  4.   name: read-secrets
    5. 

  5.   namespace: development # This only grants permissions within the "development" namespace.
    6. 

  6. subjects:
    7. 

  7. - kind: User
    8. 

  8.   name: dave
    9. 

  9.   apiGroup: rbac.authorization.k8s.io
    10. 

  10. roleRef:
    11. 

  11.   kind: ClusterRole
    12. 

  12.   name: secret-reader
    13. 

  13.   apiGroup: rbac.authorization.k8s.io
    14.

Default Role and Role Binding in Kubernetes

API Server has created a series of Cluster Roles and Cluster Role Binding. The names in these resource objects begin with system: to indicate that the resource object belongs to the Kubernetes system infrastructure. That is to say, the default cluster role of RBAC has been covered enough so that the cluster can be completely in place. RBAC runs under management. Modifying these resource objects may have unknown consequences, such as defining the permissions of the kubelet process for the system:node ClusterRole, which may cause the kubelet to fail to work if the role is modified.

You can use the label kubernetes.io/bootstrapping=rbac-defaults to view the default Cluster Role and Cluster Role Binding:

    

  1. kubectl get clusterrole -l kubernetes.io/bootstrapping=rbac-defaults
    2. 

  2. NAME                                           AGE
    3. 

  3. admin                                          6d
    4. 

  4. cluster-admin                                  6d
    5. 

  5. edit                                           6d
    6. 

  6. system:auth-delegator                          6d
    7. 

  7. system:basic-user                              6d
    8. 

  8. system:controller:attachdetach-controller      6d
    9. 

  9. system:controller:certificate-controller       6d
    10. 

  10. ......
    11. 

  11. system:node-problem-detector                   6d
    12. 

  12. system:node-proxier                            6d
    13. 

  13. system:persistent-volume-provisioner           6d
    14. 

  14. view                                           6d
    15. 

    

  1. kubectl get clusterrolebinding -l kubernetes.io/bootstrapping=rbac-defaults
    2. 

  2. NAME                                           AGE
    3. 

  3. cluster-admin                                  6d
    4. 

  4. system:basic-user                              6d
    5. 

  5. system:controller:attachdetach-controller      6d
    6. 

  6. system:controller:certificate-controller       6d
    7. 

  7. system:controller:cronjob-controller           6d
    8. 

  8. system:controller:daemon-set-controller        6d
    9. 

  9. system:controller:deployment-controller        6d
    10. 

  10. ......
    11. 

  11. system:discovery                               6d
    12. 

  12. system:kube-controller-manager                 6d
    13. 

  13. system:kube-dns                                6d
    14. 

  14. system:kube-scheduler                          6d
    15. 

  15. system:node                                    6d
    16. 

  16. system:node-proxier                            6d
    17.

Detailed privilege information about these roles can be viewed Default Roles and Role Bindings


Original text http://blog.frognew.com/2017/04/kubernetes-1.6-rbac.html

Topics: Kubernetes DNS kubelet Attribute

Hot Topics

©2024 Programmer Think