Protección de Container Engine for Kubernetes

Cargas de trabajo que se distribuyen mutuamente

En este momento, no se recomienda ejecutar cargas de trabajo que no sean de confianza mutua en el mismo cluster. Por ejemplo, no debe ejecutar las siguientes cargas de trabajo en el mismo cluster:

• Cargas de trabajo de desarrollo y cargas de trabajo de producción
• Plano de control y plano de datos
• Cargas de trabajo que ejecutan un código de cliente arbitrario

Cargas de trabajo con diferentes niveles de confianza

Considere la posibilidad de tener clusters independientes si tiene varios clientes, equipos o usuarios que acceden al mismo cluster con distintos niveles de confianza. Como se menciona en las secciones siguientes, Kubernetes y OKE ofrecen métodos para aislar las cargas de trabajo. Sin embargo, estos métodos no son actualmente suficientes para la configuración estricta de multi-arrendamiento.

Kubelets tiene acceso de lectura a los recursos

Un kubelet que se ejecuta en un nodo de trabajador en un cluster creado por OKE no puede modificar los recursos que no pertenecen al nodo del kubelet. Para obtener más información, consulte los detalles sobre el controlador de admisión NodeRestriction en la documentación de Kubernetes.

Tenga en cuenta, especialmente cuando se ejecutan cargas de trabajo multi-inquilino, que aunque un kubelet no puede modificar recursos que no pertenecen a su nodo, el kubelet aún puede leer esos recursos. Estos recursos pueden incluir:

• Servicios
• terminales
• nodos
• pods
• secretos, configmaps y volúmenes persistentes enlazados al nodo de kubelet

Para obtener más información, consulte Uso de autorización de nodos en la documentación de Kubernetes.

Compartimentos de pools de nodos

Los pools de nodos de un cluster pueden abarcar compartimentos. Sin embargo, si bien el uso de varios compartimentos ofrece una manera práctica de agrupar y gestionar nodos de trabajo, no proporciona ningún tipo de aislamiento entre los nodos de trabajo del cluster. Se puede programar cualquier carga de trabajo en cualquier pool de nodos, independientemente del compartimento. Un caso de uso válido para usar más de un compartimento para un pools de nodos sería crear fácilmente grupos dinámicos y políticas de IAM para nodos de trabajo. Un caso de uso no válido para varios compartimentos sería colocar cada pool de nodos que ejecuta una carga de trabajo del cliente en un compartimento independiente bajo la suposición de que los compartimentos proporcionan algún tipo de aislamiento o límite de seguridad.

Subredes de pool de nodos

Se recomienda utilizar únicamente subredes privadas para los pools de nodos. Se debe configurar un gateway de servicio para proporcionar acceso a los servicios de Oracle Cloud Infrastructure. No se puede utilizar un gateway de servicio si las subredes son públicas con un gateway de Internet. Si sus subredes privadas requieren acceso a Internet, utilice un gateway NAT.

Control de a qué pods de nodos puede acceder

Por defecto, se puede programar un pod en cualquier nodo del cluster. Kubernetes ofrece un amplio conjunto de políticas para controlar la ubicación de los pods en los nodos y la ubicación y expulsión de pods basada en marcado que estén disponibles para los usuarios finales. Para muchos clusters, el uso de estas políticas para separar cargas de trabajo puede ser una convención que los autores adoptan o aplican mediante herramientas. Estos controles de ubicación no son adecuados en un entorno multiinquilino cuando los usuarios con capacidades de despliegue no son de confianza. Si hay usuarios que no son de confianza que despliegan código, debe considerar un cluster por grupo que no es de confianza.

Límite del acceso especificado a principales de instancia

Por defecto, todos los pods de un nodo pueden acceder a los certificados principales de la instancia mediante el punto final de metadatos de la instancia. Para evitar la escalada de privilegios a través de principales de instancia, debe aislar las cargas de trabajo entre los pools de nodos con distintos grupos dinámicos para que los pods de un pool de nodos determinado tengan el conjunto mínimo de privilegios necesarios para la función.

Por ejemplo, suponga que tiene las dos siguientes cargas de trabajo y que ambas requieren acceso distinto:

• LogArchiver: necesita acceso para gestionar bloques y objetos de Object Storage
• HostMonitor: necesita acceso a la API de Compute para gestionar instancias

El enfoque más sencillo sería programarlo en el mismo pool de nodos y proporcionar el principal de la instancia con todos los accesos necesarios. Sin embargo, esto aumenta el impacto en el caso de que una de las cargas de trabajo se vea comprometida. Un mejor enfoque sería programar las cargas de trabajo en pools de nodos independientes con el conjunto limitado de acceso que los principales de instancias requieren para la carga de trabajo aplicable.

