Entendiendo la red Cluster VPC segura por defecto

Nube privada virtual 1.30 y posteriores

A partir de los nuevos clústeres de VPC creados en la versión 1.30, IBM Cloud Kubernetes Service ha introducido una nueva característica de seguridad denominada Secure by Default Cluster VPC Networking. Con Secure by Default, hay nuevos valores de VPC como, por ejemplo, grupos de seguridad gestionados, reglas de grupo de seguridad y pasarelas de punto final privado virtual (VPE) que se crean automáticamente al crear un clúster de VPC. Revise los detalles siguientes sobre los componentes de VPC que se crean y gestionan automáticamente al crear un clúster de la versión 1.30 y posterior.

Visión general

Con Secure by Default Networking, cuando suministra un nuevo clúster de VPC IBM Cloud Kubernetes Service en la versión 1.30 o posterior, solo se permite el tráfico necesario para que funcione el clúster y se bloquea todo el resto del acceso. Para implementar Secure by Default Networking, IBM Cloud Kubernetes Service utiliza varios grupos de seguridad y reglas de grupo de seguridad para proteger los componentes de clúster. Estos grupos y reglas de seguridad se crean automáticamente y se adjuntan a sus nodos trabajadores, balanceadores de carga y puertas de enlace VPE relacionadas con el clúster.

Los grupos de seguridad de nube privada virtual filtran el tráfico a nivel de hipervisor. Las reglas de grupo de seguridad no se aplican en un orden determinado. Sin embargo, las solicitudes a los nodos trabajadores solo se permiten si la solicitud coincide con una de las reglas que especifique. Si permite el tráfico en una dirección mediante la creación de una regla de entrada o de salida, también se permiten respuestas en la dirección opuesta. Los grupos de seguridad son aditivos, lo que significa que si los nodos trabajadores están conectados a más de un grupo de seguridad, todas las reglas incluidas en los grupos de seguridad se aplican a los nodos trabajadores. Las versiones de clúster más recientes pueden tener más reglas en el grupo de seguridad kube-<clusterID> que las versiones de clúster más antiguas. Se añaden reglas de grupo de seguridad para mejorar la seguridad del servicio y no interrumpir la funcionalidad.

Pasarelas de punto final privado virtual (VPE)

Cuando se crea el primer clúster de VPC en IBM Cloud Kubernetes Service 1.28+ en una VPC determinada, o un clúster en el que la VPC tiene su maestro actualizado a 1.28+, se crean varias pasarelas de VPE compartidas para diversos servicios de IBM Cloud. Solo se crea uno de cada uno de estos tipos de pasarelas VPE compartidas por VPC. Todos los clústeres de la VPC comparten la misma pasarela VPE para estos servicios. A estas pasarelas de VPE compartidas se les asigna una única IP reservada de cada zona en la que se encuentran los trabajadores del clúster.

Las siguientes pasarelas de VPE se crean automáticamente al crear un clúster de VPC.

Pasarelas VPE
La tabla muestra los gateways VPE creados para los clusters VPC. La primera columna incluye el nombre de la pasarela. La segunda columna incluye una breve descripción.
Pasarela VPE	Descripción
IBM Cloud Container Registry	Compartido Extraer imágenes de contenedor de IBM Cloud Container Registry a apps que se ejecutan en el clúster.
Pasarela IBM Cloud Object Storage s3	Compartido Acceda a las API de COS.
Pasarela de configuración de IBM Cloud Object Storage	Imágenes de contenedor de copia de seguridad de compartidas en IBM Cloud Object Storage
IBM Cloud Kubernetes Service	Acceda a las API de IBM Cloud Kubernetes Service para interactuar con el clúster y gestionarlo. †

† Todos los clústeres de VPC soportados tienen una pasarela VPE para el maestro de clúster que se crea en la cuenta cuando se crea el clúster. Esta pasarela de VPE la utilizan los trabajadores de la agrupación y la pueden utilizar otros elementos de la VPC para conectarse al servidor de API maestro de la agrupación. A esta pasarela de VPE se le asigna una única IP reservada de cada zona en la que se encuentran los trabajadores del clúster, y esta IP se crea en una de las subredes de VPC de esa zona que tiene trabajadores del clúster. Por ejemplo, si el clúster tiene trabajadores en una única región de zona (us-east-1) y una única subred de VPC, se crea una única IP en esa subred y se asigna al Gateway VPE. Si un clúster tiene nodos trabajadores en las tres zonas como us-east-1, us-east-2 y us-east-3 y estos nodos trabajadores se reparten entre 4 subredes de VPC en cada zona, se crean 12 subredes de VPC en total, tres IP, una en cada zona, en una de las cuatro subredes de VPC en esa zona. Tenga en cuenta que la subred se elige de forma aleatoria.

