1. Control de acceso a la API de Kubernetes
Para obtener una
referencia más detallada de la API del sitio web oficial de k8s
 
(1) Autenticación
1. Hay 8 métodos de autenticación, y se pueden habilitar uno o más. Mientras se pase un método de autenticación, no se realizarán otros métodos de autenticación. Generalmente, se habilitan dos métodos de autenticación, certificados de cliente X509 y tokens de cuenta de servicio.
2. Hay dos tipos de usuarios en un clúster de Kubernetes: cuentas de servicio administradas por Kubernetes y cuentas ordinarias (cuentas de usuarios). El concepto de cuenta en k8s no es una cuenta que entendemos, realmente no existe, solo existe en forma.
(2) La autorización (autorización)
debe pasar por la etapa de autenticación antes de llegar a la solicitud de autorización. De acuerdo con todas las políticas de autorización que coinciden con los atributos del recurso solicitado, se decide permitir o denegar la solicitud. Actualmente existen 6 métodos de autorización, AlwaysDeny, AlwaysAllow, ABAC, RBAC, Webhook y Node. El clúster predeterminado fuerza la habilitación de RBAC.
(3) El control de admisión (control de admisión)
es un método utilizado para interceptar solicitudes. Se ejecuta después de la autenticación y la autorización. Es el último eslabón en la cadena de autenticación de autorización. Modifica y verifica los objetos de recursos de API solicitados.
(4) Accede a la Los clientes del API Server de k8s se dividen principalmente en dos categorías:
1.kubectl: El .kube / config en el directorio de inicio del usuario guarda la información relevante de la clave del cliente para acceder al API Server, de manera que cuando se accede a k8s con kubectl , leerá automáticamente el archivo de configuración, iniciará la autenticación en el servidor API y completará la solicitud de operación.
Pod: el proceso en el Pod necesita acceder al Servidor API. Si acceden personas o scripts escritos, la cuenta utilizada para este tipo de acceso es: UserAccount; y cuando el Pod en sí se conecta al Servidor API, la cuenta utilizada is: ServiceAccount, producción Este último usa principalmente
(cinco) comandos iniciados por kubectl al apiserver, usando el método http, que en realidad es la operación de agregar, eliminar, modificar y verificar la URL
. La diferencia entre las dos apis es:
api es un enlace especial, solo en el grupo principal v1. Solo se pueden usar los objetos del grupo.
apis Es el nombre de formato fijo de la entrada para el acceso general a la API
kubectl proxy --port=8888 &
curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments
curl http://localhost:8888/api/v1/namespaces/default
2. UserAccount y serviceaccount
Las cuentas de usuario son para personas. La cuenta de servicio es para el proceso que se ejecuta en el pod.
Las cuentas de usuario son globales. Su nombre es globalmente único en cada espacio de nombres del clúster. Los recursos de los usuarios futuros no estarán aislados en el espacio de nombres y las cuentas de servicio estarán aisladas en el espacio de nombres.
En circunstancias normales, las cuentas de usuario del clúster pueden sincronizarse desde la base de datos corporativa, su creación requiere permisos especiales e involucra procesos comerciales complejos. El propósito de la creación de cuentas de servicio es ser más liviano, lo que permite a los usuarios del clúster crear cuentas de servicio para tareas específicas (es decir, el principio de minimizar los permisos)
1. Crear cuenta de servicio
kubectl create serviceaccount admin #此时k8s为用户自动生成认证信息，但没有授权
kubectl get sa
kubectl describe sa admin
# 添加secrets到serviceaccount中
kubectl patch serviceaccount admin -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'
# 把serviceaccount和pod绑定起来
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: game2048
image: reg.westos.org/test/game2048:latest #私有仓库镜像
serviceAccountName: admin
# 将认证信息添加到serviceAccount中，要比直接在Pod指定imagePullSecrets要安全很多
2. Crear cuenta de usuario
cd /etc/kubernetes/pki/
openssl genrsa -out test.key 2048
openssl req -new -key test.key -out test.csr -subj "/CN=test"
openssl x509 -req -in test.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out test.crt -days 365
openssl x509 -in test.crt -text -noout #查看认证
kubectl config set-credentials test --client-certificate=/etc/kubernetes/pki/test.crt --client-key=/etc/kubernetes/pki/test.key --embed-certs=true
kubectl config view
kubectl config set-context test@kubernetes --cluster=kubernetes --user=test
kubectl config use-context test@kubernetes #切换用户
# 此时用户通过认证，但还没有权限操作集群资源，需要继续添加授权
kubectl config delete-user test #用户的删除
3. RBAC
1. RBAC (Control de acceso basado en roles): autorización de control de acceso basado en roles.
Permite a los administradores configurar dinámicamente las políticas de autorización a través de la API de Kubernetes. RBAC es la asociación de usuarios a través de roles y permisos.
RBAC solo autoriza, no niega la autorización, por lo que solo necesita definir lo que el usuario puede hacer.
RBAC incluye cuatro tipos: Rol, ClusterRole, RoleBinding, ClusterRoleBinding
2. Los tres conceptos básicos de RBAC :
Asunto: el tema, representa los tres tipos de temas en k8s, usuario, grupo, servicio Cuenta
Rol: rol, en realidad es un Grupo Las reglas definen un conjunto de permisos de operación para los objetos de la API de Kubernetes.
RoleBinding: define la relación de enlace entre "actuado por" y "rol"
3.
Rol y ClusterRole El rol es una colección de una serie de permisos, el rol solo puede otorgar acceso a los recursos en un solo espacio de nombres.
ClusterRole es similar a Role, pero se puede usar globalmente en el clúster
4. RoleBinding y ClusterRoleBinding
RoleBinding es otorgar permisos definidos en Role a usuarios o grupos de usuarios. Contiene una lista de temas (usuarios, grupos, cuentas de servicio) y hace referencia al rol.
RoleBinding es autorizar dentro de un determinado espacio de nombres, ClusterRoleBinding es adecuado para su uso en el clúster
(1) Ejemplo de rol
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: myrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]
kubectl get role
(Dos). Ejemplo de vinculación de roles
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: test-read-pods
namespace: default
subjects:
- kind: User
name: test
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: myrole
apiGroup: rbac.authorization.k8s.io
# 角色与用户绑定
kubectl get role
kubectl describe role myrole
kubectl get rolebindings.rbac.authorization.k8s.io
kubectl describe rolebindings.rbac.authorization.k8s.io
(3) Ejemplo de ClusterRole
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: myclusterrole
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list", "delete", "create", "update"]
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
kubectl get clusterrole| grep my
kubectl describe clusterrole myclusterrole
(4) Utilice el enlace de roles para enlazar clusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rolebind-myclusterrole
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: test
kubectl get rolebindings.rbac.authorization.k8s.io
kubectl describe rolebindings.rbac.authorization.k8s.io rolebind-myclusterrole
(5) Crear enlace de roles de clúster
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: rolebind-myclusterrole
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: test
kubectl get clusterrolebindings.rbac.authorization.k8s.io | grep rolebind-myclusterrole
kubectl describe clusterrolebindings.rbac.authorization.k8s.io rolebind-myclusterrole
4. Automatización de cuentas de servicios
1. Controlador de admisión de la cuenta de servicio (controlador de admisión de la cuenta de servicio)
Si el pod no tiene una configuración de ServiceAccount, establezca su ServiceAccount en el valor predeterminado.
Asegúrese de que exista la cuenta de servicio asociada con el pod; de lo contrario, rechace el pod.
Si el pod no contiene la configuración ImagePullSecrets, agregue la información de ImagePullSecrets en ServiceAccount al pod.
Agregue un volumen que contenga un token para el acceso de la API al pod.
Agregue el volumeSource montado en /var/run/secrets/kubernetes.io/serviceaccount a cada contenedor debajo del pod.
2. El controlador de Token
detecta la creación de la cuenta de servicio y crea el Secreto correspondiente para admitir el acceso a la API.
Detecte la eliminación de la cuenta de servicio y elimine todos los secretos de token de la cuenta de servicio correspondiente.
Detecte el aumento de Secret para asegurarse de que exista la cuenta de servicio correspondiente y, si es necesario, agregue el token a Secret.
Detecte la eliminación de Secret y elimine la referencia de la cuenta de servicio correspondiente si es necesario.
3. Controlador de cuentas de servicio (controlador de cuentas de servicio) El
administrador de cuentas de servicio administra las cuentas de servicio en cada espacio de nombres y se asegura de que haya una cuenta de servicio denominada "predeterminada" en cada espacio de nombres activo.
4. Kubernetes también tiene "usuarios" El concepto de "Grupo":
El nombre de ServiceAccount correspondiente al "usuario"
integrado es: system: serviceaccount: <nombre de ServiceAccount>
y el nombre integrado correspondiente del grupo de usuarios es:
system: serviceaccounts: <nombre del espacio de nombres>
# (1)表示mynamespace中的所有ServiceAccount
subjects:
- kind: Group
name: system:serviceaccounts:mynamespace #针对pod服务授权
apiGroup: rbac.authorization.k8s.io
# (2)表示整个系统中的所有ServiceAccount
subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io
5. Kubernetes también proporciona cuatro ClusterRoles predefinidos para que los usuarios utilicen directamente: vista de edición de administrador de
cluster-amdin