Seguridad del clúster de Kubernetes

1. Descripción del mecanismo

Como herramienta de administración para clústeres distribuidos, Kubernetes es una tarea importante para garantizar la seguridad del clúster. El servidor API es el intermediario para la comunicación entre los distintos componentes del clúster y la entrada al control externo. Por lo tanto, el mecanismo de seguridad de Kubernetes está básicamente diseñado para proteger el servidor API. Kubernetes utiliza autenticación (Autenticación), autorización (Autorización), control de admisión (Control de admisión) tres pasos para garantizar la seguridad del servidor API

Dos, autenticación (autenticación)

2.1 Método de autenticación

• Autenticación HTTP Token: Identifique a los usuarios legítimos a través de un Token
  La autenticación HTTP Token es una forma de expresar a los clientes con un método de codificación especial largo y un Token de cadena que es difícil de imitar. El token es una cadena muy larga y compleja, cada token corresponde a un nombre de usuario y se almacena en un archivo accesible por API Server . Cuando el cliente inicia una solicitud de llamada a la API, debe colocar el token en el encabezado HTTP
• Autenticación Base HTTP: autenticar el nombre de usuario mediante el método username + contraseña
  : la contraseña se codifica con el algoritmo BASE64 y se envía al servidor en el campo HeatherAuthorization en la Solicitud HTTP. El servidor recibe la codificación y obtiene el nombre de usuario. Y contraseña
• Autenticación de certificado HTTPS: método de autenticación de identidad del cliente basado en la firma del certificado raíz de CA (autenticación bidireccional) —— Básicamente se utiliza comúnmente ❤

flujo de trabajo de cifrado de certificados htps

1. El primer paso del cifrado del certificado https es autenticar el servidor.
   Algunos navegadores convencionales tendrán una lista integrada de instituciones CA confiables y guardarán los certificados https de las instituciones CA relevantes. Cuando un usuario visita un sitio web donde se implementa un certificado https, el servidor proporcionará un certificado https emitido por una CA. Si la CA que certifica el certificado del servidor está en la lista de CA de confianza del navegador y el certificado https es Toda la información es consistente con toda la información del sitio web visitado por el certificado actual, luego el navegador considerará que el servidor es confiable y obtendrá la clave pública (es decir, el archivo CSR) del certificado https para usar en el proceso posterior.

2. El segundo paso del cifrado del certificado https es negociar la clave de sesión.
   Una vez que el servidor se ha autenticado y obtenido la clave pública, utiliza la clave pública para realizar una comunicación cifrada con el servidor y negocia dos claves de sesión, que se utilizan para cifrar las claves de sesión cuando el cliente y el servidor de cifrado intercambian datos. Esta clave secreta se genera aleatoriamente y el resultado de cada negociación es diferente, por lo que la seguridad es relativamente alta.

3. El tercer paso del cifrado del certificado https es la transmisión cifrada.
   Una vez que tanto el cliente como el servidor tienen la clave de sesión negociada, la transmisión de datos se lleva a cabo en texto cifrado. Este método de transmisión garantiza la privacidad e integridad de los datos, y no hay necesidad de preocuparse por el robo y manipulación de los datos por parte de un tercero durante la transmisión.

1. El cliente inicia una solicitud HTTPS
2. Configuración del
   servidor El servidor que utiliza el protocolo HTTPS debe tener un conjunto de certificados digitales, que pueden ser de creación propia o certificados CA. La diferencia es que el cliente debe verificar el certificado autoemitido antes de que pueda continuar accediendo a él, mientras que el uso del certificado CA no mostrará una página emergente. Este conjunto de certificados es en realidad un par de claves públicas y privadas. Otros utilizan la clave pública para el cifrado y usted mismo utiliza la clave privada para el descifrado.
3. El servidor envía el certificado.
   Este certificado es en realidad una clave pública, pero contiene mucha información, como la autoridad emisora ​​y la fecha de vencimiento del certificado.
4. Cliente analizando el certificado
   Esta parte del trabajo la realiza el TLS del cliente. Primero, verificará si la clave pública es válida, como la autoridad emisora, la hora de vencimiento, etc. Si se encuentra una anomalía, aparecerá un cuadro de advertencia que indica que hay un problema con el certificado. Si no hay ningún problema con el certificado, genere un valor aleatorio y luego utilice el certificado para cifrar el valor aleatorio.
