1,RBACintroduce

In Kubernetes, there are six modes of authorization: ABAC (attribute-based access control), RBAC (role-based access control), Webhook, Node, AlwaysDeny (always denied) and AlwaysAllow (always allowed). As of version 1.6, Kubernetes enables the RBAC access control policy by default. Since 1.8, RBAC has been a stable feature. Set – authorization-mode=RBAC to enable RABC. In the RABC API, authorization is performed as follows: 1) Defining roles: When defining roles, rules for controlling the access to resources of this role are specified. 2) Bind role: Bind the principal to the role to authorize user access.

1.1 Roles and Cluster Roles

In the RBAC API, roles contain rules that represent collections of permissions. In this case, permissions are only granted, not denied. There are two types of roles in Kubernetes, namely normal roles and cluster roles. You can define roles within a namespace through roles, or you can define cluster-wide roles using ClusterRole. A role can only be used to grant access to resources in a single command space. A role named “pod-reader” is defined in the “default” command space. This role can access pod in the “default” namespace:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]Copy the code

A ClusterRole can be granted permissions on the following resources:

  • Cluster-wide resources (similar to Nodes)
  • Non-resource endpoints (similar to “/healthz”)
  • Resources for all namespaces in the cluster (like PODS)

Here is an example of granting cluster roles access to read secret dictionary files:

kind:ClusterRole apiVersion:rbac.authorization.k8s.io/v1 metadata: # "namespace" omitted since ClusterRoles are not namespaced name:secret-reader rules: - apiGroups: ["] resources: [" secrets "] # clear resource type verbs: [" get ", "watch", "a list"]Copy the code

1.2 Role binding and cluster role binding

Role binding Binds a role to one or a group of users so that users can be authorized. Principals are divided into users, groups, and service accounts. Role binding can also be classified into normal role binding and cluster role binding. A role binding can only reference roles in the same namespace. In the following example, the role binding binds user ‘Jane’ to the ‘pod-reader’ role in the ‘default’ namespace, which grants’ Jane ‘access to pods in the’ default ‘namespace.

# This role binding allows "jane" to read pods in the "default" namespace. kind:RoleBinding apiVersion:rbac.authorization.k8s.io/v1 metadata: name:read-pods namespace:default subjects: # main body - kind: User name: Jane apiGroup:. Rbac authorization. K8s. IO roleRef: # reference kind: the Role of Role name: pod - reader apiGroup:. Rbac authorization. K8s. IOCopy the code

Role binding can also grant access by referring to cluster roles. When a principal’s access to a resource is limited to the local namespace, this allows an administrator to define a common set of roles for the entire cluster, which can then be reused across multiple namespaces. For example, the following role binding references cluster roles, but the “Dave” user can only read secrets resources in the “development” namespace:

# This role binding allows "dave" to read secrets in the "development" namespace.
kind:RoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets
  namespace:development# This only grants permissions within the "development" namespace.
subjects:
- kind:User
  name:dave
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.ioCopy the code

Cluster roles can be used for authorization at the cluster level and throughout the namespace. The following example allows users in the “Manager” group to access confidential dictionary resources in all namespaces.

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind:ClusterRoleBinding
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  name:read-secrets-global
subjects:
- kind:Group
  name:manager
  apiGroup:rbac.authorization.k8s.io
roleRef:
  kind:ClusterRole
  name:secret-reader
  apiGroup:rbac.authorization.k8s.ioCopy the code

1.3 resources

In Kubernets, the main resources include Pods, Nodes, Services, Deployment, Replicasets, Statefulsets, Namespace, Persistents, Secrets, and ConfigMaps. In addition, some resources have sub-resources under the Pod, for example, there is a sub-resource log:

GET /api/v1/namespaces/{namespace}/pods/{name}/logCopy the code

The following example shows that the pod-and-pod-logs-reader role has access to Pods and Pods /log:

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
 namespace:default
 name:pod-and-pod-logs-reader
rules:
- apiGroups:[""]
  resources:["pods","pods/log"]
  verbs:["get","list"]Copy the code

You can also specify specific resource instances through resourceNamess to limit the role’s access control to only instances:

kind:Role
apiVersion:rbac.authorization.k8s.io/v1
metadata:
  namespace:default
  name:configmap-updater
rules:
- apiGroups:[""]
  resources:["configmaps"]
  resourceNames:["my-configmap"]
  verbs:["update","get"]Copy the code

1.4 The main body

Principals in RBAC authorization can be groups, users, or service accounts. A user is represented by a string, such as Alice or [email protected], depending on the user name configured by the administrator in the authentication module. System: is reserved for use with Kubernetes systems and therefore cannot be used as a prefix for users. Groups are also provided by authentication modules in a similar format to users.

An example of a role binding body:

The name is [email protected].

subjects:
- kind:User
  name:"[email protected]"
  apiGroup:rbac.authorization.k8s.ioCopy the code

