Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

Comunicándose con clústeres de usuarios en sentido descendente

Esta sección describe cómo Rancher aprovisiona y gestiona los clústeres de usuarios en sentido descendente que ejecutan tus aplicaciones y servicios.

El diagrama a continuación muestra cómo los controladores de clúster, los agentes de clúster y el agente del sistema Rancher permiten a Rancher controlar los clústeres en sentido descendente.

Componentes de Rancher
Figure 1. Comunicándose con clústeres en sentido descendente

Las siguientes descripciones corresponden a los números en el diagrama anterior:

  1. El Proxy de Autenticación

  2. Controladores de clúster y Agentes de clúster

  3. Agente del sistema Rancher

  4. Punto de acceso de clúster autorizado

1. El Proxy de Autenticación

En este diagrama, un usuario llamado Bob quiere ver todos los pods que se ejecutan en un clúster de usuarios en sentido descendente llamado Clúster de Usuarios 1. Desde dentro de Rancher, puede ejecutar un comando kubectl para ver los pods. Bob está autenticado a través del proxy de autenticación de Rancher.

El proxy de autenticación reenvía todas las llamadas a la API de Kubernetes a los clústeres en sentido descendente. Se integra con servicios de autenticación como autenticación local, Active Directory y GitHub. En cada llamada a la API de Kubernetes, el proxy de autenticación autentica al llamador y establece los encabezados de suplantación de Kubernetes adecuados antes de reenviar la llamada a los maestros de Kubernetes.

Rancher se comunica con los clústeres de Kubernetes utilizando una cuenta de servicio. Cada cuenta de usuario en Rancher se correlaciona con una cuenta de servicio equivalente en el clúster en sentido descendente. Rancher utiliza la cuenta de servicio para suplantar al usuario, lo que proporciona todos los permisos que se supone que debe tener el usuario.

Por defecto, Rancher genera un archivo kubeconfig que contiene credenciales para hacer proxy a través del servidor Rancher para conectarse al servidor API de Kubernetes en un clúster de usuarios en sentido descendente. El archivo kubeconfig (kube_config_rancher-cluster.yml) contiene acceso completo al clúster.

2. Controladores de clúster y Agentes de clúster

Cada clúster de usuario en sentido descendente tiene un agente de clúster, que abre un túnel al controlador de clúster correspondiente dentro del servidor Rancher.

Hay un controlador de clúster y un agente de clúster para cada clúster en sentido descendente. Cada controlador de clúster:

  • Observa los cambios de recursos en el clúster en sentido descendente

  • Lleva el estado actual del clúster en sentido descendente al estado deseado

  • Configura políticas de control de acceso a clústeres y proyectos

  • Proporciona clústeres llamando a los controladores de máquina Docker y motores de Kubernetes requeridos, como GKE

Por defecto, para permitir que Rancher se comunique con un clúster en sentido descendente, el controlador de clúster se conecta al agente de clúster. Si el agente de clúster no está disponible, el controlador de clúster puede conectarse a un agente del sistema Rancher en su lugar.

El agente de clúster, también llamado cattle-cluster-agent, es un componente que se ejecuta en un clúster de usuario en sentido descendente. Realiza las siguientes tareas:

  • Se conecta a la API de Kubernetes de los clústeres de Kubernetes lanzados por Rancher

  • Gestiona cargas de trabajo, creación y ampliación de pods dentro de cada clúster

  • Aplica los roles y vinculaciones definidos en las políticas globales de cada clúster

  • Se comunica entre el clúster y el servidor Rancher (a través de un túnel al controlador del clúster) sobre eventos, estadísticas, información de nodos y salud

3. Agente del sistema Rancher

Si el agente del clúster (también llamado cattle-cluster-agent) no está disponible, el agente del sistema Rancher crea un túnel al controlador del clúster para comunicarse con Rancher.

El rancher-system-agent se ejecuta en cada nodo en los clústeres de Kubernetes RKE2 y K3s. Se utiliza para interactuar con los nodos al realizar operaciones en el clúster. Ejemplos de operaciones en el clúster incluyen actualizar la versión de Kubernetes y crear o restaurar instantáneas de etcd.

4. Punto de acceso de clúster autorizado

