Shulou(Shulou.com)06/02 Report--

1. Introduction of RBAC

In Kubernetes, authorization has six modes: ABAC (attribute-based access control), RBAC (role-based access control), Webhook, Node, AlwaysDeny (always denied) and AlwaysAllow (always allowed).

Starting with version 1.6, Kubernetes enables RBAC access control policy by default. Since 1. 8, RBAC has been a stable function. Enable RABC by setting-- authorization-mode=RBAC. In RABC API, use the following steps to authorize:

Define roles: rules that specify access control for resources for this role when defining a role

Bind role: bind the principal to the role to authorize access to the user.

1.1, roles and cluster roles

In RBAC API, roles contain rules that represent a set of permissions. Here, permissions are only granted, not denied settings. There are two types of roles in Kubernetes, the normal role (Role) and the cluster role (ClusterRole). Roles can be defined in a namespace through Role, or cluster-wide roles can be defined using ClusterRole. A Role can only be used to grant access to resources in a single command space. Here is a role named pod-reader defined in the default command space, which can access Pod in the default namespace:

Kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: default name: pod-readerrules:- apiGroups: ["] #" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]

ClusterRole can be used to grant the same permissions as Role. They can be granted access to the following resources:

Clustered resources (similar to Node) non-resource endpoints (similar to "/ healthz") resources of all namespaces in the cluster (similar to Pod)

The following ClusterRole can be used to grant read access to secrets in any particular namespaces or across all namespaces.

Kind: ClusterRoleapiVersion: rbac.authorization.k8s.io/v1metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-readerrules:- apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] 1.2, RoleBinding and ClusterRoleBinding

Role binding is used to bind a role to a user or group of users for the purpose of authorizing the user. Principals are divided into users, groups, and service accounts. Role binding is also divided into role ordinary role binding and cluster role binding. Role bindings can only refer to roles under the same namespace.

In the following example, the role binding in the default namespace binds the jane user to the pod-reader role, which grants jane access to Pod under the default namespace.

# This role binding allows "jane" to read pods in the "default" namespace.kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: read-pods namespace: defaultsubjects:- kind: User name: jane # Name is case sensitive apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role # this must be Role or ClusterRole name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io

Role binding can also grant access by referencing cluster roles, when principal access to resources is limited to this namespace, which allows administrators to define a collection of common roles for the entire cluster and then reuse them in multiple namespaces.

For example, the following role binding references the cluster role, but dave users can only read secret s resources in the development namespace:

# This role binding allows "dave" to read secrets in the "development" namespace.kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: read-secrets namespace: development # This only grants permissions within the "development" namespace.subjects:- kind: User name: dave # Name is case sensitive apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io

Cluster roles can be used to authorize at the cluster level and the entire namespace. The following example allows users in the manager group to access secret dictionary resources in all namespaces.

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.kind:ClusterRoleBindingapiVersion:rbac.authorization.k8s.io/v1metadata: name:read-secrets-globalsubjects:- kind:Group name:manager apiGroup:rbac.authorization.k8s.ioroleRef: kind:ClusterRole name:secret-reader apiGroup:rbac.authorization.k8s.io1.3, Resources

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

GET / api/v1/namespaces/ {namespace} / pods/ {name} / log

The following example shows that the pod-and-pod-logs-reader role can access pods and pods/log:

