Jugando con k8s: Certificación de seguridad

9 Capítulo 9 Certificación de seguridad

9.1 Descripción general del control de acceso

Como herramienta de gestión de clústeres distribuidos, Kubernetes garantiza la seguridad del clúster y es una tarea importante. La llamada seguridad en realidad significa garantizar las operaciones de autenticación y autorización de varios clientes de Kubernetes.

cliente

En un clúster de Kubernetes, suele haber dos tipos de clientes:

Cuenta de Usuario: Generalmente, es una cuenta de usuario administrada independientemente de otros servicios distintos a kubernetes.

Cuenta de servicio: una cuenta administrada por Kubernetes, utilizada para proporcionar identidad para el proceso de servicio en el Pod al acceder a Kubernetes.

Autenticación, autorización y control de acceso.

ApiServer es la única entrada para acceder y administrar objetos de recursos. Cualquier solicitud para acceder a ApiServer debe pasar por los siguientes tres procesos:

Autenticación: autenticación de identidad, solo la cuenta correcta puede pasar la autenticación

Autorización: determine si el usuario tiene permiso para realizar acciones específicas en los recursos a los que accede.

Control de admisión: se utiliza para complementar el mecanismo de autorización para lograr funciones de control de acceso más granulares.

9.2 Gestión de la certificación

El punto más crítico de la seguridad del clúster de Kubernetes es cómo identificar y autenticar la identidad del cliente. Proporciona 3 métodos de autenticación de identidad del cliente:

Autenticación Base HTTP: Autenticación mediante nombre de usuario + contraseña

Este método de autenticación consiste en colocar la cadena "nombre de usuario: contraseña" codificada con el algoritmo BASE64 en el campo Autorización de encabezado en la solicitud HTTP y enviarla al servidor. Después de recibirlo, el servidor lo decodifica, obtiene el nombre de usuario y la contraseña y luego realiza el proceso de autenticación de identidad del usuario.

Autenticación de token HTTP: identifique usuarios legítimos a través de un token

Este método de autenticación es una forma de indicar la identidad del cliente mediante una cadena larga y difícil de imitar: Token. Cada token corresponde a un nombre de usuario. Cuando el cliente inicia una solicitud de llamada API, debe colocar el token en el encabezado HTTP. Después de recibir el token, el servidor API lo comparará con el token guardado en el servidor y luego realizará el proceso de autenticación de la identidad del usuario.

Autenticación de certificado HTTPS: método de autenticación de certificado digital bidireccional basado en la firma del certificado raíz de CA

Este método de autenticación es el más seguro, pero también el más problemático de utilizar.

La autenticación HTTPS se divide aproximadamente en tres procesos:

Solicitud y emisión de certificado.

Los servidores en ambos lados de la comunicación HTTPS solicitan certificados de la organización CA, que emite el certificado raíz, el certificado del servidor y la clave privada al solicitante.

Autenticación bidireccional entre cliente y servidor

1> El cliente inicia una solicitud al servidor y el servidor emite su propio certificado al cliente.

Una vez que el cliente recibe el certificado, lo descifra a través de la clave privada y obtiene la clave pública del servidor en el certificado.

El cliente utiliza la información del certificado de autenticación de clave pública del servidor y, si es coherente, se reconoce el servidor.

2> El cliente envía su propio certificado al servidor, después de recibir el certificado, el servidor lo descifra a través de la clave privada.

Obtenga la clave pública del cliente en el certificado y utilice la clave pública para autenticar la información del certificado para confirmar si el cliente es legítimo.

El servidor y el cliente se comunican

Después de que el servidor y el cliente negocien el esquema de cifrado, el cliente generará una clave secreta aleatoria, la cifrará y luego la enviará al servidor.

Después de que el servidor reciba esta clave secreta, todas las comunicaciones posteriores entre las dos partes se cifrarán con esta clave secreta aleatoria.

Nota: Kubernetes permite configurar múltiples métodos de autenticación al mismo tiempo, siempre que alguno de ellos pase la autenticación.

9.3 Gestión de autorizaciones

La autorización se produce después de una autenticación exitosa. A través de la autenticación, puede saber quién es el usuario solicitante. Luego, Kubernetes determinará si el usuario tiene permiso para acceder según la política de autorización predefinida. Este proceso se llama autorización.

Cada solicitud enviada a ApiServer lleva información del usuario y del recurso: como el usuario que envió la solicitud, la ruta de la solicitud, la acción de la solicitud, etc. La autorización se basa en comparar esta información con la política de autorización. la póliza se considera autorizada. Aprobada, de lo contrario se devolverá un error.

