Este artículo se ha incluido en la columna " Aprender k8s desde cero "
Artículo anterior: Comprensión profunda de kubectl Haga clic saltar
Gestión de la configuración con rbac
Secreto del centro de gestión de configuración
¿Qué es un secreto?
El Configmap que aprendimos anteriormente generalmente se usa para almacenar datos de texto sin formato, como archivos de configuración.Para algunos datos confidenciales, como contraseñas, claves privadas y otros datos, se usa el tipo secreto.
Secret resuelve el problema de configuración de datos confidenciales como contraseñas, tokens y claves secretas sin exponer estos datos confidenciales a imágenes o especificaciones de pod. El secreto se puede utilizar como volumen o variable de entorno.
Para usar un secreto, el pod debe hacer referencia al secreto. Los pods pueden usar secretos de dos maneras: como archivos en un volumen que se montan en uno o más contenedores en el pod, o cuando el kubelet extrae imágenes para el pod. (Por ejemplo, Harbor Pull, que almacena la contraseña del usuario del puerto, etc.)
Hay tres parámetros opcionales para el secreto:
genérico: un tipo genérico, normalmente utilizado para almacenar datos de contraseña.
tls: este tipo solo se usa para almacenar claves privadas y certificados.
docker-registry: si desea guardar la información de autenticación del repositorio docker, debe usar este tipo para crear.
Tipo de secreto:
Cuenta de servicio: solía ser referenciada por cuenta de servicio. Cuando se crea serviceacout, Kubernetes creará el secreto correspondiente de forma predeterminada. Si el Pod usa una cuenta de servicio, el secreto correspondiente se montará automáticamente en el directorio /run/secrets/kubernetes.io/serviceaccount del Pod.
Opaco: Secreto en formato de codificación base64, utilizado para almacenar contraseñas, claves secretas, etc. Los datos originales se pueden obtener a través de la decodificación base64-decode, por lo que la seguridad es débil
kubernetes.io/dockerconfigjson: se utiliza para almacenar información de autenticación para el registro privado de Docker.
usar secreto
1. Introduzca secreto a través de variables de entorno para
crear la contraseña del usuario root de mysql como secreto
[root@k8smaster ~]# kubectl create secret generic mysql-password --from-literal=password=paopaopodshuaige66
secret/mysql-password created
[root@k8smaster secret]# kubectl get secrets
NAME TYPE DATA AGE
mysql-password Opaque 1 60s
[root@k8smaster secret]# kubectl describe secret mysql-password
Name: mysql-password
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 18 bytes
El valor de la contraseña está encriptado, pero el encriptado del secreto es un pseudo-encriptado. Solo codifica los datos en base 64. El siguiente es el desencriptado para encontrar la contraseña encriptada en mysqlpassword.
[root@k8smaster secret]# kubectl get secret -o yaml
- apiVersion: v1
data:
password: eGlhbmNoYW9wb2QqKmx1Y2t5NjY=
[root@k8smaster secret]# echo 'eGlhbmNoYW9wb2QqKmx1Y2t5NjY=' | base64 --decode
paopaopodshuaige66
#创建 pod，引用 secret
[root@k8smaster secret]# vim pod-secret.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
labels:
app: myapp
spec:
containers:
- name: myapp
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
env:
- name: MYSQL_ROOT_PASSWORD #它是 Pod 启动成功后,Pod 中容器的环境变量名.
valueFrom:
secretKeyRef:
name: mysql-password #这是 secret的对象名 把这个secret中的password这个key和对应的value值赋值给上面的变量
key: password #它是 secret 中的 key 名
[root@k8smaster secret]# kubectl apply -f pod-secret.yaml
pod/pod-secret created
[root@k8smaster secret]# kubectl exec -it pod-secret -- /bin/sh
/ # printenv
MYSQL_ROOT_PASSWORD=paopaopodshuaige66
Mount Secret a través del volumen
Crear secreto, encriptar manualmente, basado en encriptación base64
[root@k8smaster secret]# echo -n 'admin' | base64
YWRtaW4=
[root@k8smaster secret]# echo -n 'paopaoshuaige' | base64
cGFvcGFvc2h1YWlnZQ==
解码
[root@k8smaster secret]# echo cGFvcGFvc2h1YWlnZQ== | base64 -d
paopaoshuaige
Crear archivo yaml
[root@k8smaster secret]# vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: cGFvcGFvc2h1YWlnZQ==
[root@k8smaster secret]# kubectl apply -f secret.yaml
secret/mysecret created
[root@k8smaster secret]# kubectl describe secret mysecret
Name: mysecret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 13 bytes
username: 5 bytes
Monte el secreto al volumen
[root@xianchaomaster1 ~]# vim pod_secret_volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret-volume
spec:
containers:
- name: myapp
image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
imagePullPolicy: IfNotPresent
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
readOnly: true
volumes:
- name: secret-volume #把secret做成卷挂载到/etc/secret 只读权限
secret:
secretName: mysecret
[root@k8smaster secret]# kubectl apply -f pod_secret_volume.yaml
pod/pod-secret-volume created
[root@k8smaster secret]# kubectl exec -it pod-secret-volume -- /bin/sh
/ # ls /etc/secret
password username
/ # cat /etc/secret/username
admin
/ # cat /etc/secret/password
paopaoshuaige/ #
De lo anterior se puede ver que la información secreta montada en el pod en realidad ha sido descifrada.
Autorización RBAC del mecanismo de seguridad k8s
Gestión de seguridad de k8s: una descripción general de la autenticación, la autorización y el control de admisión
k8s ha realizado configuraciones precisas para la autenticación, autorización y control de acceso de todo nuestro sistema; para el clúster k8s, el servidor ap es la única entrada para el control de acceso de todo el clúster. Cuando implementamos aplicaciones en el clúster k8s, también podemos pasar el fregadero El puerto expuesto por el NodePort del host accede al programa interno, y el usuario debe pasar por el siguiente proceso de autenticación para acceder al clúster de kubernetes: autenticación -> autorización -> control de admisión (controlador de administración)
1. La autenticación es la autenticación del cliente, y el punto popular es la autenticación del nombre de usuario y la contraseña.
2. La autorización es la autorización de recursos. Los recursos en k8s no son más que contenedores. Al final, en realidad son los recursos informáticos, de red y de almacenamiento del contenedor. Cuando se autentica una solicitud, necesita acceder a un determinado recurso (como la creación de un pod), la comprobación de autorización determinará si el cliente puede acceder al recurso (como un pod en un espacio de nombres) de acuerdo con las reglas de autorización.
3. Mecanismo de Control de Admisión: El Controlador de Admisión está ubicado en el Servidor API, antes de que el objeto sea persistente, el Controlador de Admisión intercepta la solicitud al Servidor API, que generalmente se usa para autenticación y autorización. Contiene dos controladores especiales:
MutatingAdmissionWebhook y ValidatingAdmissionWebhook. Como mutación de configuración y webhook de control de admisión de validación respectivamente.
Control de Admisión Mutante: Modificar el objeto solicitado
Validando el Control de Admisión: Validando el objeto solicitado
El controlador de admisión se configura en los parámetros de inicio del API Server. Un controlador de admisión puede pertenecer a uno o ambos de los anteriores. Cuando la solicitud llega al API Server, primero se realiza el control de admisión de cambios y luego se realiza el control de admisión de verificación.
Al implementar un clúster de Kubernetes, habilitaremos una serie de controladores de admisión de forma predeterminada. Si estos controladores de admisión no están configurados, se puede decir que su clúster de Kubernetes se está ejecutando desnudo. Solo el administrador del clúster puede modificar el controlador de admisión del clúster.
Por ejemplo, habilitaría el siguiente controlador de admisión de forma predeterminada.
--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
La arquitectura general de k8s también es una arquitectura de microservicios. Todas las solicitudes se realizan a través de un Gateway, es decir, el componente kube-apiserver (que proporciona servicios REST al mundo exterior). Hay dos tipos de clientes en k8s, uno es para usuarios ordinarios, y el otro es para usuarios ordinarios. Es un Pod en el clúster. Los mecanismos de autenticación de estos dos clientes son ligeramente diferentes, pero no importa cuál sea, deben pasar por los tres mecanismos de autenticación, autorización, y acceso a su vez.
Certificación
1. La autenticación admite una variedad de complementos
(1) Autenticación de token:
Ambas partes tienen una clave compartida, y primero se crea una contraseña en el servidor, y el cliente puede iniciar sesión con esta contraseña al iniciar sesión. Este es el método de autenticación de clave simétrica. k8s proporciona una interfaz tranquila y todos sus servicios se brindan a través del protocolo http, por lo que la información de autenticación solo se puede pasar a través del encabezado de autenticación del protocolo http, que generalmente se denomina token.
(2) autenticación SSL:
Para el acceso k8s, la autenticación ssl le permite al cliente confirmar la identidad de autenticación del servidor. Cuando nos comunicamos con el servidor, necesitamos que el servidor envíe un certificado. Necesitamos confirmar si el certificado está firmado por ca. Si es un ca reconocemos Firmado, la información del sujeto en él es consistente con la información del host de destino que visitamos, no hay problema, entonces creemos que la identidad del servidor ha sido autenticada. Lo más importante en k8s es que el servidor también necesita autenticar la información del cliente, y kubectl también debe tener un Certificado, este certificado también es un certificado firmado por el CA reconocido por el servidor. Ambas partes deben autenticarse entre sí para realizar una comunicación cifrada, que es la autenticación SSL.
2. Cuenta en kubernetes
El cliente inicia una solicitud al servidor ap. El servidor ap necesita identificar si el usuario tiene el permiso solicitado y si el usuario puede realizar la operación correspondiente a través del servidor ap. Qué información se necesita para identificar la información del usuario para completar el control de acceso relevante para ¿el usuario?
kubectl Explain pods.spec puede ver que hay un campo serviceAccountName (nombre de cuenta de servicio), esta es la cuenta utilizada cuando nuestro pod se conecta a apserver, por lo que hay dos tipos de cuentas en todo el clúster de kubernetes, ServiceAccount (cuenta de servicio), Cuenta de usuario (cuenta de usuario) cuenta)
Cuenta de usuario: una cuenta en la que todos pueden iniciar sesión en realidad, el cliente desea iniciar una solicitud al servidor ap, y el servidor ap necesita identificar si el cliente tiene el permiso solicitado, luego diferentes usuarios tendrán diferentes permisos, dependiendo de la representación de la cuenta de usuario, llamada nombre de usuario
ServiceAccount: Está diseñado para facilitar el proceso en el Pod para llamar a la API de Kubernetes u otros servicios externos.Es un recurso en kubernetes.
sa cuenta: la cuenta utilizada para iniciar sesión en el tablero
cuenta de usuario: este es el usuario que inicia sesión en la máquina física k8s
执行kubectl指令的时候会加载文件
[root@k8smaster secret]# cat /root/.kube/config
文件里有一个user用户，做了rbac授权
user: kubernetes-admin
会基于这个用户去访问k8s
escribir al final
No es fácil de crear, si crees que el contenido es útil para ti, ¡por favor dame un seguimiento de tres enlaces para apoyarme! Si hay algún error, indíquelo en los comentarios y lo cambiaré a tiempo.
La serie actualmente en actualización: Aprendiendo k8s desde cero
Gracias por mirar, el artículo se mezcla con la comprensión personal, si hay algún error, comuníquese conmigo para señalarlo ~