Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Aislamiento de inquilinos

Cuando pensamos en la tenencia múltiple, con frecuencia queremos aislar a un usuario o una aplicación de otros usuarios o aplicaciones que se ejecutan en una infraestructura compartida.

Kubernetes es un orquestador de un solo inquilino, es decir, todos los inquilinos de un clúster comparten una sola instancia del plano de control. Sin embargo, hay varios objetos de Kubernetes que puedes usar para crear la apariencia de tener varios inquilinos. Por ejemplo, los espacios de nombres y los controles de Role-based acceso (RBAC) se pueden implementar para aislar lógicamente a los inquilinos unos de otros. Del mismo modo, las cuotas y los rangos de límites se pueden usar para controlar la cantidad de recursos del clúster que puede consumir cada inquilino. Sin embargo, el clúster es la única construcción que proporciona un límite de seguridad sólido. Esto se debe a que un atacante que consigue acceder a un host del clúster puede recuperar todos los secretos y volúmenes montados en ese host. ConfigMaps También podrían hacerse pasar por el Kubelet, lo que les permitiría manipular los atributos del nodo y and/or moverlos lateralmente dentro del clúster.

En las siguientes secciones, se explica cómo implementar el aislamiento de los inquilinos y, al mismo tiempo, mitigar los riesgos de utilizar un único orquestador de inquilinos, como Kubernetes.

Tenencia múltiple flexible

Con la tenencia múltiple flexible, se utilizan construcciones nativas de Kubernetes, como los espacios de nombres, los roles y los enlaces de roles y las políticas de red, para crear una separación lógica entre los inquilinos. El RBAC, por ejemplo, puede impedir que los inquilinos accedan a los recursos de los demás o los manipulen. Las cuotas y los rangos de límites controlan la cantidad de recursos del clúster que puede consumir cada inquilino, mientras que las políticas de red pueden ayudar a evitar que las aplicaciones implementadas en diferentes espacios de nombres se comuniquen entre sí.

Sin embargo, ninguno de estos controles impide que los pods de distintos usuarios compartan un nodo. Si se requiere un aislamiento más estricto, puedes usar un selector de nodos, reglas de antiafinidad, restricciones and/or y tolerancias para obligar a los pods de diferentes arrendatarios a programarse en nodos separados, a menudo denominados nodos de inquilino único. Esto puede resultar bastante complicado y tener un coste prohibitivo en un entorno con muchos inquilinos.

Kiosk es un proyecto de código abierto que puede ayudar a implementar la tenencia múltiple flexible. Se implementa como una serie de CRD y controladores que proporcionan las siguientes capacidades:

Loft es una oferta comercial de los mantenedores de Kiosk y que añade las siguientes capacidades: DevSpace

Hay tres casos de uso principales que pueden abordarse mediante la opción multiusuario flexible.

Configuración empresarial

La primera es en un entorno empresarial, en el que los «inquilinos» son poco confiables, ya que son empleados, contratistas o están autorizados por la organización de algún otro modo. Por lo general, cada inquilino se alineará con una división administrativa, como un departamento o un equipo.

En este tipo de entorno, un administrador de clústeres normalmente será responsable de crear los espacios de nombres y administrar las políticas. También pueden implementar un modelo de administración delegada en el que determinadas personas supervisen un espacio de nombres, lo que les permite realizar operaciones CRUD para objetos no relacionados con políticas, como despliegues, servicios, pods, trabajos, etc.

El aislamiento que proporciona el tiempo de ejecución de un contenedor puede ser aceptable en esta configuración o puede que sea necesario aumentarlo con controles adicionales para la seguridad de los pods. También puede ser necesario restringir la comunicación entre servicios en diferentes espacios de nombres si se requiere un aislamiento más estricto.

Kubernetes como servicio

Por el contrario, la opción multiusuario flexible se puede utilizar en entornos en los que se quiera ofrecer Kubernetes como servicio (KaaS). Con KaaS, la aplicación se aloja en un clúster compartido junto con una colección de controladores y CRD que proporcionan un conjunto de servicios de PaaS. Los inquilinos interactúan directamente con el servidor de API de Kubernetes y pueden realizar operaciones CRUD en objetos que no sean de políticas. También hay un elemento de autoservicio en el sentido de que se puede permitir a los inquilinos crear y administrar sus propios espacios de nombres. En este tipo de entorno, se supone que los inquilinos ejecutan código que no es de confianza.