Grupos de seguridad gestionados

IBM Cloud Kubernetes Service crea y actualiza automáticamente los siguientes grupos de seguridad y reglas para clústeres de VPC.

Grupo de seguridad de trabajadores (kube-<clusterID>).
Grupo de seguridad del gateway VPE maestro (kube-vpegw-<clusterID>).
Grupo de seguridad de pasarela VPE compartida (kube-vpegw-<vpcID>).
Grupo de seguridad de los servicios del equilibrador de carga (kube-lbaas-<clusterID>).

Grupo de seguridad de trabajador

Cuando crea un clúster de VPC IBM Cloud Kubernetes Service, se crea un grupo de seguridad para todos los trabajadores, o nodos, para el clúster determinado. El nombre del grupo de seguridad es kube-<clusterID> donde <clusterID> es el ID del clúster. Si posteriormente se añaden nuevos nodos al clúster, estos nodos se añaden automáticamente al grupo de seguridad del clúster.

No modifique las reglas en el grupo de seguridad kube-<clusterID> ya que hacerlo podría provocar interrupciones en la conectividad de red entre los trabajadores del clúster y el clúster de control.

Reglas del grupo de seguridad kube-clusterID
La tabla muestra las reglas aplicadas al grupo de seguridad de trabajadores de cluster. La primera columna incluye el protocolo de la regla. La segunda columna incluye los puertos y tipos. La tercera columna incluye el destino remoto de la regla. La cuarta columna incluye una breve descripción de la regla.
Descripción	Dirección	Protocolo	Puertos o valores	Origen o destino
Permite el tráfico de entrada a la subred de pod.	Entrada	Todos	Todos	172.17.0.0/18 (el rango de subred predeterminado) o un rango de subred personalizado que especifique al crear el clúster.
Permite el acceso de entrada a sí mismo, lo que permite la comunicación de trabajador a trabajador.	Entrada	Todos	Todos	`kube-<clusterID>`
Permite el acceso ICMP (ping) de entrada.	Entrada	ICMP	type=8	0.0.0.0/0
Permite el tráfico entrante desde nodeports abiertos por sus balanceadores de carga (ALBs/NLBs). A medida que se añaden o eliminan equilibradores de carga, las reglas se añaden o eliminan dinámicamente.	Entrada	TCP	Puertos de nodo de equilibrador de carga.	`kube-lbaas-<clusterID>`
Permite el tráfico de salida a la subred de pod.	De salida	Todos	Todos	172.17.0.0/18 (el rango de subred predeterminado) o un rango de subred personalizado que especifique al crear el clúster.
Permite el tráfico de salida al plano de control maestro, lo que permite que se suministren los trabajadores.	De salida	Todos	Todos	161.26.0.0/16
Permite el acceso de salida a uno mismo, lo que permite la comunicación de trabajador a trabajador.	De salida	Todos	Todos	`kube-<clusterID>`
Permite el tráfico de salida al grupo de seguridad de pasarela VPE maestro.	De salida	Todos	Todos	`kube-vpegw-<clusterID>`
Permite el tráfico de salida al grupo de seguridad de pasarela VPE compartido.	De salida	Todos	Todos	`kube-vpegw-<vpcID>`
Permite el tráfico TCP a través del ALB de Ingress	De salida	TCP	Ports:Min=443,Max=443	Dirección IP pública de ALB `n`
Permite el tráfico TCP y UDP a través del programa de resolución de DNS personalizado para la zona `n`.`**`	De salida	TCP/UDP	Min=53,Max=53	Dirección IP del programa de resolución de DNS en la zona `n`.
Permite el tráfico a todo el rango de servicio CSE.	De salida	Todos	Todos	166.8.0.0/14
Permite el tráfico al punto final privado de IAM para todas las zonas. Las IP pueden variar según la región. Se añade una regla por zona en la que se encuentra el clúster.	De salida	Todos	Todos	Dirección IP de punto final privado de IAM para todas las zonas.
4.18 y posteriores Permite el tráfico saliente a la API de metadatos de instancia.	De salida	Todos	Todos	169.254.169.254

** Hub y Spoke VPC utilizan programas de resolución DNS personalizados en la VPC. El tráfico debe fluir a través de las direcciones IP de cada programa de resolución de DNS. Hay dos reglas por zona (TCP y UDP) a través del puerto 53.

Grupo de seguridad de pasarela VPE maestra