API Server actualmente admite las siguientes estrategias de autorización:

AlwaysDeny: significa rechazar todas las solicitudes, generalmente se usa para pruebas
AlwaysAllow: permite recibir todas las solicitudes, lo que equivale a que el clúster no requiera proceso de autorización (política predeterminada de Kubernetes)
ABAC: control de acceso basado en atributos, lo que significa utilizar reglas de autorización configuradas por el usuario para hacer coincidir y controlar las solicitudes de los usuarios.
Webhook: autorizar a los usuarios llamando a servicios REST externos
Nodo: es un modo dedicado para el control de acceso de solicitudes realizadas por kubelet
RBAC: control de acceso basado en roles (opción predeterminada en el modo de instalación de kubeadm)

El control de acceso basado en roles RBAC (Control de acceso basado en roles) describe principalmente una cosa: qué permisos se otorgan a qué objetos

Se trata de los siguientes conceptos:

Objetos: Usuario, Grupos, Cuenta de Servicio
Rol: representa un conjunto de acciones operables (permisos) definidas en un recurso
Vinculación: vincula el rol definido al usuario

RBAC presenta 4 objetos de recursos de nivel superior:

Rol, ClusterRole: rol, utilizado para especificar un conjunto de permisos
RoleBinding, ClusterRoleBinding: enlace de roles, utilizado para asignar roles (permisos) a objetos

Rol、ClústerRole

Un rol es un conjunto de permisos, y los permisos aquí están en forma de permisos (lista blanca).

# Role只能对命名空间内的资源进行授权，需要指定nameapce
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: authorization-role
rules:
- apiGroups: [""]  # 支持的API组列表,"" 空字符串，表示核心API群
  resources: ["pods"] # 支持的资源对象列表
  verbs: ["get", "watch", "list"] # 允许的对资源对象的操作方法列表

# ClusterRole可以对集群范围内资源、跨namespaces的范围资源、非资源类型进行授权
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Lo que hay que explicar en detalle son los parámetros en las reglas:

apiGroups: lista de grupos de API compatibles

"","aplicaciones", "escalado automático", "lotes"

recursos: lista de objetos de recursos soportados

"servicios", "puntos finales", "pods", "secretos", mapas de configuración, "crontabs", "implementaciones", "trabajos", "nodos", "rolebindings", "clusterroles", "daemonsets", "replicasets
" ","statefulsets",
"horizontalpodautoscalers","replicationcontrollers","cronjobs"

verbos: lista de métodos de operación en objetos de recursos

"obtener", "listar", "ver", "crear", "actualizar", "parchear", "eliminar", "ejecutar"

Enlace de roles、ClusterRoleBinding

La vinculación de roles se utiliza para vincular una función a un objeto de destino. El objetivo de vinculación puede ser Usuario, Grupo o Cuenta de servicio.

# RoleBinding可以将同一namespace中的subject绑定到某个Role下，则此subject即具有该Role定义的权限
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: authorization-role
  apiGroup: rbac.authorization.k8s.io

# ClusterRoleBinding在整个集群级别和所有namespaces将特定的subject与ClusterRole绑定，授予权限
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
 name: authorization-clusterrole-binding
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

RoleBinding hace referencia a ClusterRole para autorización

RoleBinding puede hacer referencia a ClusterRole para autorizar sujetos de recursos que pertenecen a la definición de ClusterRole en el mismo espacio de nombres.

Una práctica muy común es que los administradores de clústeres predefinan un conjunto de roles para todo el clúster (ClusterRole) y luego reutilicen estos ClusterRole en múltiples espacios de nombres. Esto puede mejorar en gran medida la eficiencia de la gestión de autorizaciones y hacer que las reglas de autorización básicas y la experiencia del usuario sean consistentes en cada espacio de nombres.

# 虽然authorization-clusterrole是一个集群角色，但是因为使用了RoleBinding
# 所以heima只能读取dev命名空间中的资源
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding-ns
  namespace: dev
subjects:
- kind: User
  name: heima
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: authorization-clusterrole
  apiGroup: rbac.authorization.k8s.io

Combate práctico: cree una cuenta que solo pueda administrar los recursos de Pods en el espacio de desarrollo

1) Crea una cuenta

# 1) 创建证书
[root@k8s-master01 pki]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# (umask 077;openssl genrsa -out devman.key 2048)

# 2) 用apiserver的证书去签署
# 2-1) 签名申请，申请的用户是devman,组是devgroup
[root@k8s-master01 pki]# openssl req -new -key devman.key -out devman.csr -subj "/CN=devman/O=devgroup"     
# 2-2) 签署证书
[root@k8s-master01 pki]# openssl x509 -req -in devman.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out devman.crt -days 3650