Para aislar a los inquilinos en este tipo de entorno, es probable que tengas que implementar políticas de red estrictas, así como un entorno aislado de módulos. El sandboxing consiste en ejecutar los contenedores de un pod dentro de una micromáquina virtual, como Firecracker, o en un kernel del espacio de usuario. En la actualidad, puede crear módulos en entornos aislados con EKS Fargate.

Software como servicio (SaaS)

El caso de uso final de la tenencia múltiple flexible es el entorno (SaaS). Software-as-a-Service En este entorno, cada inquilino está asociado a una instancia concreta de una aplicación que se ejecuta en el clúster. Cada instancia suele tener sus propios datos y utiliza controles de acceso independientes que, por lo general, son independientes del RBAC de Kubernetes.

A diferencia de otros casos de uso, el inquilino de una configuración de SaaS no interactúa directamente con la API de Kubernetes. En cambio, la aplicación SaaS es responsable de interactuar con la API de Kubernetes para crear los objetos necesarios para apoyar a cada inquilino.

Construcciones de Kubernetes

En cada uno de estos casos, se utilizan las siguientes construcciones para aislar a los inquilinos unos de otros:

Espacios de nombres

Los espacios de nombres son fundamentales para implementar una tenencia múltiple flexible. Permiten dividir el clúster en particiones lógicas. Las cuotas, las políticas de red, las cuentas de servicio y otros objetos necesarios para implementar la modalidad multiusuario se asignan a un espacio de nombres.

Políticas de red

De forma predeterminada, todos los pods de un clúster de Kubernetes pueden comunicarse entre sí. Este comportamiento se puede modificar mediante políticas de red.

Las políticas de red restringen la comunicación entre los pods mediante etiquetas o intervalos de direcciones IP. En un entorno con varios inquilinos en el que se requiere un aislamiento estricto de la red entre los inquilinos, recomendamos empezar con una regla predeterminada que niegue la comunicación entre los pods y otra regla que permita a todos los pods consultar el servidor DNS para resolver los nombres. Una vez establecida, puede empezar a agregar más reglas permisivas que permitan la comunicación dentro de un espacio de nombres. Esto se puede refinar aún más según sea necesario.

Role-based control de acceso (RBAC)

Los roles y los enlaces de roles son los objetos de Kubernetes que se utilizan para aplicar el control de acceso basado en roles (RBAC) en Kubernetes. Los roles contienen listas de acciones que se pueden realizar contra los objetos de tu clúster. Los enlaces de roles especifican las personas o grupos a los que se aplican los roles. En los entornos empresariales y de KaaS, el RBAC se puede utilizar para permitir la administración de objetos por parte de grupos o individuos seleccionados.

Cuotas

Las cuotas se utilizan para definir los límites de las cargas de trabajo alojadas en el clúster. Con las cuotas, puedes limitar la cantidad total de CPU y memoria que se puede consumir en un espacio de nombres o limitar la cantidad de objetos que se pueden crear. Los rangos de límite te permiten declarar los valores mínimos, máximos y predeterminados de CPU y memoria para los pods y contenedores individuales dentro de un espacio de nombres.

La asignación excesiva de recursos en un clúster compartido suele ser beneficiosa porque te permite maximizar tus recursos. Sin embargo, el acceso ilimitado a un clúster puede provocar la falta de recursos, lo que puede provocar una degradación del rendimiento y una pérdida de disponibilidad de las aplicaciones. Si las solicitudes de un pod son demasiado bajas y la utilización real de los recursos supera la capacidad del nodo, el nodo comenzará a experimentar una presión sobre la CPU o la memoria. Cuando esto ocurre, es posible que los pods se reinicien y se and/or desalojen del nodo.

Para evitar que esto suceda, debes establecer cuotas en los espacios de nombres de un entorno con varios inquilinos para obligar a los inquilinos a especificar las solicitudes y los límites al programar sus pods en el clúster. También mitigará una posible denegación de servicio al limitar la cantidad de recursos que puede consumir un pod.

También puedes usar las cuotas para distribuir los recursos del clúster de forma que coincidan con los gastos del inquilino. Esto es particularmente útil en el escenario de KaaS.