Un punto de acceso de clúster autorizado (ACE) permite a los usuarios conectarse al servidor API de Kubernetes de un clúster en sentido descendente sin tener que enrutar sus solicitudes a través del proxy de autenticación de Rancher.

ACE está disponible en clústeres RKE2 y K3s que están aprovisionados o registrados con Rancher. No está disponible en clústeres en un proveedor de Kubernetes alojado, como EKS de Amazon.

Hay dos razones principales por las que un usuario podría necesitar el punto de acceso de clúster autorizado:

  • Para acceder a un clúster de usuario en sentido descendente mientras Rancher está inactivo

  • Para reducir la latencia en situaciones donde el servidor Rancher y el clúster en sentido descendente están separados por una larga distancia

El microservicio kube-api-auth se despliega para proporcionar la funcionalidad de autenticación de usuario para el punto de acceso de clúster autorizado. Cuando accedes al clúster de usuario utilizando kubectl, el servidor API de Kubernetes del clúster te autentica utilizando el servicio kube-api-auth como un webhook.

Al igual que el punto de acceso de clúster autorizado, el servicio de autenticación kube-api-auth también está disponible solo para clústeres de Kubernetes lanzados por Rancher.

Situación de ejemplo: Supongamos que el servidor Rancher está ubicado en los Estados Unidos, y el Clúster de Usuario 1 está ubicado en Australia. Una usuaria, Alice, también vive en Australia. Alice puede manipular recursos en el Clúster de Usuario 1 utilizando la interfaz de usuario de Rancher, pero sus solicitudes tendrán que enviarse desde Australia al servidor Rancher en los Estados Unidos, y luego ser reenviadas a Australia, donde se encuentra el clúster de usuario en sentido descendente. La distancia geográfica puede causar una latencia significativa, que Alice puede reducir utilizando el punto final del clúster autorizado.

Con este punto de acceso habilitado para el clúster en sentido descendente, Rancher genera un contexto adicional de Kubernetes en el archivo kubeconfig para conectarse directamente al clúster. Este archivo contiene las credenciales para kubectl y helm.

Para utilizar el contexto ACE en tu kubeconfig, ejecuta kubectl use-context <ace context name> después de habilitarlo.

Para más información, consulta la sección sobre cómo acceder a tu clúster con kubectl y el archivo kubeconfig.

Recomendamos exportar el archivo kubeconfig para que, si Rancher falla, aún puedas utilizar las credenciales en el archivo para acceder a tu clúster.

Personificación

Los usuarios técnicamente existen solo en el clúster en sentido ascendente. Rancher crea RoleBindings y ClusterRoleBindings que hacen referencia a los usuarios de Rancher, aunque no hay ningún recurso de Usuario real en el clúster en sentido descendente.

Cuando los usuarios interactúan con un clúster en sentido descendente a través del proxy de autenticación, debe haber alguna entidad en el sentido descendente que actúe como el actor para esas solicitudes. Rancher crea cuentas de servicio para ser esa entidad. A cada cuenta de servicio solo se le concede un permiso, que es suplantar al usuario al que pertenecen. Si solo hubiera una cuenta de servicio que pudiera suplantar a cualquier usuario, entonces sería posible que un usuario malicioso corrompiera esa cuenta y escalara sus privilegios suplantando a otro usuario. Este problema fue la base para un CVE.

Solución de problemas de suplantación

En el clúster en sentido descendente, cinco recursos se encargan de la suplantación:

  • espacio de nombres: cattle-impersonation-system

  • cuenta de servicio: cattle-impersonation-system/cattle-impersonation-<user ID>

  • secreto del token de cuenta: cattle-impersonation-system/cattle-impersonation-<user ID>-token-<hash>

  • rol de clúster: cattle-impersonation-<user ID>

  • vinculación de rol de clúster: cattle-impersonation-<user ID>

En este ejemplo de un rol de clúster de suplantación típico, el sistema está configurado para usar github como el proveedor de autenticación:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 creationTimestamp: "2021-10-06T18:20:13Z"
 labels:
   authz.cluster.cattle.io/impersonator: "true"
   cattle.io/creator: norman
 name: cattle-impersonation-user-abcde
 resourceVersion: "3528"
 uid: a7478731-72a0-4343-b09f-c3bf12552d77
