Gestión de la protección del tráfico saliente en clusters VPC

Nube privada virtual 4.15 y más tarde

Revise las siguientes opciones para gestionar la protección del tráfico saliente en Red Hat OpenShift on IBM Cloud Clústeres VPC. Puede permitir todo el acceso saliente o permitir selectivamente el tráfico saliente a los componentes que sus aplicaciones necesitan.

En muchos de los siguientes escenarios, tiene la opción de añadir reglas personalizadas a su grupo de seguridad ' kube-<clusterID> ' como una forma de permitir el tráfico saliente a recursos específicos. Tenga en cuenta que las reglas que añada al grupo de seguridad " kube-<clusterID> " se eliminarán si posteriormente ejecuta " ibmcloud oc security-group reset. Al restablecer los grupos de seguridad, se restauran las reglas predeterminadas y se eliminan las que hayas añadido.

Desactivación de la protección del tráfico saliente

Nube privada virtual 4.15 y más tarde

Revise las siguientes opciones para desactivar las protecciones de tráfico saliente para nuevos clusters.

Puede activar y desactivar la protección del tráfico saliente mediante los comandos outbound traffic protection enable y disable. Es posible que desee cambiar entre las dos configuraciones cuando se está alejando de permitir todo el tráfico saliente.

Opción 1: Desactivar la protección del tráfico saliente al crear un clúster

Esta opción permite todas las conexiones de red salientes.

  • En la consola, seleccione la opción Permitir tráfico saliente.
  • En la CLI, cuando cree un clúster mediante el comando" cluster create vpc-gen2 ", especifique la opción " --disable-outbound-traffic-protection ".
  • En Terraform, especifique la opción " disable_outbound_traffic_protection = true ".
  • En la API, especifique la opción " disableOutboundTrafficProtection=true ".

Opción 2: Permitir el tráfico saliente a través de un grupo de seguridad personalizado

Antes de crear su clúster, cree un grupo de seguridad personalizado en su VPC que permita el acceso al sitio o servicio externo al que su clúster necesita acceder. A continuación, adjunte este grupo de seguridad a su clúster durante la creación del mismo.

  • En la consola, especifique su grupo de seguridad personalizado.
  • En la CLI, cuando cree un clúster mediante el comando" cluster create vpc-gen2 ", especifique la opción " --cluster-security-group <security-group-ID> " e incluya su ID de grupo de seguridad personalizado.
  • En Terraform, especifique la opción " security_groups " e incluya su grupo personalizado.

Desactivación de la protección del tráfico saliente para los clusters existentes

Nube privada virtual 4.15 y más tarde

Revise sus opciones para desactivar la protección del tráfico saliente después de haber aprovisionado un clúster.

Opción 1: Desactivar la protección del tráfico saliente desde la CLI

Esta opción permite todas las conexiones de red externas.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Opción 2: Añadir una regla de grupo de seguridad al grupo de seguridad predeterminado del trabajador del clúster

Puede añadir una regla de grupo de seguridad al grupo de seguridad del trabajador del clúster (kube-<clusterID>) que permita el acceso al sitio externo específico. Repita este paso para cada sitio o subred al que su cluster necesite acceder. Para más información, Ejemplo de escenarios para permitir selectivamente el tráfico saliente.

ibmcloud is sg-rulec kube-CLUSTERID outbound icmp_tcp_udp --remote IP-ADDRESS-OR-SUBNET

Activación de la protección del tráfico saliente para los clústeres existentes

Nube privada virtual 4.15 y más tarde

Para activar la protección de salida para sus clusters 4.15 existentes, ejecute el siguiente comando. Tenga en cuenta que la activación de la protección del tráfico saliente bloquea todo el tráfico saliente.

ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER

Ejemplos de escenarios para permitir selectivamente el tráfico saliente

Revise las siguientes secciones para obtener instrucciones sobre cómo permitir el tráfico saliente a recursos y componentes comunes tales como registros de contenedores externos como ' quay.io, Red Hat Marketplace y OperatorHub. Tenga en cuenta que cuando permita selectivamente el tráfico saliente creando reglas de grupo de seguridad personalizadas, sus cambios se eliminarán si restablece su grupo de seguridad a la configuración predeterminada ejecutando el comando ' ibmcloud oc security-group reset.

