Entendiendo la red Cluster VPC segura por defecto

Virtual Private Cloud 4.15 and later

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 de seguridad y estas reglas se crean automáticamente y se asocian a sus nodos de trabajo, equilibradores 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	Accede 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.

Acceso a la puerta de enlace VPE maestra del clúster desde otra VPC

La puerta de enlace VPE del clúster maestro es utilizada por los nodos de trabajo del clúster y por cualquier recurso de la misma VPC para acceder al servidor API del clúster maestro a través de la red privada. Si necesitas conectarte de forma privada al clúster maestro desde otra VPC de la misma cuenta, puedes crear una puerta de enlace VPE adicional en esa otra VPC que apunte al mismo clúster maestro.

Para ello, utilice el CRN de destino de la puerta de enlace VPE maestra del clúster que crea Red Hat OpenShift on IBM Cloud. Debe proporcionar sus propias direcciones IP reservadas para la nueva puerta de enlace, y debe crear y gestionar el grupo de seguridad y sus reglas. Las reglas de salida en una puerta de enlace VPE no tienen ningún efecto; solo se evalúan las reglas de entrada. Red Hat OpenShift on IBM Cloud no gestiona ni modifica la puerta de enlace VPE ni el grupo de seguridad que crees.

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.
Red Hat OpenShift on IBM Cloud supervisa únicamente las reglas de entrada de TCP y UDP en el rango de puertos del nodo del grupo de seguridad kube-<clusterID>. Si Red Hat OpenShift on IBM Cloud detecta una regla en el rango de puertos de nodo y no existe ningún servicio de puerto de nodo correspondiente, elimina la regla. Para permitir el tráfico entrante hacia un servicio de puerto de nodo, añada la regla necesaria al grupo de seguridad kube-<clusterID> una vez creado el servicio de puerto de nodo, no antes.
Red Hat OpenShift on IBM Cloud ignora las reglas adicionales que se añadan al grupo de seguridad kube-<clusterID> fuera del rango de puertos del nodo y las deja tal cual.
No modifique ni elimine las reglas predeterminadas del 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 plano 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 and later Permite el tráfico saliente hacia la API de metadatos de la 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

El grupo de seguridad de la puerta de enlace VPE compartida se crea al aprovisionar el primer clúster en una VPC. El nombre del grupo de seguridad es kube-vpegw-<vpcID> donde <vpcID> es el ID de tu VPC. Este grupo de seguridad está asociado a todas las puertas de enlace VPE compartidas de la VPC y controla qué recursos pueden enviar tráfico a través de dichas puertas de enlace.

Cada vez que se aprovisiona un clúster adicional en la misma VPC, se añade una única regla remota de entrada a este grupo de seguridad que permite el tráfico procedente del grupo de seguridad de los trabajadores kube-<clusterID> del nuevo clúster. Se crea una regla para cada clúster de la VPC. Si el grupo de seguridad kube-vpegw-<vpcID> ya existe cuando se aprovisiona un clúster, se reconoce y se reutiliza; no se vuelve a crear.

