• Access Control Overview
    • User account and service account
    • User groups
    • certification
    • authorization
  • Manage and apply the Service Account
    • Service Account Automation
    • Creating a Service Account
    • Call the imagePullSecret resource object
  • RBAC: role-based access control
    • The Role and RoleBinding
    • ClusterRole and ClusterRoleBinding
  • Access controller
    • LimitRanger Access controller
    • ResourceQuota Resources and access controllers

Access Control Overview

As the gateway of Kubernetes cluster system, API Server is the only entrance to access and manage resource objects, and all other components that need to access cluster resources. Cluster basic components including Kube-controller-manager, Kube-Scheduler, kubelet and kube-proxy, cluster add-ons such as CoreDNS, and previously used kubectl commands are accessed and managed through this gateway. The API Server checks the validity of each access request, including user identification, operation permission verification, and whether the operation complies with global specifications. Kubernetes authenticates and authorizes requests by means of plug-ins: identifies clients through authentication plug-ins; Then through one or more authorization plug-ins to check whether the user has the permission to execute the resource operation request; Finally, one or more access control plug-ins are traversed to check whether the target Namespace resource object exists or violates system resource limits.

User account and service account

The information about the user and the group that the authentication plug-in extracts from the client request is not saved; it is only used to verify that the user has permission to perform the requested action. There are usually three ways for clients to access API services: Kubectl, client libraries, or directly using REST interfaces to make requests, and the principals that can perform such requests are divided into two categories by Kubernetes:

  • Pod object, corresponding to Service Account, refers to the Account managed by Kubernetes API, used to provide the identity for the Service process in Pod when accessing Kubernetes API. Service Accounts are usually bound to specific namespaces, which are created by the API Server, or manually created through API calls, along with a set of credentials stored as Secret for accessing the API Server.
  • An operator, as User Account, is a User Account managed by a service separate from Kubernetes, such as a key distributed by an administrator.

User groups

The User Account is used for manual manipulation and is used globally. Its name must be globally unique. A Service Account belongs to a namespace and is used only for specific operational tasks. It is lighter. Both types of accounts can belong to one or more user groups. A user group is a logical collection of user accounts and does not have operation rights. However, the rights attached to a user group can be inherited by all internal users to achieve efficient authorization management. Kubernetes has some special purpose groups built in:

  • System :unauthenticated: an account that fails to pass the authentication test of any authorized plug-in. That is, the group to which the user belongs. ‰
  • System :authenticated :a group that users are automatically added to after successful authentication and can quickly reference all authenticated user accounts. ‰
  • System: ServiceAccounts, all ServiceAccount objects on the current system.
  • System: ServiceAccounts :(Namespace) All Service Account objects in a specific namespace.

certification

The authentication plug-in is responsible for the authentication of API requests. It supports client certificates, bearer tokens, authenticating proxy, HTTP Basic authentication, etc. When the API Server receives an access request, it invokes the authentication plug-in to try to extract the following information:

  • Username: indicates the Username, such as kubernetes-admin. ‰
  • UID: A user’s numeric label used to ensure unique user identity. ‰
  • Groups: indicates the group to which a user belongs. It is used for permission assignment and inheritance. ‰
  • Extra: a string of key-value data type used to provide additional information for authentication.

The API Server supports multiple authentication mechanisms at the same time, but at least one authentication plug-in should be enabled for the ServiceAccount and User Account respectively. When multiple authentication mechanisms are enabled at the same time, the authentication process is executed in serial mode until one authentication mechanism is successfully completed.

authorization

After successful authentication, the operation request needs to be forwarded to the authorization plug-in for permission check to ensure that it has the permission to perform the corresponding operation. Four types of built-in authorization plug-ins are supported:

  • Node: Access control to Kubelet based on the target scheduling Node of Pod resource. ‰
  • ABAC:attribute-based access control. ‰
  • RBAC:role-based access control. ‰
  • Webhook: Access control that verifies user authorization through external REST service checks based on HTTP callback mechanisms.

There are also two special authorization plug-ins, AlwaysDeny and AlwaysAllow, where AlwaysDeny is only used for testing and AlwaysAllow is used to turn off authorization checking.

Manage and apply the Service Account

The API Server is a unique entry point for accessing and managing resource objects and validates each access request. Each Pod object corresponds to a ServiceAccount. If the Pod resource is not specified when it is created, the access controller named ServiceAccount will automatically attach the default ServiceAccount in the current namespace to it, which is usually named default:

Those who qualify kubectl describe serviceAccount Default Namespace: Default... Mountable secrets: default-token-m6bz5 Tokens: default-token-m6bz5Copy the code

Pod storage volume mount ways to use these information, location at/var/run/secrets/kubernetes. IO/serviceaccount