Acceso a imágenes de registros de contenedores externos como DockerHub o ' quay.io

Para acceder a imágenes de registros como DockerHub o ' quay.io o ' registry.redhat.com' , elija una de las siguientes opciones.

  • Desactivar la protección del tráfico saliente.
    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  • Refleja las imágenes que tu aplicación necesita en ' icr.io. Tirar, etiquetar y empujar esas imágenes a IBM Cloud Container Registry. Para obtener más información, consulte Envío de imágenes a IBM Cloud Container Registry.

Permitir el tráfico saliente a Red Hat Marketplace y OperatorHub

Los siguientes pasos habilitan todo el tráfico saliente. Si no quieres activar esta opción, puedes duplicar las imágenes de Red Hat Marketplace y OperatorHub que necesita tu aplicación en tu propio icr.io.

  1. Desactivar la protección del tráfico saliente.

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  2. Parchee OperatorHub en su clúster para permitir que se inicien los pods.

    oc patch OperatorHub cluster --type json -p '[{"op": "remove", "path": "/spec/disableAllDefaultSources"}]'

Para revertir estos cambios más tarde y desactivar OperatorHub, siga los siguientes pasos.

  1. Activar la protección del tráfico saliente.

    ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER

  2. Parche OperatorHub en su clúster para desactivar los pods

    oc patch OperatorHub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'

Permitir el tráfico saliente a los flujos de imágenes

Para acceder a los flujos de imágenes de su clúster, elija entre las siguientes opciones.

  • Refleja las imágenes que necesites en el registro ' icr.io '. Para obtener más información, consulte Envío de imágenes a IBM Cloud Container Registry.

  • Desactivar la protección del tráfico saliente.

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  • Añada una regla de grupo de seguridad al grupo de seguridad ' kube-<clusterID> ' a las direcciones IP del flujo de imágenes que desea utilizar. Tenga en cuenta que las direcciones IP de los flujos de imágenes pueden cambiar.

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR

Permitir el tráfico saliente para la monitorización remota de la salud con Telemetría

Para permitir la monitorización remota de la salud, debe desactivar la protección del tráfico saliente ejecutando el siguiente comando.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Acceso a los clusters 4.15 y a la consola web a través del VPE

Puede configurar Kubernetes para permitir el acceso al clúster a través de la puerta de enlace privada vpe. Esta opción está disponible tanto para clusters VPC privados como para clusters VPC públicos y privados. Dado que el acceso se realiza a través del punto final privado, el cliente debe configurar una VPN desde el cliente hasta su VPC para acceder al clúster.

A partir de los clusters 4.15, se necesita una regla de grupo de seguridad adicional para que funcione el acceso VPE. La regla de grupo de seguridad adicional es necesaria tanto para los clústeres privados como para los clústeres con puntos finales públicos y privados.

  1. Enumere sus servidores VPN.

    ibmcloud is vpn-servers

  2. Obtenga los detalles de su servidor VPN.

    ibmcloud is vpn-server SERVER

  3. Obtenga el grupo de IP de cliente de su servidor VPN.

    ibmcloud is vpn-server | grep "Client IP pool"

  4. Obtén los detalles de tu clúster y anota el puerto VPE.

    ibmcloud ks cluster get --cluster CLUSTERID

  5. Inicie su VPN en el cliente.

  6. Acceda a su clúster a través de VPE.

    ibmcloud ks cluster config --admin --cluster CLUSTERID --endpoint vpe

  7. Mostrar una lista de pods. Tenga en cuenta que este comando falla porque el cliente no puede acceder al clúster mediante la VPN a través de la pasarela VPE.

    kubectl get pods -A

  8. Añada una regla de grupo de seguridad al ' kube-vpegw-<clusterID> ' para su VPN. La remota en este caso proviene de la IP CIDR del cliente VPN.

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR

    Ejemplo de comando.

    ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min 30829  --port-max 30829 --remote 192.168.192.0/22

  9. Mostrar una lista de pods.

    kubectl get pods -A