Al crear un clúster de VPC, se crea una pasarela de punto final privado virtual (VPE) en la misma VPC que el clúster. El nombre de la seguridad es kube-vpegw-<clusterID> donde <clusterID> es el ID del clúster. El propósito de esta puerta de enlace VPE es servir como puerta de enlace al maestro de clúster que es administrado por IBM Cloud. A la pasarela VPE se le asigna una única dirección IP en cada zona de la VPC en la que el clúster tiene trabajadores.

Para permitir el acceso al maestro de un clúster solo desde sus nodos trabajadores, se crea un grupo de seguridad para cada pasarela de VPE maestra de clúster. A continuación, se crea una regla remota que permite la conectividad de Ingress desde el grupo de seguridad de trabajador de clúster a los puertos necesarios en la pasarela VPE maestra de clúster. Para que las conexiones privadas, incluidas las conexiones que llegan a través de una VPN de VPC, se conecten a la puerta de enlace VPE del punto final de servicio privado del clúster, se permite el tráfico TCP desde los CIDR de subred para cada grupo de trabajadores activo de su clúster.

Reglas de entrada en el grupo de seguridad del gateway VPE maestro
La tabla muestra las reglas de entrada aplicadas al grupo de seguridad del gateway VPE maestro. La primera columna incluye el protocolo de la regla. La segunda columna incluye los puertos y tipos. La tercera columna incluye el destino remoto de la regla. La cuarta columna incluye una breve descripción de la regla.
Descripción	Dirección	Protocolo	Puertos o valores	Origen o destino
Permitir el tráfico de entrada desde el grupo de seguridad de trabajador del clúster al puerto de nodo del servidor.	Entrada	TCP	Servidor URL puerto de nodo	`kube-<clusterID>`
Permitir el tráfico de entrada desde el grupo de seguridad de trabajador de clúster al puerto de Konnectivity.	Entrada	TCP	Puerto de Konnectivity	`kube-<clusterID>`
Permite el tráfico entrante desde la subred de cada grupo de trabajadores activo de su clúster.`*`	Entrada	TCP	Servidor URL puerto de nodo	CIDR de subred

* Se añade una regla para la subred de cada grupo de trabajadores activo. Si tiene trabajadores en tres zonas, se añadirán tres reglas (una para cada subred de esa zona).

Grupo de seguridad de pasarela VPE compartido

Las puertas de enlace VPE compartidas se crean cuando se provisioned.The grupo de seguridad de puerta de enlace VPE compartida se crea al crear un clúster (si no existe ya de clústeres anteriores). El nombre del grupo de seguridad es kube-vpegw-<vpcID> donde <vpcID> es el ID de tu VPC. A continuación, se crea una regla remota que permite la conectividad de Ingress desde el grupo de seguridad de trabajador de clúster para el clúster determinado. El grupo de seguridad de pasarela de VPE compartido contiene las pasarelas de VPE compartidas por todos los clústeres de dicha VPC. Es posible que en versiones posteriores se añadan pasarelas VPE compartidas para permitir conexiones a otros IBM Cloud.

Si este grupo de seguridad de pasarela VPE compartido ya existe cuando se suministra un clúster, el proceso de suministro lo reconoce y no se vuelve a crear. Sin embargo, todavía se añade una regla remota entre el grupo de seguridad de pasarela de VPE compartido existente y el nuevo grupo de seguridad de trabajador. Esto se hace para que se permita la conectividad desde todos los clústeres de la VPC determinada. Se crea una regla para cada clúster de la VPC.

Hay un máximo de 15 reglas que pueden dirigirse a otros grupos de seguridad como origen o destino. De forma predeterminada, IBM Cloud Kubernetes Service aplica 1 regla que tiene como destino el grupo de seguridad kube-<clusterID> para cada clúster de la VPC. Debido a esta cuota, solo se pueden crear 15 clústeres en una VPC determinada. Para obtener más información, consulte Cuotas de VPC.

Reglas de entrada en el grupo de seguridad compartido del gateway VPE
La tabla muestra las reglas de entrada aplicadas al grupo de seguridad compartido del gateway VPE. La primera columna incluye la finalidad de la norma. La segunda columna incluye la dirección de la regla. La tercera columna incluye el protocolo. La cuarta columna incluye el destino remoto de la regla.
Descripción	Dirección	Protocolo	Origen o destino
Permite el tráfico de entrada desde el clúster especificado.	Entrada	TCP	`kube-<clusterID>`

Grupo de seguridad de servicios de equilibrador de carga