5. El cliente transmite la información del certificado encriptado.
   Esta parte de la transmisión es el valor aleatorio encriptado con el certificado, el propósito es permitir que el servidor obtenga este valor aleatorio, y la comunicación entre el cliente y el servidor se puede encriptar y desencriptar a través de este valor aleatorio.
6. El servidor descifra la información del certificado,
   después de que el servidor lo descifra con la clave privada, obtiene el valor aleatorio (clave privada) que le ha pasado el cliente y luego cifra el contenido simétricamente con este valor. El llamado cifrado simétrico consiste en mezclar la información y la clave privada a través de un determinado algoritmo, de modo que a menos que se conozca la clave privada, no se pueda obtener el contenido, y sucede que tanto el cliente como el servidor conocen la clave privada, siempre y cuando el algoritmo de cifrado sea lo suficientemente fuerte, La clave privada es lo suficientemente compleja y los datos son lo suficientemente seguros.
7. Transmisión de información encriptada
   Esta parte de la información es la información encriptada por la clave privada de la sección de servicio, que se puede restaurar en el cliente.
8. El cliente descifra la información, el
   cliente descifra la información transmitida por el segmento de servicio con la clave privada generada previamente y luego obtiene el contenido descifrado.
   PD: Durante todo el proceso de negociación, incluso si el tercero supervisa los datos, no puede hacer nada.

2.2 Necesidad de autenticar nodos

Dos tipos

• Acceso de componentes de Kubenetes al servidor API: kubectl, Controller Manager, Scheduler, kubelet, kube-proxy

• Acceso al contenedor desde el Pod administrado por Kubenetes: Pod (dashborad también se ejecuta como un Pod)

Instrucciones de seguridad:

• Controller Manager, Scheduler y API Server están en la misma máquina, así que use directamente el puerto no seguro del API Server para acceder, –insecure-bind-address = 127.0.0.1
• kubectl, kubelet y kube-proxy necesitan certificados para la autenticación bidireccional HTTPS para acceder al servidor API

Emisión de certificados:

• Emisión manual: el certificado HTTPS se emite a través del clúster K8S y CA
• Emisión automática: cuando Kubelet accede al servidor API por primera vez, el token se utiliza para la autenticación. Después de pasar, Controller Manager generará un certificado para kubelet. Todas las visitas posteriores utilizarán el certificado para la autenticación.

2.3 kubeconfig

El archivo kubeconfig contiene parámetros del clúster (certificado de CA, dirección del servidor API), parámetros del cliente (el certificado y la clave privada generados anteriormente) e información de contexto del clúster (nombre del clúster, nombre de usuario). El componente de Kubenetes se puede cambiar especificando un archivo kubeconfig diferente al inicio Diferentes grupos.

configuración cat cd ~ / .kube

2.4 Cuenta de servicio

El contenedor en el Pod accede al servidor API. Dado que la creación y destrucción de pods son dinámicas, no es posible generar manualmente un certificado para él. Kubenetes usa la cuenta de servicio para resolver el problema de autenticación del Pod que accede al servidor API

2.5 La relación entre Secret y SA

K8S diseñó un objeto de recurso llamado Secret, que se divide en dos categorías, una es token de cuenta de servicio para ServiceAccount y la otra es Opaque para almacenar información confidencial definida por el usuario. Hay tres partes que se utilizan en ServiceAccount: Token, ca.crt y espacio de nombres.

• token: JWT (token web Json, un estándar abierto basado en JSON) firmado con la clave privada del servidor API. Cuando se usa para acceder al servidor API, autenticación del lado del servidor
• ca.crt: certificado raíz, utilizado por el cliente para verificar el certificado enviado por el servidor API
• espacio de nombres: identifica el espacio de nombre de dominio del token de cuenta de servicio

kubectl get secret --all-namespaces
kubectl describe secret default-token-5gm9r --namespace=kube-system
kubectl get pod -n kube-system
kubectl exec kube-proxy-fb85x -n kube-system -it -- /bin/sh
# ls /run/secrets/kubernetes.io/serviceaccount

默认情况下，每个namespace都会有一个ServiceAccount，如果Pod在创建时没有指定ServiceAccount,
就会使用Pod所需的enamespace的ServiceAccount
默认挂载目录：/run/secrets/kubernetes.io/serviceaccount

 

Tres, autorización (autenticación)

