Entendiendo la red Cluster VPC segura por defecto

Nube privada virtual 4.15 y más tarde

A partir de los nuevos clústeres VPC que se crean en la versión 4.15, Red Hat OpenShift on IBM Cloud introdujo una nueva función 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 siguientes detalles sobre los componentes de la VPC que se crean y gestionan para usted cuando crea un clúster de la versión 4.15 y posteriores.

Visión general

Con Secure by Default Networking, cuando suministra un nuevo clúster de VPC Red Hat OpenShift on IBM Cloud en la versión 4.15 o posterior, solo se permite el tráfico necesario para que funcione el clúster y se bloquea el resto del acceso. Para implementar Secure by Default Networking, Red Hat OpenShift on IBM Cloud utiliza varios grupos de seguridad y reglas de grupo de seguridad para proteger los componentes del 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 de 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 Red Hat OpenShift on IBM Cloud 4.14+ en una VPC determinada, o un clúster en el que la VPC tiene su maestro actualizado a 4.14+, se crean varias pasarelas 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 VPE compartidas se les asigna una única IP reservada de cada zona en la que se encuentran los trabajadores del clúster.

Pasarelas VPE compartidas

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

Pasarelas VPE compartidas
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. La tercera columna incluye los nombres DNS.
Pasarela VPE	Descripción	nombres DNS
IBM Cloud Container Registry	Extraiga imágenes de contenedores de IBM Cloud Container Registry para las aplicaciones que se ejecutan en su clúster.	`icr.io`, `*.icr.io`
Pasarela IBM Cloud Object Storage s3	Acceda a las API de IBM Cloud Object Storage.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
Pasarela de configuración de IBM Cloud Object Storage	Copia de seguridad de imágenes de contenedor en IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (ca-mon, in-che, in-mum)	Acceda a las API de Red Hat OpenShift on IBM Cloud para crear clústeres, añadir grupos de trabajadores y mucho más.	`private.<region>.containers.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (otras regiones)	Acceda a las API de Red Hat OpenShift on IBM Cloud para crear clústeres, añadir grupos de trabajadores y mucho más.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	Acceda a las API de VPC para aprovisionar y gestionar los recursos que forman parte de la infraestructura como servicio de VPC ( IaaS ).	`<region>.private.iaas.cloud.ibm.com`

Pasarelas VPE no compartidas

Todos los clústeres de VPC compatibles tienen un VPE Gateway para el maestro del clúster que se crea en su cuenta cuando se crea el clúster.

Pasarelas VPE no compartidas
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
Red Hat OpenShift on IBM Cloud maestro de 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 este Gateway VPE se le asigna una única IP Reservada de cada zona en la que se encuentran los cluster workers, y esta IP se crea en una de las subredes VPC de esa zona que tiene cluster workers. †

† Por ejemplo, si el clúster tiene trabajadores en una única región de zona (us-east-1) y una única subred VPC, entonces 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

Red Hat OpenShift on IBM Cloud crea y actualiza automáticamente los siguientes grupos de seguridad y reglas para clústeres de VPC.

Grupos de seguridad gestionados
La tabla muestra los grupos de seguridad gestionados creados para clusters VPC. La primera columna incluye el nombre del grupo de seguridad. La segunda columna incluye la convención de nomenclatura.
Grupo de seguridad	Convenio de denominación
Grupo de seguridad de trabajadores	`kube-<clusterID>`
Grupo de seguridad del gateway VPE maestro	`kube-vpegw-<clusterID>`
Grupo de seguridad de puerta de enlace VPE compartida	`kube-vpegw-<vpcID>`
Grupo de seguridad de los servicios del equilibrador de carga	`kube-lbaas-<clusterID>`

Grupo de seguridad de trabajador

Cuando se crea un clúster VPC en Red Hat OpenShift on IBM Cloud, se crea un grupo de seguridad para todos los trabajadores, o nodos, del clúster en cuestión.

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.
Los equilibradores de carga añaden o eliminan reglas de forma dinámica en función de las necesidades.
Las reglas que se añaden en el rango de puertos del nodo se eliminan automáticamente si no son necesarias. Si los clientes quieren permitir el tráfico entrante a un servicio de puerto de nodo, debe añadir la regla para permitir el tráfico después de crear el servicio de puerto de nodo.
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 clúster. 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 norma.
Descripción	Dirección	Protocolo	Puertos o valores	Origen o destino
Permite el tráfico de entrada a la subred de pod.	Entrada	ICMP/ TCP / UDP	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	ICMP/ TCP / UDP	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	ICMP/ TCP / UDP	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 que permite que se suministren los trabajadores.	De salida	ICMP/ TCP / UDP	Todos	161.26.0.0/16
Permite el acceso de salida a sí mismo, lo que permite la comunicación de trabajador a trabajador.	De salida	ICMP/ TCP / UDP	Todos	`kube-<clusterID>`
Permite el tráfico de salida al grupo de seguridad de pasarela VPE maestro.	De salida	ICMP/ TCP / UDP	Todos	`kube-vpegw-<clusterID>`
Permite el tráfico de salida al grupo de seguridad de pasarela VPE compartido.	De salida	ICMP/ TCP / UDP	Todos	`kube-vpegw-<vpcID>`
Permite el tráfico al punto final público a través del puerto oauth para todas las zonas de la MZR donde se encuentra el clúster.`*`	De salida	TCP	Puerto Oauth	IP de punto final público para todas las zonas de la MZR.
Permite el tráfico TCP a través del ALB de entrada	De salida	TCP	Ports:Min=443,Max=443	Dirección IP pública de ALB `n`
Permite el tráfico de TCP y UDP a través del resolver 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	ICMP/ TCP / UDP	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	ICMP/ TCP / UDP	Todos	Dirección IP de punto final privado de IAM para todas las zonas.
Permite el tráfico saliente a la API de metadatos de instancia.	De salida	ICMP/ TCP / UDP	Todos	169.254.169.254
4.18 y posteriores Permite el tráfico saliente a la API de metadatos de instancia.	De salida	ICMP/ TCP / UDP	Todos	169.254.169.254

* Estas reglas sólo se añaden a los clústeres con puntos finales de servicio público habilitados para permitir el acceso a la consola web OpenShift y al punto final público a través del puerto OAuth. Se añade una regla para cada zona de la región multizona (MZR) donde se encuentra el clúster. Si el clúster está en una MZR con 3 zonas, se crean 3 reglas.

** 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

Cuando crea 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 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 cluster worker. 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	Puertos o valores	Origen o destino
Permite 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>`
Permite el tráfico de entrada desde el grupo de seguridad de trabajador de clúster al puerto openVPN o Konnectivity.	Entrada	TCP	Puerto de Konnectivity	`kube-<clusterID>`
Permite el tráfico de entrada desde el grupo de seguridad de trabajador del clúster al puerto de Oauth.	Entrada	TCP	Puerto Oauth	`kube-<clusterID>`
CoreOS-enabled. Permite el tráfico de entrada desde el grupo de seguridad de nodos trabajadores del clúster al puerto del servidor de encendido	Entrada	TCP	Puerto de servidor de Ignition	`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
Permite el tráfico entrante desde la subred de cada grupo de trabajadores activo de su clúster.`*`	Entrada	TCP	OAuth puerto	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. Por defecto, Red Hat OpenShift on IBM Cloud aplica 1 regla dirigida al 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).

Cada clúster obtiene su propio grupo de seguridad exclusivo que comparten todos los equilibradores de carga del clúster.
El nombre del grupo de seguridad es kube-lbaas-<clusterID> donde <clusterID> es el ID de su clúster.
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.
Puede añadir reglas a este grupo de seguridad. Sin embargo, algunas normas podrían eliminarse si son incompatibles con las demás o si rompen la funcionalidad.

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

Proporcionado por el usuario Security Groups

Al crear un clúster de VPC, puede proporcionar hasta cuatro grupos de seguridad adicionales de su propiedad.

Para obtener más información, consulte Creación y gestión de grupos de seguridad de VPC.

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 4.15 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 los clústeres sin acceso a la red pública, este proceso falla. eBPF está ahora activado por defecto para los nuevos despliegues de Sysdig. No obstante, si experimenta problemas en un clúster existente, compruebe si eBPF está activado y actívelo si es necesario. Como alternativa, puede permitir el tráfico saliente o consultar la documentación de Sysdig para instalar el agente en entornos con air-gapped.

Cuotas de clúster de VPC

Cifrado en tránsito para VPC File Storage.

Para utilizar el IET con clusters seguros por defecto, debe añadir la siguiente regla de salida al grupo de seguridad kube-<clusterID>.

Protocolo: Cualquier
Tipo de fuente: Cualquier
Fuente: 0.0.0.0/0
Destino 169.254.169.254.

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 del 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.