El grupo de seguridad predeterminado que está conectado a todos los equilibradores de carga (ALB y NLB). El nombre del grupo de seguridad es kube-lbaas-<clusterID> donde <clusterID> es el ID de su clúster. Cada clúster obtiene su propio grupo de seguridad exclusivo que comparten todos los equilibradores de carga del clúster. El ejemplo siguiente muestra las reglas añadidas al grupo de seguridad del equilibrador de carga por un clúster que utiliza un único ALB. Las reglas de este grupo de seguridad se añaden o suprimen dinámicamente a medida que se añaden, eliminan o actualizan los equilibradores de carga. Tenga en cuenta que los SDNLB no dan soporte a la conexión de grupos de seguridad.

Reglas del grupo de seguridad del equilibrador de carga
La tabla muestra las reglas aplicadas al grupo de seguridad del equilibrador de carga. La primera columna incluye la finalidad de la regla. La segunda columna incluye la dirección de la regla. La tercera columna incluye el protocolo. La cuarta columna incluye los puertos o valores. La quinta columna incluye el destino remoto de la regla.
Descripción	Dirección	Protocolo	Puerto o valor	Origen o destino
Permite el acceso de salida al puerto de nodo abierto por el equilibrador de carga. En función del equilibrador de carga, es posible que tenga varias reglas.	De salida	TCP	Node puerto (s) abierto (s) por el equilibrador de carga.	`kube-<clusterID>`
El equilibrador de carga escucha en el puerto 80 permitiendo el acceso de entrada desde ese puerto.	Entrada	TCP	Puerto LB público. Ejemplo `80`	0.0.0.0/0
El equilibrador de carga escucha en el puerto 443 permitiendo el acceso de entrada desde ese puerto.	Entrada	TCP	Puerto LB público. Ejemplo `443`	0.0.0.0/0

Limitaciones

Grupos de seguridad de nodo trabajador: Dado que los nodos trabajadores de su clúster VPC existen en una cuenta de servicio y no aparecen en el panel de control de la infraestructura VPC, no puede crear un grupo de seguridad y aplicarlo a sus instancias de nodos trabajadores. Sólo puede modificar el grupo de seguridad kube-<clusterID> existente.
Registro y supervisión: Al configurar el registro y la supervisión en un clúster 1.30 o posterior, debe utilizar el punto final de servicio privado al instalar el agente de registro en el clúster. Los datos de registro no se guardan si se utiliza el punto final público.
Supervisión de clústeres con nodos trabajadores RHCOS: El agente de supervisión se basa en cabeceras de kernel en el sistema operativo, sin embargo, RHCOS no tiene cabeceras de kernel. En este escenario, el agente vuelve a sysdig.com para utilizar el agente precompilado. En clústeres sin acceso de red pública, este proceso falla. Para permitir la supervisión en clústeres RHCOS, debe permitir el tráfico de salida o consultar la documentación de Sysdig para instalar el agente en entornos aislados.
Cuotas de clúster de VPC: Hay un máximo de 15 reglas que pueden dirigirse a otros grupos de seguridad como origen o destino. De forma predeterminada, IBM Cloud Kubernetes Service aplica 1 regla que tiene como destino el grupo de seguridad kube-<clusterID> para cada clúster de la VPC. Debido a esta cuota, solo se pueden crear 15 clústeres en una VPC determinada. Para obtener más información, consulte Cuotas de VPC.
Comunicación de copia de seguridad a través de la red pública: Los trabajadores de clúster de VPC utilizan la red privada para comunicarse con el maestro de clúster. Anteriormente, para los clústeres de VPC que tenían el punto final de servicio público habilitado, si la red privada estaba bloqueada o no estaba disponible, los trabajadores del clúster podían volver a utilizar la red pública para comunicarse con el maestro del clúster. En los clústeres Secure by Default, volver a la red pública no es una opción porque el tráfico de salida público de los trabajadores del clúster está bloqueado. Es posible que desee inhabilitar la protección de tráfico de salida para permitir esta opción de copia de seguridad de red pública, sin embargo, existe una alternativa mejor. En su lugar, si hay un problema temporal con la conexión de trabajador a maestro a través de la red privada, entonces, en ese momento, puede añadir una regla de grupo de seguridad temporal al grupo de seguridad kube-clusterID para permitir el tráfico de salida al puerto apiserver maestro del clúster. Más adelante, cuando se resuelva el problema, puede eliminar la regla temporal.
Cifrado de OpenShift Data Foundation y Portworx: Si tiene previsto utilizar OpenShift Data Foundation o Portworx en un clúster sin acceso de red pública y desea utilizar Hyper Protect Crypto Services o Key Protect para el cifrado, debe crear una pasarela de punto final privado virtual (VPE) que permita el acceso a la instancia de KMS. Asegúrese de enlazar al menos 1 dirección IP de cada subred de la VPC con la VPE.