K8S como herramientas de gestión de clúster distribuidos, para garantizar la seguridad de su clúster es una tarea importante, apiserver intermediario de los diversos componentes de la comunicación dentro del cluster, sino también el control externo de la entrada, así K8S mecanismo de seguridad básico está diseñado alrededor de la protección de apiserver a. K8S utilizan la autenticación Autenticación, Autorización autorización, control de acceso admissionControl tres pasos para garantizar la seguridad de apiserver.
kubectl usuario, biblioteca cliente o mediante el envío de una solicitud de acceso a la API REST. usuarios y cuentas de servicio Kubernetes pueden ser autorizados para su acceso a la API. Se pasará a través de varias etapas, como se describe en la figura después de la petición llega a la API servidor:
Transport Layer Security
En un clúster típico Kubernetes, API proporciona servicios a través de 443 puertos. servidor API proporciona un certificado. Esto es típicamente certificado autofirmado, de modo / .kube / config certificado raíz directorio contiene normalmente el certificado de servidor de la API, el certificado raíz se utiliza la máquina del usuario $ USER en lugar del predeterminado.
autenticación La autenticación
forma de autenticación:
. 1) el token de autenticación HTTP: la identificación de un usuario legítimo por el Token
la autenticación HTTP con el token durante mucho tiempo un esquema de codificación particular y difícil de imitar una cadena de caracteres para indicar una identificación del cliente --Token manera.
En circunstancias normales, Token es una cadena compleja, por ejemplo, se utiliza una cadena de datos de la firma de clave privada puede ser utilizado como un token. Además, cada una de emergencia corresponde a un nombre de usuario, un archivo en el servidor API puede acceder a la tienda. Cuando un cliente inicia una petición a la llamada a la API, se tienen que poner en los años encabezado HTTP de Token, para que la API del servidor será capaz de identificar a los usuarios y usuarios legítimos de ilegales
2) HTTP Base de autenticación: nombre de usuario + contraseña a través de la
cadena de autenticación Base HTTP después de la 'nombre de usuario + contraseña + de colon "BASE64 codifica mediante algoritmos en la solicitud HTTP se envía al dominio de servidor de cabecera de Autorización . El servidor después de la recepción de la decodificación, para obtener un nombre de usuario y contraseña, y autenticar la identidad del proceso de usuario.
3) El más estrictas HTTPS autenticación de certificado: Sobre la base de dos vías certificado digital certificado raíz de autenticación CA firmó
En primer lugar, se necesita un certificado de entidad emisora. certificado de CA confirmado por la información pública a los demás, mientras que la firma de CA en el certificado. En muchos casos, CA y los usuarios son entidades independientes, CA como proveedor de servicios, es posible debido a que los problemas de calidad de servicio y pérdidas ocasionar al usuario. Encuadernación información del certificado y los datos clave pública correspondiente propietario de la clave privada, y con la firma digital de CA. Certificado también contiene el nombre de la CA con el fin de encontrar la firma digital de la clave pública de la CA para verificar el certificado a la parte que confía.
certificación de CA implica muchos conceptos, como el certificado raíz, certificado autofirmado, clave, algoritmo de cifrado de clave privada y HTTPS y así sucesivamente.
Siguiendo sustancialmente describe los procesos de protocolo SSL para ayudar a entender el certificado de CA y la configuración de CA certificado Kubernetes.
(1) Servicio extremo HTTPS comunicación entre las dos partes para solicitar un certificado de CA, una CA es un tercero de confianza, puede ser una autoridad reconocida en la empresa, puede ser su propia cuenta. sistemas internos suelen utilizar su propio sistema de certificación. Bajo el certificado raíz de CA, el certificado de servidor y la clave privada al solicitante;
(2) las partes HTTPS aplicación cliente comunicación al certificado de CA, expedido de acuerdo con el certificado raíz de CA, el certificado de cliente y una clave privada al solicitante;
( 3) el cliente envía una solicitud al servidor, el certificado de servidor emitido bajo el servidor al cliente. Después de recibir el certificado, la clave privada para descifrar el certificado y el certificado de servidor de certificados comparando la información de certificados de clave pública en el mensaje, tal como el nombre de dominio y la clave pública asociada con el mensaje enviado por el servidor solo es consistente, en caso afirmativo, el cliente reconoce la personalidad jurídica del servidor;
(4) el cliente envía un certificado de cliente al servidor, el servidor recibe un certificado con la clave privada para descifrar el certificado, para obtener el certificado de clave pública del cliente, e información con el certificado de clave pública, confirmar que el cliente es legítimo;
(5) la información del cliente cifrada mediante una clave secreta aleatoria, y transmite la información cifrada al servidor. Después de que el servidor y el cliente negocian un esquema de cifrado buena, el cliente genera una clave secreta aleatoria, el cliente a través del esquema de cifrado negociado, las claves de cifrado al azar, y envía la clave secreta aleatoria al servidor. Cuando el servidor recibe esta clave secreta, el contenido de todas las comunicaciones entre las partes a través de la encriptación de clave secreta aleatoria.
Lo anterior es el proceso de comunicación de protocolo SSL manera específica, esto requiere que el usuario y el certificado del servidor en ambos lados. Unidireccional certificado de protocolo de autenticación SSL CA no necesita tener el cliente, que corresponden a los pasos anteriores, sólo los procesos de validación del lado del servidor para eliminar el certificado de cliente, y en la negociación de una llamada esquema de criptografía simétrica y clave secreta simétrica, el servidor se envía al cliente no se ha cifrado (esto no afecta a la seguridad del proceso SSL) esquemas criptográficos.
nodo K8S requiere autenticación
de dos tipos:
1) el acceso a los componentes apiserver K8S: kubectl, Controller Manager, Scheduler, kubelet, Kube proxy-
2) K8S acceso de gestión pod al contenedor: Pod
instrucciones de seguridad
del gestor de controlador, planificador, apiserver la misma máquina, por lo que el uso directo de apiserver acceso al puerto no seguro, - en los inseguros-bind-address = 127.0.0.1
kubectl, kubelet \ Kube-proxy de acceso apiserver requerirían certificados HTTPS La autenticación mutua
Certificado
manual de publicación: HTTPS certificados fueron emitidos por K8S con el clúster de CA
emite automáticamente: cuando kubelet primera visita apiserver, hacer uso de token de autenticación, generará un certificado para kubelet por el gestor de controlador, después de que los certificados de autenticación de acceso están haciendo.
kubeconfig
archivo kubeconfig contiene parámetros de clúster (certificado de CA, dirección apiserver), el parámetro de cliente (certificado generado y la clave privada), la información de contexto racimo (cluster name, nombre de usuario). K8S especifica kubeconfig componentes diferentes archivos en el arranque se pueden conectar a un grupo diferente.
ServiceAccount
vaina en el acceso apiserver contenedor, porque la vaina de la creación, la destrucción es dinámica, por lo que ir a por ello genera manualmente el certificado de morir. K8S utilizan la cuenta de servicio para resolver el problema de la certificación de la vaina de acceso apiserver
sa relación secreta con los
K8S implica un objeto de recurso llamado secreto, divididos en dos categorías, una es para el servicio ServiceAccount-cuenta-token, el otro se utiliza a opaco información confidencial definida por el usuario tienda. ServiceAccount en
uso se compone de tres partes: el simbólico, en ca.crt, espacio de nombres de
símbolo utilizando una clave de firma apiserver JWT privada para acceder a la autenticación del lado del servidor es apiserver.
ca.crt certificado raíz, el certificado para la validación del lado del cliente apiserver de transmisión
identifica el espacio de nombres del dominio espacial papel de servicio de la cuenta en token
[@ k8smaster la raíz POD] GET # kubectl Secreto --all-espacios de nombres
[@ k8smaster la raíz POD] # kubectl describir secretos default-token-rfxkf --namespace = Kube-sistema
por defecto, cada espacio de nombres tendrá un ServiceAccount, si la vaina no se especifica al crear ServiceAccount, utilizará el espacio de nombres vaina pertenece ServiceAccount
Autenticación Autorización
por encima del proceso de certificación, pero ambas partes confirmaron que una comunicación de la otra parte es creíble, pueden comunicarse entre sí. La autoridad de autenticación es determinar qué recursos tiene la parte solicitante. apiserver apoya Actualmente política de autorización varios (por apiserver --authorization-modo de arranque conjunto de parámetros)
alwaysDeny: rechazado todas las solicitudes, normalmente utilizado para probar
alwaysAllow: permite recibir todas las solicitudes, si el clúster no necesita proceso de autorización, puede ser con esta estrategia
ABAC (control de acceso basado en Attrilbute) : control de acceso basadas en atributos, las reglas de autorización de indicación configurados por el usuario para solicitudes de los usuarios a juego y el control
WebBook: llamando a un servicio REST externo para la autorización de usuario
de RBAC (control de acceso basado en roles ): basada en funciones de control de acceso, la regla por defecto ahora
RBAC modo de autorización
RBAC (Role-Based Access Control) de control de acceso basado en roles, en k8s1.5 introducido, la versión actual de la norma predeterminada, en comparación con otro método de control de acceso tiene las siguientes ventajas:
los recursos de clúster y no de recursos tienen tanto una cobertura completa de
toda la RBAC totalmente completado por varios objetos de la API, API, al igual que otros objetos, puede funcionar con kubectl o api
se puede ajustar en tiempo de ejecución sin tener que reiniciar apiserver
recursos de la API de RBAC de descripciones de objetos
Presenta RBAC cuatro nuevos objetos de alto nivel de recursos: cometido, ClusterRole, RoleBinding, ClusterRoleBinding , 4 tipos de objetos pueden estar en funcionamiento a kubectl con api
Clases, y ClusterRole
en la API de RBAC, papel representa un conjunto de reglas de derecho, que sólo aumentará la (autoridad acumulativo), no hay una gran cantidad de recursos de inicio permisos RBAC mediante la reducción de sus operaciones, el papel se puede definir en un espacio de nombres Si quieres cruzar-namespace puede crear ClusterRole.
ClusterRole tienen los mismos privilegios papeles de funciones de control, la diferencia se ClusterRole es el nivel de clúster, ClusterRole se puede utilizar:
un control de recurso de nivel de clúster (por ejemplo nodo de acceso)
puntos finales no basadas en los recursos (por ejemplo, / acceso healthz)
de todos los recursos espacios de nombres control (por ejemplo, vainas)
Y ClusterRoleBinding RoleBinding
permiso RoleBinding se puede conceder a los roles definidos grupo de usuarios de usuario o, RoleBinding contiene un conjunto de lista de permisos (sujetos), contiene una lista de permisos permisos concedidos a haber diferentes formas de tipos de recursos (usuarios, grupos, cuentas de servicios) , RoleBinding también se incluye en el papel referencias Bind. RoleBinding aplica a autorizada dentro de un espacio de nombres, y ClusterRoleBinding aplica a la autorización en todo el clúster. RoleBinding también se puede hacer referencia ClusterRole autorizado espacio de nombres en el usuario, grupo de usuarios actual o ServiceAccount, esta operación permite a los administradores de racimo para definir algunos CLusterRole general en todo el cluster, y luego usar un RoleBinding espacio de nombres diferente a la referencia, puede ser usado ClusterRoleBinding Todos los permisos de recursos de espacio de nombres en el clúster de ser autorizado,
实战操作
[root @ usuario k8smaster] # useradd devuser #创建用户devuser
[root @ usuario k8smaster] # passwd devuser #设置devuser密码
Cambiar contraseña para devuser usuario.
Nueva contraseña:
contraseña incorrecta: La contraseña es menos de 8 caracteres
Vuelva a escribir la nueva contraseña:
passwd: todos los tokens de autenticación actualizado correctamente.
[root @ usuario k8smaster] #
web oficial certificado de forma generación: https: //kubernetes.io/zh/docs/concepts/cluster-administration/certificates/
Link: https: la generación de certificados herramienta //pan.baidu.com/s/1npkX5-KkBJg13mIDyjRMpg
código de extracción: NRTC
[root @ k8smaster cfssl] # rizo -L https://pkg.cfssl.org/R1.2/cfssl_linux- amd64 -o CFS # descargar la herramienta clave secreta generada
[@ k8smaster la cfssl root] # rizo -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o cfssljson
[@ k8smaster la cfssl root] # rizo - -o-CertInfo cfssl https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 L
[@ k8smaster la cfssl root] # la chmod + X * # Un conjunto de herramientas como permisos de ejecución
[root @ k8smaster pki] pwd #
/ etc / Kubernetes / PKI
[PKI la raíz @ k8smaster] # / la raíz / usuario / cfssl / cfssl la gencert -ca en ca.crt-ca-Key = = = Kubernetes en ca.key -profile / la raíz / usuario / CSR-de devuser .json | / root / usuario / cfssl / cfssljson -bare devuser
# Generar claves y certificados, claves y certificados generados se almacenan en el archivo predeterminado devuser-key.pem y devuser.pem en
02/23/2020 04:22:01 [INFO] Generar solicitud recibida
23/02/2020 04 : 22 es: 01 [el INFO] Recibido el CSR
02/23/2020 04:22:01 [INFO] generación de claves: RSA-2048
02/23/2020 04:22:01 [INFO] codifica la CSR
02/23/2020 04: 22:01 [INFO] certificado firmado con el Número de serie el 341072919289017469746252089406121038060622110111
02/23/2020 04:22:01 [ADVERTENCIA] Este Certificado de Lacks "hosts" un campo ,. Esto lo hace inadecuado para
los sitios web. Ver la para más información en los requisitos de base para The gestión y emisión operados
de los Trusted públicamente Certificados, v.1.1.6, la de la CA / Browser Forum (https://cabforum.org);
ESPECÍFICAMENTE, 10.2.3 de la section ( "Requisitos de Información").
[root @ k8smaster PKI] #
-rw-r - r-- 1 root 1237 Feb 23 de 4:22 devuser.pem
-rw ------- 1 root 1679 Feb 23 de 4:22 devuser-clave. pem
-rw-r - r-- 1 root 997 Feb 23 de 4:22 devuser.csr
[Usuario k8smaster la raíz @] # pwd
/ la raíz / Usuario
[User k8smaster la raíz @] # Exportación KUBE_APISERVER = "https://192.168.23.100:6443" dirección de acceso Set # apiserver
[@ k8smaster el usuario root] # kubectl configuración SET-Cluster kubernetes --certificate-autoridad = / etc / kubernetes / pki / ca.crt --embed-certs = true --server = $ {} KUBE_APISERVER --kubeconfig = devuser.kubeconfig # cúmulo parámetros ajustan
el cluster "Kubernetes" SET.
[ usuario @ k8smaster la raíz] #
[usuario k8smaster la raíz @] # kubectl SET-Credenciales de devuser config \
> = --client-Certificado / etc / Kubernetes / PKI / devuser.pem \
> = --client-Key / etc / Kubernetes / PKI / -de devuser la key.pem \
> --embed a verdaderos-certs = \
> # set --kubeconfig = devuser.kubeconfig parámetros de autenticación de cliente
de usuario "devuser" conjunto.
[root @ usuario k8smaster] #
[root @ k8smaster de usuario] # ls -lrt
total de 8
-rw-r - r-- 1 root root 206 Feb 23 03:20 devuser-csr.json
drwxr-xr-x 2 raíz raíz 55 Feb 23 de 3:34 cfssl
-rw ------- 1 raíz de la raíz 23 de Feb de 4065 04:28 devuser.kubeconfig
[root @ usuario k8smaster] #
[root @ usuario k8smaster] # kubectl crear espacio de nombres dev #创建命名空间
espacio de nombres / dev creado
[root @ usuario k8smaster] # kubectl configuración conjunto contexto kubernetes \
> --cluster = kubernetes \
> user = devuser \
> --namespace = dev \
> --kubeconfig = devuser.kubeconfig #设置上下文Lista de parámetros
de contexto "kubernetes" creadas.
[root @ usuario k8smaster] #
[Root @ k8smaster el usuario] # kubectl Crear rolebinding devuser la unión --clusterrole-admin-admin user = = = dev # devuser --namespace a devuser vinculante dev espacio de nombres rol de administrador
rolebinding.rbac.authorization.k8s.io / Creado de devuser-ADMIN de unión a
[^ k8smaster el usuario root] #
[devuser @ k8smaster ~] $ mkdir .kube
[devuser @ k8smaster ~] $
[Root @ k8smaster el usuario] # cp devuser.kubeconfig /home/devuser/.kube/
[root @ k8smaster el Usuario] # chown devuser: devuser /home/devuser/.kube/devuser.kubeconfig # Kube variables de entorno para configurar devuser
[devuser @ k8smaster .kube] $ ls -lrt
total de 8
-rw ------- 1 devuser devuser 4153 23 feb 04:40 devuser.kubeconfig
[devuser @ k8smaster .kube] $ mv devuser.kubeconfig config
[devuser @ k8smaster .kube] $ kubectl config uso contexto kubernetes --kubeconfig = config #切换用户上下文
cambia a "kubernetes" de contexto.
[devuser @ k8smaster .kube] $ kubectl get vaina
No recursos encontrados.
[devuser @ k8smaster .kube] $
[devuser @ k8smaster .kube] $ kubectl plazo Tomcat --image = 192.168.23.100: 5000 / Tomcat: v2 = --port 8080 --replicas = 1 #运行Tomcat
kubectl plazo --generator = despliegue / apps.v1 es obsoleto y se eliminará en una versión futura. Uso kubectl plazo --generator = run-pod / V1 o kubectl crear en su lugar.
deployment.apps / Tomcat creado
[devuser @ k8smaster .kube] $ kube
[Root @ k8smaster el usuario] # Los espacios de nombres kubectl GET POD --all-Wide -O | grep Tomcat #tomcat carreras en dev espacio de nombres
dev-Tomcat bb9f46cfc-gzmgr 1/1 Ejecución de 0 2m39s 10.244.2.37 k8snode02 <ninguno> <ninguno>
[root @ k8smaster el usuario] #
[devuser @ k8smaster .kube] $ kubectl GET POD -n predeterminado #devuser no ver otros espacios de nombres, como por defecto
de error del servidor (Prohibido): Vainas de usuario están prohibidas: la "devuser" el usuario no Lista de recursos puede " pods "en API Grupo" "en el espacio de nombres en el" default "
[devuser @ k8smaster .kube] $
Control de admisión
de control de admisión es apiserver colección de plugins mediante la adición de diferentes plugins, implementar reglas de control de acceso adicionales. Incluso algunas de las principales características de apiserver lograrse a través de los controladores de admisión, como ServiceAccount