El proceso de autenticación anterior solo confirma que ambas partes en comunicación han confirmado que la otra parte es creíble y puede comunicarse entre sí. Y la autenticación es para determinar qué recursos tiene la parte solicitante. API Server admite actualmente las siguientes estrategias de autorización (establecidas por el parámetro de inicio –modo de autorización de API Server)

• AlwaysDeny: indica que todas las solicitudes son rechazadas, generalmente se usan para pruebas
• AlwaysAllow: permite que se reciban todas las solicitudes. Si el clúster no requiere un proceso de autorización, puede usar esta estrategia
• ABAC (Control de acceso basado en atributos): control de acceso basado en atributos, lo que significa usar reglas de autorización configuradas por el usuario para hacer coincidir y controlar las solicitudes del usuario. (Es necesario reiniciar el servidor API para que surta efecto)
• Libro web: autorice a los usuarios llamando a servicios REST externos
• RBAC (Control de acceso basado en roles): control de acceso basado en roles, las reglas predeterminadas actuales

3.1 Modo de autorización RBAC❤

El control de acceso basado en roles RBAC (Control de acceso basado en roles) se introdujo en Kubernetes 1.5 y la versión actual se ha convertido en el estándar predeterminado. En comparación con otros métodos de control de acceso, tiene las siguientes ventajas:

• Cobertura total de recursos (como implementación, pod, cpu) y no recursos (como el estado del pod) en el clúster
• Todo el RBAC se completa completamente con varios objetos API. Al igual que otros objetos API, se puede operar con kubectl o API
• Se puede ajustar en tiempo de ejecución sin reiniciar el servidor API

1. Descripción del objeto de recurso de la API de
RBAC RBAC ha introducido 4 nuevos objetos de recurso de nivel superior: Role, ClusterRole, RoleBinding, ClusterRoleBinding. Los 4 tipos de objetos se pueden operar en

componentes de Kubenetes (kubectl, kube-proxy) u otros a través de kubectl y API Cuando un usuario definido por el usuario solicita un certificado de la CA, debe proporcionar un archivo de solicitud de certificado (los usuarios y los grupos se definen aquí):

{
    
    
	"CN": "admin", # 用户名
	"hosts": [],
	"key": {
    
    
		"algo": "rsa",
		"size": 2048
	},
	"names": [{
    
    
		"C": "CN",
		"ST": "HangZhou",
		"L": "XS",
		"O": "system:masters",  # O就是组织
		"OU": "System"
	}]
}

El servidor API considerará el campo CN del certificado de cliente como Usuario y el campo names.O como Grupo;

Cuando kubelet usa la autenticación de arranque TLS, el servidor API puede usar Bootstrap Tokens o el archivo de autenticación Token para verificar el token. No importa cuál, Kubenetes vinculará un usuario y grupo predeterminados al token;

Cuando el Pod usa ServiceAccount para la autenticación, el JWT en el token de la cuenta de servicio guardará la información del usuario;

Con la información del usuario, cree un par de objetos de recursos de vinculación de rol / rol (rol de clúster / rol de clúster) para completar el enlace de permisos

3.2 Rol y ClusterRole

En la API de RBAC, el rol representa un conjunto de permisos de reglas y los permisos solo aumentarán (los permisos adicionales, la configuración indica lo que se puede hacer, pero no lo que no se puede configurar) . No hay ningún recurso que tenga muchos permisos al principio, pero se reduce a través de RBAC Operación; el rol se puede definir en un espacio de nombres, si desea cruzar el espacio de nombres, puede crear un ClusterRole.

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

ClusterRole tiene la misma autoridad y capacidades de control de roles que Role. La diferencia es que ClusterRole está en el nivel de clúster. ClusterRole se puede usar para:

• Control de recursos a nivel de clúster (como permisos de acceso a nodos)
• Puntos finales sin recursos (por ejemplo, acceso / healthz)
• Todo el control de recursos del espacio de nombres (por ejemplo, pods)

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get","watch","list"]

3.3 RoleBinding y ClusterRoleBinding

RoloBinding puede otorgar los permisos definidos en el rol a usuarios o grupos de usuarios. RoleBinding contiene un conjunto de listas de permisos (sujetos), que contiene diferentes tipos de permisos para recibir tipos de recursos ** (usuarios, grupos, cuentas de servicio); ** RoloBinding también contiene una referencia al rol que se está vinculando; RoleBinding es adecuado para la autorización dentro de un determinado espacio de nombres y ClusterRoleBinding es adecuado para la autorización de todo el clúster.