rules:
# allowed to impersonate user user-abcde
- apiGroups:
 - ""
 resourceNames:
 - user-abcde
 resources:
 - users
 verbs:
 - impersonate
# allowed to impersonate listed groups
- apiGroups:
 - ""
 resourceNames:
 - github_team://123 # group from GitHub auth provider
 - system:authenticated # automatic group from Kubernetes
 - system:cattle:authenticated # automatic group from Rancher
 resources:
 - groups
 verbs:
 - impersonate
# allowed to impersonate principal ID github_user://098
- apiGroups:
 - authentication.k8s.io
 resourceNames:
 - github_user://098 # principal ID from GitHub auth provider
 resources:
 - userextras/principalid
 verbs:
 - impersonate
# allowed to impersonate username example
- apiGroups:
 - authentication.k8s.io
 resourceNames:
 - example # username from GitHub auth provider
 resources:
 - userextras/username
 verbs:
 - impersonate

Cuando solucione problemas de suplantación, verifique si estos recursos existen para el usuario y si las reglas en el rol de clúster son similares a las anteriores. Por ejemplo:

kubectl --namespace cattle-impersonation-system get serviceaccount cattle-impersonation-<user ID>
kubectl --namespace cattle-impersonation-system get secret cattle-impersonation-<user ID>-token-<hash>
kubectl get clusterrole cattle-impersonation-<user ID> --output yaml
kubectl get clusterrolebinding cattle-impersonation-<user ID>

Si ve un error relacionado con "suplantación" en la interfaz de usuario, preste especial atención al end del mensaje de error, que debería indicar la verdadera razón por la que la solicitud falló.

Archivos Importantes

Los archivos mencionados a continuación son necesarios para mantener, solucionar problemas y actualizar su clúster:

  • config.yaml: El archivo de configuración del clúster RKE2 y K3s.

  • rke2.yaml o k3s.yaml: El archivo Kubeconfig para su clúster RKE2 o K3s. Este archivo contiene credenciales para el acceso completo al clúster. Puede usar este archivo para autenticarse con un clúster de Kubernetes lanzado por Rancher si Rancher falla.

Para más información sobre cómo conectarse a un clúster sin el proxy de autenticación de Rancher y otras opciones de configuración, consulte la documentación del archivo kubeconfig.

Herramientas para aprovisionar clústeres de Kubernetes

Las herramientas que Rancher utiliza para aprovisionar clústeres de usuario en sentido descendente dependen del tipo de clúster que se está aprovisionando.

Kubernetes lanzado por Rancher para nodos alojados en un proveedor de infraestructura

Rancher puede aprovisionar dinámicamente nodos en un proveedor como Amazon EC2, DigitalOcean, Azure o vSphere y luego instalar Kubernetes en ellos.

Rancher aprovisiona este tipo de clúster utilizando docker-machine.

Kubernetes lanzado por Rancher para nodos personalizados

Al configurar este tipo de clúster, Rancher instala Kubernetes en nodos existentes, lo que crea un clúster personalizado.

Rancher aprovisiona este tipo de clúster utilizando RKE2 o K3s.

Proveedores de Kubernetes alojados

Al configurar este tipo de clúster, Kubernetes es instalado por proveedores como Google Kubernetes Engine, Amazon Elastic Container Service para Kubernetes o Azure Kubernetes Service.

Rancher aprovisiona este tipo de clúster utilizando kontainer-engine.

Clústeres de Kubernetes importados

En este tipo de clúster, Rancher se conecta a un clúster de Kubernetes que ya ha sido configurado. Por lo tanto, Rancher no aprovisiona Kubernetes, sino que solo configura los agentes de Rancher para comunicarse con el clúster.

Componentes del servidor de Rancher y código fuente

Este diagrama muestra cada componente que integra el servidor de Rancher:

Componentes de Rancher

Los repositorios de GitHub para Rancher se pueden encontrar en los siguientes enlaces:

Esta es una lista parcial de los repositorios más importantes de Rancher. Para más detalles sobre el código fuente de Rancher, consulta la sección sobre contribuir a Rancher. Para ver todas las bibliotecas y proyectos utilizados en Rancher, consulta el go.mod`archivo en el repositorio `rancher/rancher.