Those who qualify kubectl describe pod configmap-vol... Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-m6bz5 (ro) ... Volumes: default-token-m6bz5: Type: Secret (a volume populated by a Secret) SecretName: default-token-m6bz5 Optional: falseCopy the code

The mount point directory contains three files: CRT, Namespace, and Token. The token file stores the authentication token of the Service Account. Processes in the container use the token to initiate connection requests to the API Server, and then the authentication plug-in completes user authentication and passes the user name to the authorization plug-in.

Service Account Automation

The Kubernetes system automates Service accounts by cooperating with three independent components: Service Account access controller, Token Controller, and Service Account Account Controller. ServiceAccount The ServiceAccount controller manages resources for the namespace and ensures that each namespace has a ServiceAccount object named Default. The ServiceAccount Access Controller is a part of the API Server. It modifies the ServiceAccount object when a Pod is created or updated. The operations are as follows:

  • If Pod does not explicitly define the ServiceAccount object to use, set it to “default”
  • Ensure that the ServiceAccount explicitly referenced by Pod already exists, otherwise the request will be rejected
  • If the Pod object does not contain ImagePullSecerts, add the ImagePullSecrets of ServiceAccount to it
  • Add a storage volume for a Pod with a token to access the API
  • For Pod object in each container, add a volumeMounts mounted to/var/run/secrets/kubernetes. IO/serviceaccount

The token controller is a child of controller-Manager and works in asynchronous mode. Its mission is: ‰

  • Monitor the creation of the Service Account and add a Secret object for it to access the API
  • Monitor Service Account deletion and delete all Service Account token keys associated with it
  • Monitor the addition of Secret objects, ensure that the Service Account they reference already exists, and add authentication tokens to Secret objects if necessary
  • Monitor the deletion of Secret objects to ensure that references to this Secret are removed from each ServiceAccount.

Creating a Service Account

Service Account is a resource type on the Kubernetes API. It belongs to a namespace. Each namespace has a default resource object named default. Kubectl get serviceaccounts –all-namespaces Each Pod object can attach only one Service Account resource in its namespace, but a Service Account resource can be shared by multiple Pod objects. When creating a Pod resource, you can use the spec.serviceAccountName attribute to specify the Service Account object to be used. If the attribute is omitted, the default resource object is used. The following configuration list creates a service account named sa-demo, and the rest of the information is automatically generated by the system, including the Secret object for the authentication token:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-demo
Copy the code

Call the imagePullSecret resource object

The ServiceAccount resource can also come with a list of Docker-Registry resources based on the spec.imagepullSecret field for service authentication before downloading an image file from a private image repository during container creation. For example, the following listing specifies the local-registry created in Kubernetes Notes (8) -configmap and Secret:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: sa-demo
imagePullSecrets:
- name: local-registry
Copy the code

RBAC: role-based access control

In THE RBAC access control mechanism, a User is a principal that can independently access data in a computer system or other resources represented by data. Role refers to the job or position in an organization or task. It represents a kind of right, qualification and responsibility. Permission is the operation that is allowed to be performed. The RBAC authorization plug-in used by K8s supports two types of roles: Role and ClusterRole. Role acts at the namespace level and is used to define the set of resource permissions within the namespace, while ClusterRole is used to organize the set of resource permissions at the cluster level. Both of them are standard API resource types.

The Role and RoleBinding

A Role is simply a collection of permissions that describes which operations can be performed on which resources. The rules field is used to nest authorization rules in the resource configuration manifest. The following example of a Role object configuration manifest sets permissions to read, list, and monitor Pod objects:

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

No namespace is specified. By default, the namespace is created in default. Role can take effect only after role-binding to the principal (such as user, group, or service Account). RoleBinding is used to assign permissions defined in roles to one or a group of users. It consists of a set of principals and a Role or ClusterRole that is referenced to assign permissions to this set of principals. For example, the following RoleBinding configuration listing assigns the Pods-reader role to user kube-user1, so that kube-user1 has the corresponding permissions:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: role-binding-1
subjects:
- kind: User
  name: kube-user1
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pods-reader
  apiGroup: rbac.authorization.k8s.io  
Copy the code

ClusterRole and ClusterRoleBinding