# 3) 设置集群、用户、上下文信息
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --embed-certs=true --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.109.100:6443

[root@k8s-master01 pki]# kubectl config set-credentials devman --embed-certs=true --client-certificate=/etc/kubernetes/pki/devman.crt --client-key=/etc/kubernetes/pki/devman.key

[root@k8s-master01 pki]# kubectl config set-context devman@kubernetes --cluster=kubernetes --user=devman

# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 查看dev下pod，发现没有权限
[root@k8s-master01 pki]# kubectl get pods -n dev
Error from server (Forbidden): pods is forbidden: User "devman" cannot list resource "pods" in API group "" in the namespace "dev"

# 切换到admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

2) Cree Role y RoleBinding, y autorice al usuario devman

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: dev
  name: dev-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
---

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: authorization-role-binding
  namespace: dev
subjects:
- kind: User
  name: devman
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-role
  apiGroup: rbac.authorization.k8s.io

[root@k8s-master01 pki]# kubectl create -f dev-role.yaml
role.rbac.authorization.k8s.io/dev-role created
rolebinding.rbac.authorization.k8s.io/authorization-role-binding created

3) Cambie de cuenta y verifique nuevamente

# 切换账户到devman
[root@k8s-master01 pki]# kubectl config use-context devman@kubernetes
Switched to context "devman@kubernetes".

# 再次查看
[root@k8s-master01 pki]# kubectl get pods -n dev
NAME                                 READY   STATUS             RESTARTS   AGE
nginx-deployment-66cb59b984-8wp2k    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-dc46j    1/1     Running            0          4d1h
nginx-deployment-66cb59b984-thfck    1/1     Running            0          4d1h

# 为了不影响后面的学习,切回admin账户
[root@k8s-master01 pki]# kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".

9.4 Control de admisión

Después de pasar la autenticación y autorización previas, el apiserver procesará la solicitud solo después de pasar el proceso de control de acceso.

El control de admisión es una lista configurable de controladores, y usted puede elegir qué controladores de admisión ejecutar a través de la configuración de la línea de comandos en Api-Server:

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,
                      DefaultStorageClass,ResourceQuota,DefaultTolerationSeconds

Solo cuando todos los controladores de admisión pasen la verificación, el apiserver ejecutará la solicitud; de lo contrario, la rechazará.

Los controles de admisión actualmente configurables del Control de Admisión son los siguientes:

AlwaysAdmit: permitir todas las solicitudes
AlwaysDeny: prohíbe todas las solicitudes, generalmente se usa para pruebas
AlwaysPullImages: descargue siempre la imagen antes de iniciar el contenedor
DenyExecOnPrivileged: interceptará todas las solicitudes para ejecutar comandos en el contenedor privilegiado.
ImagePolicyWebhook: este complemento permitirá que un programa Webhook en el backend complete la función del controlador de admisión.
Cuenta de servicio: implementación de ServiceAccount para lograr la automatización
SecurityContextDeny: este complemento invalidará todas las definiciones en Pods que usan SecurityContext
ResourceQuota: se utiliza para fines de gestión de cuotas de recursos, observando todas las solicitudes para garantizar que la cuota en el espacio de nombres no exceda el estándar.
LimitRanger: se utiliza para la gestión de límites de recursos y actúa sobre el espacio de nombres para garantizar los límites de recursos para los Pods.
Recursos iniciales: para los pods que no han establecido solicitudes ni restricciones de recursos, se configuran en función del uso histórico de recursos de sus espejos.
NamespaceLifecycle: si intenta crear un objeto de recurso en un espacio de nombres que no existe, la solicitud de creación será rechazada. Cuando se elimina un espacio de nombres, el sistema eliminará todos los objetos del espacio de nombres.
DefaultStorageClass: para lograr el suministro dinámico de almacenamiento compartido, intente hacer coincidir la StorageClass predeterminada para PVC que no especifican StorageClass o PV, minimizando los detalles de almacenamiento back-end que los usuarios necesitan saber al solicitar PVC.
DefaultTolerationSeconds: este complemento establece el tiempo de "tolerancia" predeterminado para los pods que no tienen tolerancias de perdón configuradas y tienen dos taints: notready:NoExecute e inalcanzable:NoExecute, que es de 5 minutos.
PodSecurityPolicy: este complemento se utiliza para decidir si controlar la política de seguridad del Pod en función del contexto de seguridad del Pod y la PodSecurityPolicy disponible al crear o modificar un Pod.