pod-readerOtorgue el rol del espacio de nombres predeterminado al usuario jane, y luego pod-readerlos permisos que el usuario jane tendrá en el espacio de nombres predeterminado :

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:  
  name: read-pods 
  namespace: default
subjects:
- kind: User  
  name: jane  
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: Role  
  name: pod-reader  
  apiGroup: rbac.authorization.k8s.io

RoleBinding también puede hacer referencia a ClusterRole para autorizar usuarios, grupos de usuarios o ServiceAccounts en el espacio de nombres actual. Esta operación permite a los administradores del clúster definir algunos ClusterRoles comunes en todo el clúster y luego usar RoleBinding para hacer referencia en diferentes espacios de nombres.

Por ejemplo, el siguiente RoleBinding hace referencia a un ClusterRole, que tiene acceso a secretos en todo el clúster; pero su usuario autorizado Dave solo puede acceder a secretos en el espacio de desarrollo (porque el RoleBinding se define en el espacio de nombres de desarrollo)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development
subjects:
- kind: User  
  name: dave  
  apiGroup: rbac.authorization.k8s.io
roleRef:  
  kind: ClusterRole  
  name: secret-reader  
  apiGroup: rbac.authorization.k8s.io

Utilice ClusterRoleBinding para autorizar todos los permisos de recursos de espacio de nombres en todo el clúster; el siguiente ejemplo de ClusterRoleBinding muestra que todos los usuarios del grupo de administradores están autorizados a acceder a secretos en todos los espacios de nombres:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
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.io

3.4 Recursos

Algunos recursos en un clúster de Kubernetes generalmente se representan por sus cadenas de nombre. Estas cadenas generalmente aparecen en la dirección URL de la API; al mismo tiempo, algunos recursos también contendrán sub-recursos. Por ejemplo, el recurso de registros es un sub-recurso de pods y la URL en la API Por ejemplo: GET / api / v1 / namespaces / {namespace} / pods / {name} / log

Si desea controlar los permisos de acceso de estos sub-recursos en el modelo de autorización de RBAC, puede usar el delimitador / para lograrlo. A continuación, se muestra una definición de función de muestra que define los permisos de acceso de los registros de recursos de pods.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:  
  namespace: default 
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]  
  resources: ["pods/log"]  # 仅仅只能看pod的日志信息
  verbs: ["get","list"] # 动作类型，获取和列出

3.5 a sujetos

RoleBinding y ClusterRoleBinding pueden vincular roles a sujetos; los sujetos pueden ser grupos, usuarios o cuentas de servicio.

Los usuarios en Temas están representados por cadenas, pero el sistema reserva el sistema de prefijo: de Usuarios El administrador del clúster debe asegurarse de que los usuarios normales no utilicen este formato de prefijo.

Los grupos reciben el mismo nombre que los usuarios. Todos son una cadena y no hay un requisito de formato específico; el mismo prefijo del sistema está reservado para el sistema

 

★ Cuatro, crear usuarios y autorización

Ejemplo: crear un usuario solo puede administrar el espacio de desarrollo

#创建用户
[root@k8s-master01 ~]# useradd devuser
[root@k8s-master01 ~]# passwd devuser


# 创建命名空间
[root@k8s-master01 ~]# kubectl create namespace dev
namespace/dev created

#创建证书请求文件，即指定用户
[root@k8s-master01 ~]# mkdir -p /usr/local/install-k8s/cert/devuser
[root@k8s-master01 ~]# cd /usr/local/install-k8s/cert/devuser
[root@k8s-master01 devuser]# vim devuser-csr.json
{
    
    
	"CN": "devuser",
	"hosts": [], # 可以使用主机，不写代表所有
	"key": {
    
    
		"algo": "rsa", # rsa算法
		"size": 2048
	},
	"names": [{
    
    
		"C": "CN",
		"ST": "BeiJing",
		"L": "BeiJing",
		"O": "k8s", # 组名
		"OU": "System"
	}]
}

#下载证书生成工具
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
mv cfssl_linux-amd64 /usr/local/bin/cfssl

wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
mv cfssl-certinfo_linux-amd64 /usr/local/bin/cfssl-certinfo