Prioridad y preferencia de los pods

La prioridad y la preferencia de los pods pueden resultar útiles si quieres dar más importancia a un pod en comparación con otros pods. Por ejemplo, con la prioridad de los pods, puede configurar los pods del cliente A para que se ejecuten con una prioridad mayor que la del cliente B. Cuando no haya suficiente capacidad disponible, el programador desalojará los pods de menor prioridad del cliente B para dar cabida a los pods de mayor prioridad del cliente A. Esto puede resultar especialmente útil en un entorno de SaaS en el que los clientes dispuestos a pagar una prima reciben una prioridad más alta.

Controles mitigantes

Su principal preocupación como administrador de un entorno multiusuario es evitar que un atacante acceda al host subyacente. Se deben tener en cuenta los siguientes controles para mitigar este riesgo:

Entornos de ejecución en espacio aislado para contenedores

El sandboxing es una técnica mediante la cual cada contenedor se ejecuta en su propia máquina virtual aislada. Entre las tecnologías que permiten hacer sandboxing en módulos se incluye Firecracker.

Para obtener información adicional sobre el esfuerzo por convertir Firecracker en un entorno de ejecución compatible con EKS, consulte https://threadreaderapp.com/thread/1238496944684597248.html.

Gatekeeper de Open Policy Agent (OPA) &

Gatekeeper es un controlador de admisión de Kubernetes que hace cumplir las políticas creadas con OPA. https://www.openpolicyagent.org/ Con OPA, puedes crear una política que gestione los pods de los arrendatarios en instancias distintas o con una prioridad mayor que la de otros arrendatarios. Puedes encontrar una colección de políticas OPA comunes en el GitHub repositorio de este proyecto.

También hay un complemento OPA experimental para CoreDNS que te permite usar OPA para filter/control los registros devueltos por CoreDNS.

Kyverno

Kyverno es un motor de políticas nativo de Kubernetes que puede validar, mutar y generar configuraciones con políticas como recursos de Kubernetes. Kyverno usa Kustomize-style superposiciones para la validación, admite el parche JSON y el parche de fusión estratégica para la mutación, y puede clonar recursos en diferentes espacios de nombres basándose en activadores flexibles.

Puedes usar Kyverno para aislar los espacios de nombres, reforzar la seguridad de los pods y otras prácticas recomendadas, y generar configuraciones predeterminadas, como las políticas de red. En el GitHub repositorio de este proyecto se incluyen varios ejemplos. Muchos otros están incluidos en la biblioteca de políticas del sitio web de Kyverno.

Aislar las cargas de trabajo de los inquilinos en nodos específicos

Restringir las cargas de trabajo de los inquilinos para que se ejecuten en nodos específicos puede utilizarse para aumentar el aislamiento en el modelo flexible de tenencia múltiple. Con este enfoque, las cargas de trabajo específicas de los inquilinos solo se ejecutan en los nodos aprovisionados para los respectivos inquilinos. Para lograr este aislamiento, se utilizan las propiedades nativas de Kubernetes (afinidad de nodos y limitaciones y tolerancias) para programar los pods en nodos específicos y evitar que los pods de otros inquilinos se programen en los nodos específicos del inquilino.

Parte 1: Afinidad de nodos

La afinidad de nodos de Kubernetes se usa para programar los nodos según las etiquetas de los nodos. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ Con las reglas de afinidad de nodos, los pods se sienten atraídos por nodos específicos que coincidan con los términos del selector. En la siguiente especificación del pod, la afinidad del requiredDuringSchedulingIgnoredDuringExecution nodo se aplica al pod correspondiente. El resultado es que el pod se dirigirá a los nodos etiquetados con lo siguiente key/value:node-restriction.kubernetes.io/tenant: tenants-x.

...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: node-restriction.kubernetes.io/tenant
            operator: In
            values:
            - tenants-x
...

Con esta afinidad de nodos, la etiqueta es obligatoria durante la programación, pero no durante la ejecución; si las etiquetas de los nodos subyacentes cambian, los pods no se expulsarán únicamente por ese cambio de etiqueta. Sin embargo, la programación futura podría verse afectada.

Parte 2: Manchas y tolerancias

