This is the 10th day of my participation in Gwen Challenge

K8s cluster regardless of all components of the cluster to add, delete, change and check, are through the API server this component, of course, the late use of API cluster operation is also through the API server this component. Because the API Server can manipulate ETCD while no other component can.

Then the security of the API server is very critical. The cluster has access control mechanisms for the API, including authentication management, and authorization management

Authentication management

authentication

  • HTTPS certificate bidirectional authentication: implements bidirectional authentication based on component certificates derived from the CA root certificate
  • HTTP token: Identifies legitimate users based on a token
  • HTTP Base: simple HTTP user name and password authentication

The user types

  • Regular users: users who use Kubectl to operate clusters
  • Service user: a user who creates an account for obtaining cluster permissions while POD is running

The following figure shows that the private key certificate used by the admin user is the apiserver component for authentication

Create a service account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
Copy the code

Check the token of the service account. Take Dashboard as an example. You can log in to the dashboard using the toekn in the output

# to check the token kubectl -n kubernetes - dashboard go in secret $(kubectl -n kubernetes - dashboard get secret | grep admin - user | awk '{print $1}')Copy the code

HTTP Base authentication means that the user name and password are encrypted using Base64 and stored in the header to be sent to the server for authentication. Many tools support this method

View users in the cluster

kubectl get user
Copy the code

View roles in the cluster

kubectl get clusterrole
Copy the code

Authorization management

Authorization way

  • Rbac authorization:
  • Abac authorization:
  • Authorization of the node
  • Webhook authorization

There are many authorization mechanisms in K8S, the above is, the more commonly used is RBAC, RBAC authorization model is very common in the management background

Role Based Access Control (RABC) implements role-based access control

Attribute Based Access Control (ABAC) Attribute based access control

Node authorizes kubelet to send requests to the API server

Webhook is HTTP callback authorization based on Web utility to facilitate access to services behind the cluster

Node and RBAC authenticators are enabled in the default configuration. You can view them in the configuration

cat /etc/kubernetes/manifests/kube-apiserver.yaml
Copy the code

node

The authenticator allows Kubelet to perform API operations, enabled by default

Read operation:

  • services
  • endpoints
  • nodes
  • pods
  • Secrets, ConfigMaps, PVCS, and poD-related persistent volumes bound to the Kubelet node

Write operation:

  • Nodes and node status (enabledNodeRestrictionAccess plugins to restrict Kubelet to modifying only its own nodes)
  • Pod and Pod status (enabledNodeRestrictionAccess plugins to restrict Kubelet to modifying only pods bound to itself)
  • The event

Authentication related operations:

  • To start the boot process based on TLS certificationsigningrequests API used in read/write permissions
  • Ability to create TokenReviews and SubjectAccessReviews for delegated authentication/authorization checks

webhook

HTTP POST requests triggered under certain conditions; Simple event notifications sent via HTTP POST

ABAC authorization

Abac defines an access control paradigm in which users are granted access by using policies that group attributes together

For use in the process of production is not much, there is not much to do, see website: kubernetes. IO/useful/docs/ref…

This section focuses on RBAC

RBAC authorization

Role-based authorization models are widely used in environments such as storage in the previous chapter when creating NFS SCS

And rbac authentication is enabled by default, it comes from the mechanism of rbac. The authorization. K8s. IO API objects

API objects

The RBAC API declares four types of Kubernetes objects: Role, ClusterRole, Rolebinding, and ClusterRoleBinding

You can manipulate these objects using the Kubectl tool

The Role and ClusterRole

An RBAC Role or ClusterRole contains a set of rules that represent related permissions. These permissions are purely cumulative (there is no rule to reject an operation).

Role must correspond to a namespace

ClusterRole is a cluster-scoped resource. The two resource names are different (Role and ClusterRole) because Kubernetes objects are either namespace scoped or cluster scoped, not both.

ClusterRole has several uses. You can use it to:

  1. Define the access permission to a namespace domain object, and complete the authorization in each namespace.
  2. Set access permissions for objects in the namespace scope and perform authorization across all namespaces;
  3. Define access rights for cluster-scoped resources.

To define roles in namespaces, use roles; When defining cluster-wide roles, you should use ClusterRole

Role example

Has read access to the POD object in the Default namespace

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

ClusterRole example

Secret object read access to any namespace or across namespaces (depending on how the role is bound)

ApiVersion: rbac authorization. K8s. IO/v1 kind: ClusterRole metadata: # "namespace" is ignored, because ClusterRoles without being limited by the namespace name: Secret-reader: -apigroups: [""] # "" secrets" resources: ["secrets"] ["get", "watch", "list"]Copy the code

RoleBinding and ClusterRoleBinding

Role binding is the granting of role-defined permissions to one or a group of users

RoleBinding performs authorization in the specified namespace, while ClusterRoleBinding performs authorization at the cluster level

A RoleBinding can refer to any Role in the same namespace. Alternatively, a RoleBinding can refer to a ClusterRole and bind the ClusterRole to the namespace where the RoleBinding resides. If you want to bind ClusterRole to all namespaces in the cluster, you use a ClusterRoleBinding

RoleBinding example

Grant the Role in pod-reader to user “Jane” in the default namespace. This gives user “Jane” the right to read Pods from the namespace of “default”