ClusterRole licensing applies to the entire cluster and is often used to control resource types for which a Role does not take effect. This includes cluster-level resources (such as Nodes), endpoints of non-resource types (such as /healthz), and resources that apply to all namespaces (for example, access to any resource across namespaces). ClusterRole Resource In addition to managing the same permissions as Role resources, ClusterRole resources can also be used to authorize cluster-level components. The configuration method and the fields that can be embedded in the Rules field are similar to Role resources. Kind is ClusterRole. For namespace-level resources, RoleBinding can also bind principals to ClusterRole resources. However, RoleBinding can only give users ClusterRole access to the namespace in which the role-Binding resource resides. With ClusterRoleBinding, the user has access to all resources in the associated namespaces. However, for non-namespace resources, such as Nodes, PersistentVolumes, and non-resource urls (/ API, /apis, /healthz, / SwaggerAPI, and /version), The RoleBinding cannot be used to authorize the user. They can also only be defined in clusterRoles and require authorization based on a ClusterRoleBinding. However, the read permissions for these resources are automatically set by the system default ClusterRole and ClusterRoleBinding resources named System: Discovery. Kubectl get ClusterRole System :discovery -o yaml kubectl get ClusterRole System :discovery -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:discovery
  ...
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /livez
  - /openapi
  - /openapi/*
  - /readyz
  - /version
  - /version/
  verbs:
  - get
Copy the code

Access controller

After the authentication and permission checks are completed, further validation is performed by the access controller, such as performing semantic validation of the object, setting default values for missing fields, limiting image files used by all containers to come from a particular Registry, and checking whether the resource requirements of the Pod object are beyond the specified limits. Access controller is divided into Mutating – AdmissionWebhook and ValidatingAdmissionWebhook two types, respectively used to perform object configuration in the API “variation” and “verification” operation. Variation controllers can modify their licensed objects, whereas validation controllers generally do not. In the specific code implementation, an access controller can be both verification, mutation two functions. Access control can be divided into two stages at run time. The first stage runs each variant controller in sequence, and the second stage runs each verification controller in sequence. Once any controller in any stage rejects the request, the whole request will be rejected immediately and an error message will be returned to the user.

LimitRanger Access controller

LimitRange resources can be used to specify the amount of computing resources for each container in a namespace, or set default requirements and limits for computing resources. After a LimitRange object is defined, the resource object that the client submits to create or modify is checked by the LimitRanger controller. LimitRange supports system resource limits for container, Pod, and PersistentVolumeClaim resource objects. Pod and Container are used to define the range of available CPU and memory resources. Persistentvolume-claim, on the other hand, defines the limited scope of storage space. The following configuration list defines the container’s resource limits in the default space:

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
  - default:
    cpu: 1
    defaultRequest:
    cpu： 1
    max:
    cpu: 2000m
    maxLimitRequestRatio:
    cpu: 4
    type: Container
Copy the code

If no resource limit is specified when creating a Pod object, the LimitRange resource is automatically set for it, and requests that exceed the Max limit are blocked.

ResourceQuota Resources and access controllers

Although LimitRange resources can limit the amount of computing or storage resources associated with a single container, Pod, and PVC, the total amount of resources occupied by multiple objects may exceed the system limit. The ResourceQuota resource defines the number of objects in the namespace or system ResourceQuota. It limits the total number of objects of each resource type and the total number of computing and storage resources consumed by all objects. A namespace can create a ResourceQuota object. The ResourceQuota object limits the computing resource requirements and total computing resource limits for all Pod objects in a given namespace that are not in a terminated state, for example

  • Requests. CPU: indicates the total limit of CPU resource requirements
  • Requests. CPU: The total amount of memory resource requirements. ‰
  • CPU: indicates the total limit of CPU resources. ‰
  • Memory: indicates the total limit of memory resource limits.

You can also limit the number of PVCS that can be used in a particular namespace and the total space size of those PVC resources. Some examples are:

  • Persistentvolumeclaims: Total number of PVCS that can be created
  • Requests. Storage: The total limit for all PVC storage requirements

In version 1.9, count quotas are supported for all resource type objects in the count/

.

format, such as count/deployments. Apps count/services.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota-1
spec:
  hard:
    pods: 2
    requests.cpu: 500m
    requests.memory: 1Gi
    limits.cpu: 2
    limits.memory: 2Gi
    count/deployments.apps: 1
    persistentvolumeclaims: 2
Copy the code

Kubectl describe quota resource-quota-1: kubectl describe quota resource-quota-1

Name:                   resource-quota-1
Namespace:              default
Resource                Used  Hard
--------                ----  ----
count/deployments.apps  0     1
limits.cpu              0     2
limits.memory           0     2Gi
persistentvolumeclaims  1     2
pods                    4     2
requests.cpu            0     500m
requests.memory         0     1Gi
Copy the code

According to the output, the number of PODS is four before ResourceQuota is created. Therefore, new pods cannot be added after ResourceQuota is created. In addition, once computing resource requirements and computing resource limit quotas are enabled, any Pod objects created must have these two properties set or they will be blocked.

Learning materials

Kubernetes combat advanced ma Yongliang