Bloqueo del acceso de contenedor a los metadatos de la instancia

El método preferido de bloquear el acceso es utilizando un plugin de política de red con una política por defecto de tipo "denegar todo". A continuación, se otorga explícitamente acceso a pods y redes que utilizan recursos de NetworkPolicy en Kubernetes mediante selectores de etiquetas. Si no tiene instalado un plugin de política de red, puede utilizar una regla IPTables para restringir el acceso de todos los pods del host. Le recomendamos que no utilice este enfoque para bloquear un subconjunto de pods en un host.

Importante: NetworkPolicys y la siguiente regla de IPTable solo se aplican a los contenedores de la red de superposición de pod. Los contenedores y los servicios que se ejecutan en la red del host no se ven afectados por ninguna de las siguientes opciones:

iptables --insert FORWARD 1 --in-interface veth+ --destination 169.254.0.0/16 --jump DROP

Políticas de red

Las políticas de red de Kubernetes permiten a los administradores definir cómo los grupos de pods se pueden comunicar con otros pods del cluster. Además, las políticas de red le permiten definir la forma en que los grupos de pods se pueden comunicar con servicios fuera del cluster (por ejemplo, servicios de Oracle Cloud Infrastructure ).

Para restringir el acceso mediante políticas de red, necesita instalar un plugin de red. Los plugins de red configuran y aplican las políticas de red definidas en Kubernetes. Numerosas opciones de complementos de red están disponibles. Puede seguir estas instrucciones que le ofrecemos para instalar y configurar Calico en el cluster. Los plugins de políticas de red funcionan restringiendo el acceso al host. Para obtener información sobre la instalación de Calico en OKE, consulte Ejemplo: instalación de Calico y configuración de políticas de red.

Listas de seguridad del pool de nodos

Los administradores de la red pueden definir reglas de listas de seguridad en subredes de pools de nodos para restringir el acceso a nodos de trabajo y desde ellos. La definición de reglas de listas de seguridad permite a los administradores aplicar restricciones de red que no se pueden sustituir en los hosts del cluster.

Dado que toda la comunicación entre los podes se produce en una red de superposición de VXLAN en los nodos de trabajo, no puede usar reglas de la lista de seguridad para restringir la comunicación entre los pods. Sin embargo, puede usar listas de seguridad para restringir el acceso a los nodos de trabajo y desde ellos.

Importante: Debe existir un conjunto mínimo de reglas de listas de seguridad en subredes de pools de nodos para garantizar que el cluster pueda funcionar. Consulte Configuración de recursos de red de ejemplo para obtener información sobre el conjunto mínimo de reglas de listas de seguridad antes de modificar las reglas de listas de seguridad.

Uso de resúmenes de imágenes en lugar de etiquetas

Se recomienda recuperar solo imágenes mediante resúmenes de imagen y no utilizando etiquetas (ya que las etiquetas de imagen se pueden modificar). Los resúmenes de imágenes son el resumen sha256 de la imagen, que permite a docker verificar que la imagen descargada es la que esperaba.

ID de resumen de imagen de ejemplo:

sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Recupere la imagen como se muestra en el siguiente ejemplo:

docker pull acme@sha256:77af4d6b9913e693e8d0b4b294fa62ade6054e6b2f1ffb617ac955dd63fb0182

Puede utilizar el siguiente comando para mostrar todos los resúmenes de las imágenes locales:

docker images --digests

Limitación del uso de recursos

La cuota de recursos limita el número o la capacidad de recursos otorgados a un espacio de nombres. Esto se suele utilizar para limitar la cantidad de CPU, memoria o disco persistente que puede asignar un espacio de nombres, pero también puede controlar cuántos pods, servicios o volúmenes existen en cada espacio de nombres.

Los rangos de límites restringen el tamaño máximo o mínimo de algunos de los recursos anteriores para evitar que los usuarios soliciten valores demasiado altos o bajos para recursos que se suelen reservar, como la memoria, o para proporcionar límites por defecto cuando no se especifique ninguno.

El acceso a cuotas de recursos se puede restringir mediante políticas de RBAC en Kubernetes. Esto puede ayudar a un administrador a garantizar que los usuarios de un cluster no puedan utilizar recursos a los que no deban tener acceso. Consulte Limitación del uso de recursos en un cluster en la documentación de Kubernetes para obtener más información.