ApiVersion: rbac authorization. K8s. IO/v1 # this role binding allows read "default" name "Jane" space of the Pods kind: RoleBinding metadata: name: Read - Pods Namespace: default subjects: # You can specify more than one "subject" - kind: User name: Jane # "name" is case insensitive apiGroup: Rbac. Authorization. K8s. IO roleRef: # "roleRef" specified binding relations with some Role or ClusterRole kind: # This field must match the name of the Role or ClusterRole to which you are binding: rbac.authorization.k8s.ioCopy the code

A RoleBinding can also reference a ClusterRole to grant access rights defined in the corresponding ClusterRole to resources in the namespace where a RoleBinding resides. This reference allows you to define a common set of roles across the entire cluster and reuse them in multiple namespaces

For example, the following RoleBinding references a ClusterRole, where “Dave” (the principal here, case insensitive) can only access Secrets objects in the “development” namespace, Because the namespace where RoleBinding is located (determined by its metadata) is “development”

apiVersion: . Rbac authorization. K8s. IO/v1 # this role binding allows the user to be able to read the "default" name "Dave" in space # Secrets you will need a ClusterRole called "secret - reader" Kind: RoleBinding metadata: name: read-secrets # RoleBinding Access permissions are only granted in the "development" namespace. Namespace: development of the subjects: - kind: User name: Dave # 'name' is a case-insensitive apiGroup:. Rbac authorization. K8s. IO roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.ioCopy the code

ClusterRoleBinding example

To grant access across the entire cluster, a ClusterRoleBinding can be used. The ClusterRoleBinding below allows all users in the “Manager” group to access Secrets in any namespace

ApiVersion: rbac authorization. K8s. IO/v1 # binding allows the cluster role "manager" in the group access to any namespace the secrets in kind: ClusterRoleBinding metadata: name: read-secrets-global subjects: - kind: Group name: Manager # 'name is case-insensitive apiGroup:. Rbac authorization. K8s. IO roleRef: kind: ClusterRole name: secret - reader apiGroup: rbac.authorization.k8s.ioCopy the code

After a binding is created, you cannot modify the roles or ClusterRoles referenced by the binding object. Attempting to change the roleRef of a bound object will result in a validity check error. If you want to change the contents of the roleRef field in an existing binding object, you must delete and recreate the binding object.

There are two main reasons for this limitation:

  1. Bindings for different roles are completely different bindings. Requires changes by deleting/rebuilding bindingsroleRefThis ensures that all principals to be bound will be granted new roles (instead of allowing changes)roleRefCauses all existing principals to be granted permissions corresponding to the new role without verification).
  2. willroleRefSet to unchangeable, which makes it possible to grant users access to existing bound objectsupdatePermissions that allow them to manage the list of principals without changing the roles granted to those principals.

The kubectl auth Reconcile command can create or update the manifest file containing the RBAC objects and, if necessary, delete and recreate the binding objects to change the referenced roles

* Note that much of the content in this article comes from official documents

Reference address: kubernetes. IO/useful/docs/ref…

Access control

After passing the previous authentication and authorization, apiserver will process the request after passing the access control process. Admission Control has an Admission Control list, and we can choose which Admission controllers to implement through command line Settings. Apiserver does not execute the request until all access controllers have been checked. Otherwise, apiserver rejects the request.

Because the access controller is numerous, here are a few common brief introduction:

  • AlwaysAdmit: All requests are allowed
  • AlwaysDeny: deny all requests
  • AlwaysPullImages: Always download images before starting containers
  • ServiceAccount: Mount secret information to pod, such as ServiceAccount Token, Registry key, etc
  • ResourceQuota and LimitRanger: Implements quota control
  • SecurityContextDeny: Disallows the creation of pods with SecurityContext set

View default enabled:

kube-apiserver -h | grep enable-admission-plugins
Copy the code

If you are using kubeadm to install the cluster, you need to log into the API server container to execute the above command

Listing of all access controller: kubernetes. IO/docs/refere…

Practical example

The following uses NFS SC as an example

Create a namespace

apiVersion: v1
kind: Namespace
metadata:
  name: dmp-storage-class
Copy the code

Creating a Service Account

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  namespace: dmp-storage-class
Copy the code

Creating a Cluster Role

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "update", "patch"]
Copy the code

Binding a Cluster Role

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: dmp-storage-class
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io
Copy the code

Create the role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: dmp-storage-class
rules:
  - apiGroups: [""]
    resources: ["endpoints"]
    verbs: ["get", "list", "watch", "create", "update", "patch"]
Copy the code

Binding role

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: leader-locking-nfs-client-provisioner
  namespace: dmp-storage-class
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    namespace: dmp-storage-class
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io
Copy the code

use

Spec. Spec is defined in the Deployment controller

serviceAccountName: nfs-client-provisioner
Copy the code

The process is as follows

  1. Example Create a namespace dmp-storage-class

  2. Create a ServiceAccount nfs-client-provisioner in the namespace

  3. Create cluster roles for which you can add, delete, modify, and query rights for pv, PVC, SC, and Event

  4. Bind the cluster role to the service account nfs-client-provisioner

  5. Create a role for endPoints

  6. Bind the role to the service account nfs-client-provisioner

  7. Adding serviceAccountName to an object controller allows the object to have these rights

Security tools

Although API Server has many options for authentication and authorization, there are some security AIDS that are good

kube-bench

Kube-bench is a tool to check that Kubernetes is safely deployed by running checks recorded in CIS Kubernetes Benchmark

Github.com/aquasecurit…

Popeye

Popeye is a utility that scans real-time Kubernetes clusters and reports potential problems with deployed resources and configurations

Github.com/derailed/po…