Atraer las cápsulas a los nodos es solo la primera parte de este enfoque de tres partes. Para que este enfoque funcione, debemos evitar que los pods se programen en nodos para los que no estén autorizados. Para repeler los pods no deseados o no autorizados, Kubernetes utiliza nodos contaminados. https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/ Las contaminaciones se utilizan para imponer condiciones en los nodos que impiden la programación de los pods. La siguiente mancha usa un par clave-valor de. tenant: tenants-x

...
    taints:
      - key: tenant
        value: tenants-x
        effect: NoSchedule
...

Dado el nodo anteriortaint, solo se permitirá programar en el nodo los pods que toleren la contaminación. Para permitir que los pods autorizados se programen en el nodo, las especificaciones de los pods correspondientes deben incluir una referencia toleration a la contaminación, tal y como se muestra a continuación.

...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

Los pods con lo anterior no toleration impedirán que se programen en el nodo, al menos no debido a esa mancha específica. Kubernetes también usa las manchas para detener temporalmente la programación de los pods en determinadas condiciones, como la presión de los recursos de los nodos. Gracias a la afinidad de los nodos y a las limitaciones y tolerancias, podemos atraer de forma eficaz los pods deseados a nodos específicos y repeler los no deseados.

Parte 3: administración Policy-based para la selección de nodos

Hay varias herramientas que se pueden utilizar para ayudar a gestionar la afinidad de los nodos y las tolerancias de las especificaciones de los módulos, incluida la aplicación de las normas en los procesos del CICD. Sin embargo, el aislamiento también debe aplicarse a nivel de clúster de Kubernetes. Con este fin, las herramientas de administración de políticas se pueden utilizar para mutar las solicitudes entrantes del servidor API de Kubernetes, en función de la carga útil de las solicitudes, a fin de aplicar las respectivas reglas de afinidad de nodos y tolerancias mencionadas anteriormente.

Por ejemplo, los pods destinados al espacio de nombres de tenants-x se pueden marcar con la afinidad y la tolerancia de nodos correctas para permitir la programación en los nodos de tenants-x. Al utilizar herramientas de administración de políticas configuradas mediante el webhook de admisión mutante de Kubernetes, las políticas se pueden usar para modificar las especificaciones de los pods entrantes. Las mutaciones añaden los elementos necesarios para permitir la programación deseada. A continuación, se muestra un ejemplo de OPA/Gatekeeper política que agrega una afinidad de nodo.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-nodeaffinity-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds Node affinity - https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms"
  parameters:
    assign:
      value:
        - matchExpressions:
          - key: "tenant"
            operator: In
            values:
            - "tenants-x"

La política anterior se aplica a una solicitud del servidor de la API de Kubernetes para aplicar un pod al espacio de nombres tenants-x. La política agrega la regla de afinidad de requiredDuringSchedulingIgnoredDuringExecution nodos, de modo que los pods se sientan atraídos por los nodos con la etiqueta. tenant: tenants-x

Una segunda política, que se muestra a continuación, añade la tolerancia a la misma especificación del pod, utilizando los mismos criterios de coincidencia en cuanto al espacio de nombres y grupos, tipos y versiones de destino.

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: mutator-add-toleration-pod
  annotations:
    aws-eks-best-practices/description: >-
      Adds toleration - https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    namespaces: ["tenants-x"]
  location: "spec.tolerations"
  parameters:
    assign:
      value:
      - key: "tenant"
        operator: "Equal"
        value: "tenants-x"
        effect: "NoSchedule"

Las políticas anteriores son específicas de los pods; esto se debe a las rutas que conducen a los elementos mutados de los elementos de las políticas. location Se podrían escribir políticas adicionales para gestionar los recursos que crean pods, como los recursos de implementación y de trabajo. Las políticas enumeradas y otros ejemplos se pueden consultar en el GitHub proyecto complementario de esta guía.

El resultado de estas dos mutaciones es que las vainas son atraídas hacia el nodo deseado y, al mismo tiempo, no son repelidas por la mancha ganglionar específica. Para comprobarlo, podemos ver los fragmentos del resultado de dos kubectl llamadas para etiquetar los nodos con tenant=tenants-x ellos y colocar los pods en el espacio de nombres. tenants-x