Group “frontend- Admins” :

subjects:
- kind:Group
  name:"frontend-admins"
  apiGroup:rbac.authorization.k8s.ioCopy the code

In the kube-system namespace, the service account named “default” :

subjects:
- kind:ServiceAccount
  name:default
  namespace:kube-systemCopy the code

In the “QA” namespace, all service accounts:

subjects:
- kind:Group
  name:system:serviceaccounts:qa
  apiGroup:rbac.authorization.k8s.ioCopy the code

All service accounts:

subjects:
- kind:Group
  name:system:serviceaccounts
  apiGroup:rbac.authorization.k8s.ioCopy the code

All authenticated users (Version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.ioCopy the code

All unauthenticated users (Version 1.5+):

subjects:
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.ioCopy the code

For all users (Version 1.5+):

subjects:
- kind:Group
  name:system:authenticated
  apiGroup:rbac.authorization.k8s.io
- kind:Group
  name:system:unauthenticated
  apiGroup:rbac.authorization.k8s.ioCopy the code

2Command line tools

Kubernetes can bind roles through command tools.

2.1 kubectl create rolebinding

Role binding in the specified namespace:

1) In the “acme” namespace, grant the “admin” cluster role to “Bob” :

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acmeCopy the code

2) In the acme namespace, grant the admin cluster role to the acme:myapp service account:

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acmeCopy the code

2.2 kubectl create clusterrolebinding

Role binding across the cluster:

1) Grant a cluster-admin role to user root in the cluster:

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=rootCopy the code

2) grant the “system:node” cluster role to “kubelet” user in the entire cluster:

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubeletCopy the code

3) Grant the “view” cluster role to the “Acme :myapp” service account in the entire cluster:

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myappCopy the code

3, service account permissions

By default, the RBAC policy grants control board component, Node, and controller scoped permissions, but does not grant access to service accounts outside the “kube-system” namespace. This allows administrators to grant specific roles to service accounts as needed.

From safest to least safe, the method is as follows:

1) Grant roles to service accounts for a given application (best practice)

This requires that a serviveAccountName be specified in the Pod specification and that the serviceaccount has been created (via API, kubectl create serviceaccount, and so on). For example, in the “my-namespace” namespace, grant the cluster role to the “my-sa” service account “view” :

kubectl create rolebinding my-sa-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:my-sa \ 
--namespace=my-namespace Copy the code

2) Grant the “View” cluster role to the “default” service account in a namespace

If the application does not specify serviceAccountName, it uses the default service account. For example, in the “my-namespace” namespace, grant the cluster role to the “default” service account “view” :

kubectl create rolebinding default-view \ 
--clusterrole=view \ 
--serviceaccount=my-namespace:default \ 
--namespace=my-namespace Copy the code

Currently, many plug-ins run as “default” service accounts in the “kube-system” namespace. To allow superusers to access these plug-ins, grant “cluster-admin” role to “default” in the “kube-system” namespace.

$ kubectl create clusterrolebinding add-on-cluster-admin \ 
--clusterrole=cluster-admin \ 
--serviceaccount=kube-system:default Copy the code

3) Grant roles to all service accounts in a namespace:

If you want all applications in a namespace to have a role, regardless of the service account they use, you can grant roles to service account groups. For example, in “my – the namespace name” space, will be “the view” cluster role granted “system: serviceaccounts: my – namespace” group:

$ kubectl create rolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts:my-namespace \ 
--namespace=my-namespace Copy the code

4) Grant a role to all service accounts in the entire cluster (not recommended)

If you do not want to manage permissions on a per-namespace basis, you can authorize access across the cluster. For example, at the whole cluster level, grant the “view” cluster role to “sytem: ServiceAccounts” :

$ kubectl create clusterrolebinding serviceaccounts-view \ 
--clusterrole=view \ 
--group=system:serviceaccounts Copy the code

5) Grant superuser access to all service accounts in the entire cluster (strongly not recommended)

If access is not a priority, superusers can be granted access to all service accounts.

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \ 
--clusterrole=cluster-admin \ 
--group=system:serviceaccounts Copy the code

4. Loose RBAC permissions

The following policy allows all service accounts to act as cluster administrators. The application running in the container automatically receives the service account certificate and performs all API actions. This includes checking the confidential dictionary and modifying permissions, which are not recommended.

$ kubectl create clusterrolebinding permissive-binding \ 
--clusterrole=cluster-admin \ 
--user=admin \ 
--user=kubelet \ 
--group=system:serviceaccounts Copy the code

Reference material

1. The Authorization the Overview “address: kubernetes. IO/docs/admin /…

2. Using RBAC Authorization address: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

About the author: Ji Xiangyuan, product manager of Beijing Shenzhou Aerospace Software Technology Co., LTD. The copyright of this article belongs to the author.