Permitir el tráfico saliente para webhooks

Si utiliza webhooks que se ponen en contacto con un URL o un servicio externo al clúster, debe añadir reglas de grupo de seguridad que permitan el tráfico saliente desde los trabajadores de su clúster al URL o al servicio externo. Alternativamente, puede desactivar completamente la protección del tráfico saliente.

Normalmente, los webhooks de admisión que utilizan referencias a servicios de cluster no requieren ningún cambio.

En el siguiente ejemplo, un webhook de admisión que se conecta a un servicio de clúster no suele requerir ningún cambio porque el maestro se conecta al servicio a través de la conexión Konnectivity, que está permitida por defecto. Una excepción sería si los pods que implementan ese servicio de cluster necesitan conectarse a URL o a algún servicio externo. Si es así, permita que esos pods accedan a URL o al servicio externo, como se muestra en este ejemplo.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-cluster-service.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    service:
      name: my-admission-webhook
      namespace: default
      path: /validate
      port: 443
...

Sin embargo, si sus webhooks de admisión utilizan un URL, se requieren reglas de grupo de seguridad adicionales.

Ejemplo de webhook que se conecta a URL.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-url.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    url: https://webhook.ibm.com:20001/validate
...

Para permitir el acceso al URL externo o servicio para su webhook, puede elegir una de las siguientes opciones

  • Desactive la protección del tráfico saliente ejecutando el siguiente comando.

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

  • Añade reglas de grupo de seguridad de salida al grupo de seguridad ' kube-<clusterID> ' para permitir la conexión de los cluster workers. En el ejemplo anterior, se utiliza el servicio " webhook.ibm.com " en el puerto " 20001.

    1. Busque las IP de acceso a URL en dig.
        dig +short URL
    ```
    Ejemplo de comando.
    ```sh {: pre}
    dig +short webhook.ibm.com
    ```
    Salida de ejemplo
    ```sh {: screen}
    1.2.3.4
    4.5.6.7
    ```
1. Cree una regla para cada dirección IP que se devuelva.

```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
    ```
    Comandos de ejemplo.
    ```sh {: pre}
    ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 1.2.3.4
    ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 4.5.6.7
    ```

Para obtener más información, consulta « Control dinámico de admisión ».

Permitir el tráfico saliente a un servicio público

Si el servicio o servicios externos a los que llama tu aplicación tienen un pequeño conjunto de IPs/CIDRs utilizados para alojar ese servicio que no cambian muy a menudo, puedes permitir selectivamente el acceso saliente a esas IPs o CIDRs en tu grupo de seguridad ' kube-clusterID '.

El siguiente ejemplo utiliza las API de github.com en ' api.github.com.

  1. Encuentra las IPs programáticamente por ' curl.

    curl -sS -H "Accept: application/vnd.github+json" https://api.github.com/meta | jq '.api'

  2. Añada cada uno de los CIDR que encontró en el paso anterior como destino de una regla de grupo de seguridad saliente en el grupo de seguridad " kube-clusterID ". Como alternativa, puede crear un grupo de seguridad personalizado que añadirá a sus trabajadores de clúster en el momento de crear el clúster.

    ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>

Para más información, consulta Acerca de las direcciones IP GitHub's.

Consideraciones para VPC hub y spoke con protección del tráfico saliente

En un modelo hub and spoke, sólo se utiliza el clúster VPC hub para la resolución DNS. Los clusters radio acceden al DNS a través del hub. Los clusters hub y spoke suelen estar en distintas VPC, que se conectan a través de Transit Gateway.

En los clusters de la versión 4.15 y posteriores, el modelo hub and spoke no funciona sin ajustes en los grupos de seguridad de cada uno. Estos ajustes permiten el tráfico entre las VPC hub y spoke.

  1. Actualice los clústeres de la VPC de radio para que puedan acceder a la VPC central añadiendo reglas al grupo de seguridad " kube-<clusterID> " para cada clúster de radio. Asegúrese de añadir una regla de salida a cada subred CIDR de VPC en la que estén desplegados los trabajadores del clúster central. Por ejemplo, si un radio se conecta a un único concentrador y ese concentrador tiene trabajadores en tres zonas, deben añadirse tres reglas al grupo de seguridad " kube-<clusterID> " del radio, una para cada subred.

    ibmcloud is sg-rulec kube-<spoke-clusterID> outbound icmp_tcp_udp --remote <hub-subnet-CIDR>

  2. Actualiza los clústeres del concentrador para permitir el tráfico de los radios añadiendo reglas al grupo de seguridad de la puerta de enlace VPE compartida del concentrador (kube-vpegw-vpcID). Alternativamente, si utilizas tus propios grupos de seguridad personalizados para las puertas de enlace VPE compartidas, añade reglas a esos grupos de seguridad personalizados en su lugar.

  3. Ejecute el siguiente comando para encontrar las puertas de enlace VPE y, a continuación, consulte los detalles de la puerta de enlace para encontrar su grupo de seguridad asociado. Anote el ID del grupo de seguridad para añadirle reglas en el siguiente paso.

    ibmcloud is egs

  4. Añada una regla de entrada desde cada subred VPC en la que estén desplegados los spoke workers. Por ejemplo, si los radios están desplegados en tres zonas diferentes pero en una única subred en cada una de esas zonas, entonces se añaden tres reglas a los grupos de seguridad compartidos VPE Gateway del concentrador.

    ibmcloud is sg-rulec kube-vpegw-<hub-vpcID> inbound icmp_tcp_udp --remote <spoke-subnet-CIDR>

Permitir el tráfico temporal al servidor API del clúster a través de la red pública

Los trabajadores del clúster VPC utilizan la red privada para comunicarse con el maestro del clúster. Anteriormente, en los clústeres de VPC que tenían activado el punto final de servicio público, si la red privada estaba bloqueada o no 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 4.15 y posteriores, la caída a la red pública no es una opción porque el tráfico público saliente de los trabajadores del clúster está bloqueado. Es posible que desee desactivar la protección del tráfico saliente para permitir esta opción de copia de seguridad de la red pública, sin embargo, hay una alternativa mejor. En su lugar, si hay un problema temporal con la conexión entre el trabajador y el maestro a través de la red privada, entonces, en ese momento, puede agregar una regla de grupo de seguridad temporal al grupo de seguridad ' kube-clusterID ' para permitir el tráfico saliente al puerto ' apiserver ' del maestro del clúster. Más tarde, cuando se resuelva el problema, puede eliminar la regla temporal.

Puede elegir una de las siguientes opciones para permitir el tráfico a través de la red pública si la red privada está caída.

  • Añade una regla de grupo de seguridad al grupo de seguridad ' kube-clusterID ' para permitir el tráfico al servidor API.

    1. Obtenga los detalles de su clúster y tome nota del puerto del servidor API.
        ic ks cluster get --cluster <clusterID>
    ```
    Ejemplo de salida donde el puerto del servidor API es ' `30685`.

    ```sh {: screen}
    Name:                           prestg-sbd-vpc-4.15
    ID:                             coekl4a107ovqfndhh60
    ...
    Public Service Endpoint URL:    https://c100-e.containers.cloud.ibm.com:30685
    Private Service Endpoint URL:   https://c100.private.containers.cloud.ibm.com:30685
    ...
    ```
1. Añada una regla de grupo de seguridad de salida de su " `kube-<clusterID>` " a " `0.0.0.0/0` " para permitir todo el acceso público a la red.
```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min <API port> --port-max <API port> --remote 0.0.0.0/0
    ```
    Ejemplo de comando con un puerto de servidor API de ' `30685`.
    ```sh {: pre}
    ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 30685 --port-max 30685 --remote 0.0.0.0/0
    ```

  • Desactivar la protección del tráfico saliente.

    ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Verificación de la integración de Sysdig en clusters RHCOS privados

Si los pods de sysdig-agent están en CrashLoopBackOff en un clúster sólo privado que utiliza trabajadores RHCOS, puede desactivar la protección del tráfico saliente o actualizar el agente Sysdig para que utilice el controlador eBPF. Para obtener más información, consulte ¿Por qué están los pods de sysdig-agent en CrashLoopBackOff en un clúster RHCOS sólo privado?