#证书生成工具移至/usr/local/bin
[root@k8s-master01 bin]# ls
cfssl  cfssl-certinfo  cfssljson

#生成证书等文件，ca证书，ca私钥，创建json的文件。 ——》 输出到devuser文件
[root@k8s-master01 devuser]# cd /etc/kubernetes/pki/
[root@k8s-master01 pki]# cfssl gencert -ca=ca.crt -ca-key=ca.key  -profile=kubernetes \
/usr/local/install-k8s/cert/devuser/devuser-csr.json | cfssljson -bare devuser

#设置集群参数  master的IP地址
[root@k8s-master01 pki]# export KUBE_APISERVER="https://10.0.100.10:6443"
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --server=${KUBE_APISERVER}  --kubeconfig=devuser.kubeconfig

解析：
[root@k8s-master01 pki]# kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/pki/ca.crt \ #指定ca证书
--embed-certs=true \ #指定是否加密认证
--server=${KUBE_APISERVER} \ #指定服务器信息
--kubeconfig=devuser.kubeconfig #创建出devuser.kubeconfig文件

Todavía está vacío porque los parámetros deben configurarse a continuación

#设置客户端认证参数,多了用户的信息，私钥信息
[root@k8s-master01 pki]# kubectl config set-credentials devuser \
--client-certificate=/etc/kubernetes/pki/devuser.pem \
--client-key=/etc/kubernetes/pki/devuser-key.pem \
--embed-certs=true \
--kubeconfig=devuser.kubeconfig

#设置上下文参数,绑定至某个名字空间
[root@k8s-master01 pki]# kubectl config set-context kubernetes \
--cluster=kubernetes \ #默认
--user=devuser \
--namespace=dev \
--kubeconfig=devuser.kubeconfig

#复制文件至用户devuser下并修改权限,修改配置文件名称为config
[root@k8s-master01 pki]# mkdir -p /home/devuser/.kube/
[root@k8s-master01 pki]# cp ./devuser.kubeconfig /home/devuser/.kube/config
[root@k8s-master01 pki]# chown devuser:devuser /home/devuser/.kube/config

#赋予admin管理员角色给用户
[root@k8s-master01 devuser]# kubectl create rolebinding devuser-admin-binding --clusterrole=admin --user=devuser --namespace=dev


切换到devuser操作
# 设置默认上下文，让kubectl读取到配置信息
[devuser@k8s-master01 ~]$ cd .kube/
[devuser@k8s-master01 .kube]$ chmod +x config 
[devuser@k8s-master01 .kube]$ kubectl config use-context kubernetes --kubeconfig=config


# 创建pod
[devuser@k8s-master01 .kube]$ kubectl run nginx --image=hub.atguigu.com/library/myapp:v1
[devuser@k8s-master01 .kube]$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-55d45f8bd4-9w5n9    1/1     Running   0          9s

# 查看具体信息
[root@k8s-master01 pki]# kubectl get pod --all-namespaces -o wide | grep nginx
dev             nginx-55d45f8bd4-9w5n9                      1/1     Running   0          53s     10.244.1.73   k8s-node02     <none>           <none>

#该用户只能访问dev命名空间下的资源，进不了default
[devuser@k8s-master01 .kube]$ kubectl get pod -n default
Error from server (Forbidden): pods is forbidden: User "devuser" cannot list resource "pods" in API group "" in the namespace "default"

 

5. Control de acceso

El control de acceso es una colección de complementos de API Server. Al agregar diferentes complementos, se pueden implementar reglas de control de acceso adicionales. Incluso algunas de las funciones principales de API Server deben implementarse a través de controladores de admisión, como ServiceAccount

Hay una lista recomendada de controladores de admisión para diferentes versiones en el documento oficial, y la última lista recomendada de 1.14 es

NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,
MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuot

Enumere las funciones de varios complementos (diferentes complementos implementan diferentes funciones):

• NamespaceLifecycle: evita la creación de objetos en espacios de nombres inexistentes, evita la eliminación de espacios de nombres preestablecidos del sistema y elimina todos sus objetos de recursos cuando se elimina un espacio de nombres.
• LimitRanger: asegúrese de que el recurso solicitado no exceda el límite LimitRange del espacio de nombres donde se encuentra el recurso.
• ServiceAccount: agregar automáticamente ServiceAccount
• ResourceQuota: asegúrese de que el recurso solicitado no exceda el límite de ResourceQuota del recurso