Cada vez que se crea un clúster, también se añaden grupos de seguridad, y una VPC admite un máximo de 100 grupos de seguridad. Este límite se alcanza en torno a los 33 clústeres, por lo que se recomienda un máximo de 25 clústeres por VPC. Para obtener más información, consulta las 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 el objetivo 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>`

Puede añadir reglas de entrada al grupo de seguridad kube-vpegw-<vpcID>, por ejemplo, para permitir que los VSI u otros recursos de su VPC accedan a las puertas de enlace VPE compartidas. Red Hat OpenShift on IBM Cloud no elimina las reglas que añada durante el funcionamiento normal del clúster, ni siquiera cuando se aprovisionen clústeres adicionales en la VPC. Para obtener orientación sobre cómo permitir que los VSI accedan a las puertas de enlace VPE compartidas, consulta ¿Por qué mis VSI no pueden acceder a la puerta de enlace VPE?.

Al ejecutar esta acción, se eliminan ibmcloud oc security-group reset todas las reglas del grupo de seguridad, incluidas las que hayas añadido, y solo se restauran las reglas predeterminadas Red Hat OpenShift on IBM Cloud.

Si tu VPC contiene VSI u otros recursos que necesitan acceder a puntos de conexión compartidos de servicios en la nube (como o icr.io s3.direct) antes de que se aprovisione ningún clúster, puedes crear tú mismo el grupo de seguridad kube-vpegw-<vpcID> y las puertas de enlace VPE compartidas. Cuando posteriormente se aprovisiona un clúster de Red Hat OpenShift on IBM Cloud en la VPC, este detecta el grupo de seguridad existente y lo reutiliza, y añade una nueva regla de entrada para el grupo de seguridad de los trabajadores del nuevo clúster.

Cuando crees tú mismo una puerta de enlace VPE compartida, adjúntale el grupo de seguridad kube-vpegw-<vpcID>. Red Hat OpenShift on IBM Cloud no adjunta automáticamente su grupo de seguridad a las puertas de enlace que no ha creado.

Red Hat OpenShift on IBM Cloud identifica las puertas de enlace VPE compartidas que gestiona mediante el prefijo de su nombre. Las puertas de enlace creadas por Red Hat OpenShift on IBM Cloud utilizan la convención de nomenclatura iks-. Las puertas de enlace VPE compartidas y el grupo de seguridad kube-vpegw-<vpcID> no se eliminan cuando se elimina un clúster de la VPC. Red Hat OpenShift on IBM Cloud no modifica las direcciones IP reservadas de las puertas de enlace VPE compartidas que no haya creado. Si cambias el nombre de una puerta de enlace creada por Red Hat OpenShift on IBM Cloud (eliminando el iks- prefijo), Red Hat OpenShift on IBM Cloud dejará de gestionar las direcciones IP reservadas de dicha puerta de enlace. Esta es la forma recomendada de hacerse cargo de una puerta de enlace creada por Red Hat OpenShift on IBM Cloud sin interrumpir la conectividad existente.

En una configuración de VPC de tipo hub and spoke, en la que las VPC spoke delegan la resolución de DNS a una VPC hub, Red Hat OpenShift on IBM Cloud siempre crea puertas de enlace VPE compartidas en la VPC spoke cuando se aprovisiona un clúster en ella. Esto garantiza la conectividad en caso de que el spoke se desconecte del hub. Si la delegación de DNS redirige los puntos finales de los spokes a través del hub, las puertas de enlace de los spokes no se utilizan para la resolución de DNS. Aún debe configurar los grupos de seguridad en las puertas de enlace VPE compartidas del hub para permitir el tráfico entrante procedente de las subredes VPC de los spokes. Para obtener más información, consulte Consideraciones sobre las VPC de tipo hub and spoke con protección del tráfico saliente.

Grupo de seguridad de servicios de equilibrador de carga

Cada clúster tiene un grupo de seguridad kube-lbaas-<clusterID> asociado a todos sus equilibradores de carga (ALB y NLB). Los NLB de ruta privada no admiten la asignación de grupos de seguridad.

Las reglas de este grupo de seguridad se generan y actualizan dinámicamente a medida que se añaden, actualizan o eliminan equilibradores de carga. Red Hat OpenShift on IBM Cloud supervisa todas las reglas de entrada y salida de este grupo de seguridad y elimina automáticamente cualquier regla adicional que no reconozca como necesaria. Si ejecutas ibmcloud oc security-group reset, se eliminan todas las reglas y solo se restauran las reglas predeterminadas de Red Hat OpenShift on IBM Cloud.

Las reglas de salida de este grupo de seguridad redirigen el tráfico hacia los puertos de los nodos de trabajo a los que están asignados los puertos externos (como los puertos 80 y 443). No modifique ni elimine ninguna regla de salida del grupo de seguridad kube-lbaas-<clusterID>.

Restricción del tráfico entrante a los equilibradores de carga públicos

Una situación habitual es restringir qué direcciones IP de origen pueden enviar tráfico a un equilibrador de carga público. Para limitar el tráfico entrante en un puerto específico (como el puerto TCP 443):

Añade reglas de entrada al grupo de seguridad kube-lbaas-<clusterID> de ese puerto especificando las direcciones IP de origen o los bloques CIDR permitidos. Puede crear varias reglas para permitir varias direcciones IP de origen.
Una vez creadas las reglas de IP de origen permitidas, elimina la regla de entrada predeterminada que permite todas las direcciones IP (0.0.0.0/0) en ese puerto.

Cada puerto de entrada expuesto por el equilibrador de carga debe tener al menos una regla: bien la regla predeterminada que permite todas las direcciones IP, bien una o varias reglas personalizadas de direcciones IP de origen. Si eliminas la regla predeterminada permitir todas las IP sin añadir primero una regla de IP de origen permitida para ese puerto, Red Hat OpenShift on IBM Cloud vuelve a crear automáticamente la regla permitir todas las IP.

Grupos de seguridad personalizados de LBaaS

Si dispone tanto de equilibradores de carga públicos como privados y desea aplicar reglas de cortafuegos diferentes para cada uno (por ejemplo, restringir las direcciones IP de origen para los equilibradores de carga públicos, mientras que permite todo el tráfico hacia los equilibradores de carga privados), puede asociar un grupo de seguridad personalizado a equilibradores de carga específicos utilizando la service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group anotación en lugar de utilizar el valor predeterminado del clúster.

Cuando utilices un grupo de seguridad LBaaS personalizado:

Red Hat OpenShift on IBM Cloud sigue creando automáticamente cualquier regla de entrada necesaria que falte.
Red Hat OpenShift on IBM Cloud nunca elimina las reglas que añadas al grupo de seguridad personalizado.

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.

También puede asociar un grupo de seguridad personalizado a un equilibrador de carga añadiendo la anotación service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group a su recurso de equilibrador de carga. Esto resulta útil si dispone de equilibradores de carga tanto públicos como privados y desea limitar quién puede enviar tráfico al equilibrador de carga público. Cuando utilizas un grupo de seguridad LBaaS personalizado, Red Hat OpenShift on IBM Cloud crea automáticamente reglas para el tráfico entrante, pero no elimina automáticamente las reglas adicionales que añadas. Para obtener más información, consulta Grupos de seguridad personalizados de LBaaS.

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 de trabajo de su clúster VPC se encuentran en una cuenta de servicio y no aparecen en el panel de control de la infraestructura VPC, no puede crear un grupo de seguridad ni aplicarlo a las instancias de sus nodos de trabajo. Solo 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

Cada vez que se crea un clúster, se añaden grupos de seguridad a su VPC, que tiene un máximo de 100 grupos de seguridad. Este límite se alcanza en torno a los 33 clústeres, por lo que se recomienda un máximo de 25 clústeres por VPC. Para obtener más información, consulta las cuotas 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: Cualquiera
Tipo de fuente: Cualquiera
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.