Kind:RoleapiVersion:rbac.authorization.k8s.io/v1metadata: namespace:default name:pod-and-pod-logs-readerrules:- apiGroups: ["] resources: [" pods "," pods/log "] verbs: [" get "," list "]

You can also specify a specific resource instance through resourceNamess to restrict that roles can only access the instance:

Kind:RoleapiVersion:rbac.authorization.k8s.io/v1metadata: namespace:default name:configmap-updaterrules:- apiGroups: ["] resources: [" configmaps "] resourceNames: [" my-configmap "] verbs: [" update "," get "] 1.4, body

Principals in RBAC authorization can be groups, users, or service accounts. The user is represented by a string, such as "alice", "bob@example.com", etc., depending on the user name configured by the administrator in the authentication module. System: reserved for use with Kubernetes systems, so it cannot be used as a prefix for users. The group is also provided with an authentication module in a format similar to that of users.

An example of binding a subject in a role:

User named "alice@example.com":

Subjects:- kind:User name: "alice@example.com" apiGroup:rbac.authorization.k8s.io

Group named "frontend-admins":

Subjects:- kind:Group name: "frontend-admins" apiGroup:rbac.authorization.k8s.io

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

Subjects:- kind:ServiceAccount name:default namespace:kube-system

In the "qa" namespace, all service accounts:

Subjects:- kind:Group name:system:serviceaccounts:qa apiGroup:rbac.authorization.k8s.io

All service accounts:

Subjects:- kind:Group name:system:serviceaccounts apiGroup:rbac.authorization.k8s.io

All authenticated users (version 1.5 +):

Subjects:- kind:Group name:system:authenticated apiGroup:rbac.authorization.k8s.io

All unauthenticated users (version 1.5 +):

Subjects:- kind:Group name:system:unauthenticated apiGroup:rbac.authorization.k8s.io

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.io II. Command line tools

Kubernetes can bind roles through command tools.

2.1 、 kubectl create rolebinding

Perform role binding in the specified namespace:

1) in the acme namespace, grant the admin cluster role to the bob user:

$kubectl create rolebinding bob-admin-binding-clusterrole=admin-user=bob-namespace=acme

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=acme2.2, kubectl create clusterrolebinding

Role binding throughout the cluster:

1) throughout the cluster, the cluster-admin cluster role is granted to root users:

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

2) throughout the cluster, the system:node cluster role is granted to kubelet users:

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

3) throughout the cluster, grant the view cluster role to the acme:myapp service account:

$kubectl create clusterrolebinding myapp-view-binding-- clusterrole=view-- serviceaccount=acme:myapp III. Service account permissions

By default, RBAC policy grants dashboard components, Node, and controller scope permissions, but does not grant access to service accounts outside the kube-system namespace. This allows the administrator to grant specific roles to the service account as needed.

The order from the safest to the least secure is as follows:

1) Grant a role to a service account for a specified application (best practices)

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

Kubectl create rolebinding my-sa-view\-- clusterrole=view\-- serviceaccount=my-namespace:my-sa\-- namespace=my-namespace 2) Grant the view cluster role to the default service account in a namespace

If the application does not specify a serviceAccountName, it will use the default service account. For example, within the my-namespace namespace, the default service account is granted the view cluster role:

Kubectl create rolebinding default-view\-clusterrole=view\-serviceaccount=my-namespace:default\-namespace=my-namespace

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

$kubectl create clusterrolebinding add-on-cluster-admin\-- clusterrole=cluster-admin\-- serviceaccount=kube-system:default 3) in one namespace, grant roles to all service accounts:

If you want all applications in a namespace to have a role, regardless of the service account they use, you can grant the role to the service account group. For example, in the my-namespace namespace, grant the view cluster role to the system:serviceaccounts:my-namespace group:

$kubectl create rolebinding serviceaccounts-view\-- clusterrole=view\-- group=system:serviceaccounts:my-namespace\-- namespace=my-namespace 4) Grant a role to all service accounts throughout the cluster (not recommended)

If you do not want to manage permissions on a per-namespace basis, you can authorize access throughout the cluster. For example, at the entire cluster level, the view cluster role is granted to sytem:serviceaccounts:

$kubectl create clusterrolebinding serviceaccounts-view\-- clusterrole=view\-- group=system:serviceaccounts 5) Grant superuser access to all service accounts throughout the cluster (highly recommended)

If you don't pay much attention to access, you can grant the superuser access to all service accounts.

$kubectl create clusterrolebinding serviceaccounts-cluster-admin\-- clusterrole=cluster-admin\-- group=system:serviceaccounts 6) loose RBAC permissions

The following policy allows all service accounts to act as cluster administrators. Applications running in the container will automatically receive the service account certificate and perform all API activities. This includes viewing secret dictionaries and modifying permissions, which are not recommended access policies.

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

Official document: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.