kubectl get nodes -l tenant=tenants-x
NAME
ip-10-0-11-255...
ip-10-0-28-81...
ip-10-0-43-107...

kubectl -n tenants-x get pods -owide
NAME                                  READY   STATUS    RESTARTS   AGE   IP            NODE
tenant-test-deploy-58b895ff87-2q7xw   1/1     Running   0          13s   10.0.42.143   ip-10-0-43-107...
tenant-test-deploy-58b895ff87-9b6hg   1/1     Running   0          13s   10.0.18.145   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-nxvw5   1/1     Running   0          13s   10.0.30.117   ip-10-0-28-81...
tenant-test-deploy-58b895ff87-vw796   1/1     Running   0          13s   10.0.3.113    ip-10-0-11-255...
tenant-test-pod                       1/1     Running   0          13s   10.0.35.83    ip-10-0-43-107...

Como podemos ver en los resultados anteriores, todos los pods están programados en los nodos etiquetados con. tenant=tenants-x En pocas palabras, los pods solo se ejecutarán en los nodos deseados y los demás pods (sin la afinidad y las tolerancias requeridas) no. Las cargas de trabajo de los inquilinos están aisladas de manera efectiva.

A continuación se muestra un ejemplo de especificación de un pod mutado.

apiVersion: v1
kind: Pod
metadata:
  name: tenant-test-pod
  namespace: tenants-x
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: tenant
            operator: In
            values:
            - tenants-x
...
  tolerations:
  - effect: NoSchedule
    key: tenant
    operator: Equal
    value: tenants-x
...

En los ejemplos anteriores, utilizamos políticas escritas para OPA/Gatekeeper. Sin embargo, hay otras herramientas de administración de políticas que también se ocupan de nuestro caso práctico de selección de nodos. Por ejemplo, esta política de Kyverno podría usarse para gestionar la mutación por afinidad de nodos.

Referencias

Difícil tenencia múltiple

La tenencia múltiple dura se puede implementar mediante el aprovisionamiento de clústeres independientes para cada inquilino. Si bien esto proporciona un aislamiento muy fuerte entre los inquilinos, tiene varios inconvenientes.

En primer lugar, cuando hay muchos inquilinos, este enfoque puede volverse caro rápidamente. No solo tendrá que pagar los costos del plano de control de cada clúster, sino que no podrá compartir los recursos informáticos entre los clústeres. Con el tiempo, esto provocará una fragmentación en la que un subconjunto de los clústeres se subutilice mientras que otros se utilicen en exceso.

En segundo lugar, es probable que necesite comprar o crear herramientas especiales para administrar todos estos clústeres. Con el tiempo, la administración de cientos o miles de clústeres puede resultar demasiado difícil de manejar.

Por último, la creación de un clúster por inquilino será lenta en comparación con la creación de un espacio de nombres. Sin embargo, puede ser necesario adoptar un enfoque de tenencia estricta en sectores altamente regulados o en entornos de SaaS en los que se requiere un fuerte aislamiento.

Direcciones futuras

La comunidad de Kubernetes ha reconocido las deficiencias actuales de la tenencia múltiple flexible y los desafíos que plantea la tenencia múltiple compleja. El Grupo de Interés Multi-Tenancy Especial (SIG) está intentando abordar estas deficiencias mediante varios proyectos de incubación, incluidos el controlador jerárquico del espacio de nombres (HNC) y el clúster virtual.

La propuesta del HNC (KEP) describe una forma de crear relaciones entre padres e hijos entre los espacios de nombres con la herencia de objetos [de política], además de la posibilidad de que los administradores de inquilinos creen subespacios de nombres.

La propuesta de clúster virtual describe un mecanismo para crear instancias independientes de los servicios del plano de control, incluidos el servidor API, el administrador de controladores y el programador, para cada inquilino del clúster (también conocido como «Kubernetes en Kubernetes»).

La propuesta de Multi-Tenancy Benchmarks proporciona directrices para compartir clústeres mediante espacios de nombres para el aislamiento y la segmentación, y una herramienta de línea de comandos kubectl-mtb para validar el cumplimiento de las directrices. https://github.com/kubernetes-sigs/multi-tenancy/blob/master/benchmarks/kubectl-mtb/README.md

Multi-cluster herramientas y recursos de administración