Control del tráfico de red desde HDInsight en clústeres y grupos de clústeres de AKS
Nota:
Retiraremos Azure HDInsight en AKS el 31 de enero de 2025. Antes del 31 de enero de 2025, deberá migrar las cargas de trabajo a Microsoft Fabric o un producto equivalente de Azure para evitar la terminación repentina de las cargas de trabajo. Los clústeres restantes de la suscripción se detendrán y quitarán del host.
Importante
Esta funcionalidad actualmente está en su versión preliminar. En Términos de uso complementarios para las versiones preliminares de Microsoft Azure encontrará más términos legales que se aplican a las características de Azure que están en versión beta, en versión preliminar, o que todavía no se han lanzado con disponibilidad general. Para más información sobre esta versión preliminar específica, consulte la Información de Azure HDInsight sobre la versión preliminar de AKS. Para plantear preguntas o sugerencias sobre la característica, envíe una solicitud sobre AskHDInsight con los detalles y síganos para obtener más actualizaciones sobre la comunidad de Azure HDInsight.
HDInsight en AKS es una plataforma como servicio (PaaS) administrada que se ejecuta en Azure Kubernetes Service (AKS). HDInsight en AKS permite implementar cargas de trabajo analíticas de código abierto populares, como Apache Spark™, Apache Flink®️ y Trino, sin la sobrecarga de tener que administrar y supervisar los contenedores.
De forma predeterminada, HDInsight en clústeres de AKS permite conexiones de red salientes de clústeres a cualquier destino, si el destino es accesible desde la interfaz de red del nodo. Esto significa que los recursos del clúster pueden acceder a cualquier dirección IP pública o privada, nombre de dominio o dirección URL en Internet o en la red virtual.
Sin embargo, en algunos escenarios, es posible que quiera controlar o restringir el tráfico de salida del clúster por motivos de seguridad y cumplimiento.
Por ejemplo, puede que desee:
Impida que los clústeres accedan a servicios malintencionados o no deseados.
Aplique directivas de red o reglas de firewall en el tráfico saliente.
Supervise o audite el tráfico de salida del clúster con fines de solución de problemas o cumplimiento.
Métodos y herramientas para controlar el tráfico de salida
Tiene diferentes opciones y herramientas para administrar cómo fluye el tráfico de salida desde HDInsight en clústeres de AKS. Puede configurar algunos de ellos en el nivel de grupo de clústeres y otros en el nivel de clúster.
Salida con equilibrador de carga. Al implementar un grupo de clústeres con esta ruta de acceso de salida, se aprovisiona y se asigna una dirección IP pública al recurso del equilibrador de carga. No se requiere una red virtual personalizada (VNET); sin embargo, se recomienda encarecidamente. Puede usar Azure Firewall o grupos de seguridad de red (NSG) en la red virtual personalizada para administrar el tráfico que sale de la red.
Salida con enrutamiento definido por el usuario. Al implementar un grupo de clústeres con esta ruta de acceso de salida, el usuario puede administrar el tráfico de salida en el nivel de subred mediante Azure Firewall o NAT Gateway y tablas de rutas personalizadas. Esta opción solo está disponible cuando se usa una red virtual personalizada.
Habilite AKS privado. Al habilitar AKS privado en el grupo de clústeres, el servidor de API de AKS se asignará a una dirección IP interna y no será accesible públicamente. El tráfico de red entre el servidor de API de AKS y HDInsight en grupos de nodos de AKS (clústeres) permanecerá en la red privada.
Clúster de entrada privado. Al implementar un clúster con la opción de entrada privada habilitada, no se creará ninguna dirección IP pública y solo se podrá acceder al clúster desde clientes dentro de la misma red virtual. Debe proporcionar su propia solución NAT, como una puerta de enlace NAT o una NAT proporcionada por el firewall, para conectarse a HDInsight público saliente en las dependencias de AKS.
En las siguientes secciones, se describe cada método en detalle.
Salida con equilibrador de carga
El equilibrador de carga se usa para la salida a través de una dirección IP pública asignada por HDInsight en AKS. Al configurar el tipo de salida de equilibrador de carga en el grupo de clústeres, puede esperar la salida del equilibrador de carga creado por HDInsight en AKS.
Puede configurar la configuración de salida con el equilibrador de carga mediante Azure Portal.
Una vez que opte por esta configuración, HDInsight en AKS completa automáticamente la creación de una dirección IP pública aprovisionada para la salida del clúster y las asignaciones al recurso del equilibrador de carga.
Una dirección IP pública creada por HDInsight en AKS y es un recurso administrado por AKS, lo que significa que AKS administra el ciclo de vida de esa dirección IP pública y no requiere la acción del usuario directamente en el recurso de dirección IP pública.
Cuando se crean clústeres, también se crean determinadas direcciones IP públicas de entrada.
Para permitir que las solicitudes se envíen al clúster, debe agregar a la lista de permitidos el tráfico. También puede configurar ciertas reglas en el NSG para realizar un control general.
Salida con enrutamiento definido por el usuario
Nota:
El tipo de salida userDefinedRouting es un escenario de red avanzado y requiere una configuración de red adecuada antes de comenzar.
No se admite el cambio del tipo de salida después de la creación del grupo de clústeres.
Si se establece userDefinedRouting, HDInsight en AKS no configurará automáticamente las rutas de acceso de salida. El usuario debe realizar la configuración de salida.
Debe implementar HDInsight en el clúster de AKS en una red virtual existente con una subred configurada previamente y debe establecer una salida explícita.
Esta arquitectura requiere el envío explícito del tráfico de salida a un dispositivo, como un firewall, una puerta de enlace o un proxy, para permitir que la dirección IP pública asignada al equilibrador de carga estándar o dispositivo pueda controlar la traducción de direcciones de red (NAT).
HDInsight en AKS no configura la dirección IP pública de salida ni las reglas de salida, a diferencia de la salida con clústeres de tipo equilibrador de carga como se describe en la sección anterior. El UDR es el único origen para el tráfico de salida.
Para el tráfico entrante, debe elegir, en función de los requisitos, un clúster privado (para proteger el tráfico en el plano de control de AKS o servidor API) y seleccionar la opción de entrada privada disponible en cada una de las formas de clúster para utilizar el tráfico basado en el equilibrador de carga público o interno.
Creación de grupos de clústeres para la salida con userDefinedRouting
Al usar HDInsight en grupos de clústeres de AKS y elegir userDefinedRouting (UDR) como ruta de acceso de salida, no hay ningún equilibrador de carga estándar aprovisionado. Debe configurar las reglas de firewall para los recursos salientes antes de que userDefinedRouting pueda funcionar.
Importante
La ruta de acceso de salida udR necesita una ruta para 0.0.0.0/0 y un destino de próximo salto del firewall o NVA en la tabla de rutas. La tabla de rutas ya tiene un valor predeterminado de 0.0.0.0/0 para Internet. No puede obtener conectividad saliente a Internet agregando esta ruta, ya que Azure necesita una dirección IP pública para SNAT. AKS comprueba que no cree una ruta 0.0.0.0/0 que apunte a Internet, sino a una puerta de enlace, una aplicación virtual de red, etc. Cuando utilice UDR, solo se creará una dirección IP pública del equilibrador de carga para las solicitudes entrantes si configura un servicio de tipo equilibrador de carga. HDInsight en AKS nunca crea una dirección IP pública para las solicitudes salientes cuando se usa una ruta de acceso de salida UDR.
Con los pasos siguientes, comprenderá cómo bloquear el tráfico saliente del servicio HDInsight en AKS a recursos de Azure back-end u otros recursos de red con Azure Firewall. Esta configuración ayuda a evitar la filtración de datos o el riesgo de implantación de programas malintencionados.
Azure Firewall le permite controlar el tráfico saliente en un nivel mucho más granular y filtrar el tráfico en función de la inteligencia sobre amenazas en tiempo real de Microsoft Cyber Security. Puede crear, aplicar y registrar directivas de aplicaciones y de conectividad de red a nivel central en suscripciones y redes virtuales.
A continuación se muestra un ejemplo de configuración de reglas de firewall y pruebas de las conexiones salientes.
Este es un ejemplo de cómo configurar reglas de firewall y comprobar las conexiones salientes.
Cree la subred de firewall necesaria
Para implementar un firewall en la red virtual integrada, necesita una subred denominada AzureFirewallSubnet o el nombre de su elección.
En Azure Portal, vaya a la red virtual integrada con su aplicación.
En el panel de navegación izquierdo, seleccione Subredes > + Subred.
En Nombre, escriba AzureFirewallSubnet.
Intervalo de direcciones de subred, acepte el valor predeterminado o especifique un intervalo de al menos /26 de tamaño.
Seleccione Guardar.
Implementación del firewall y obtención de su dirección IP
En el menú de Azure Portal o en la página principal, seleccione Crear un recurso.
Escriba firewall en el cuadro de búsqueda y presione Entrar.
Seleccione Firewall y después Crear.
En la página Creación de un firewall, configure el firewall como se muestra en la tabla siguiente:
Configuración Value Resource group El mismo grupo de recursos que la red virtual integrada. Nombre Nombre elegido Region La misma región que la red virtual integrada. Directiva de firewall Cree una seleccionando Agregar nueva. Red virtual Seleccione la red virtual integrada. Dirección IP pública Seleccione una dirección existente o cree una seleccionando Agregar nueva. 
Haga clic en Revisar + crear.
Seleccione nuevamente Crear. Este proceso tarda unos minutos en implementarse.
Una vez finalizada la implementación, vaya a su grupo de recursos y seleccione el firewall.
En la página Información general del firewall, copie la dirección IP privada. La dirección IP privada se usará como dirección de próximo salto en la regla de enrutamiento de la red virtual.
Enrute todo el tráfico al firewall
Cuando usted crea una red virtual, Azure crea automáticamente una tabla de rutas predeterminadas para cada una de sus subredes y agrega las rutas predeterminadas del sistema a la tabla. En este paso, usted crea una tabla de rutas definida por el usuario que enruta todo el tráfico al firewall y, a continuación, lo asocia a la subred App Service en la red virtual integrada.
En el menú de Azure portal, seleccione Todos los servicios o busque y seleccione Todos los servicios desde cualquier página.
En Redes, seleccione Tablas de rutas.
Seleccione Agregar.
Configure la tabla de rutas como en el ejemplo siguiente:
Asegúrese de seleccionar la misma región que el firewall que ha creado.
Seleccione Revisar y crear.
Seleccione Crear.
Una vez finalizada la implementación, seleccione Ir al recurso.
En el panel de navegación izquierdo, seleccione Rutas > Agregar.
Configure la nueva ruta como se muestra en la tabla siguiente:
Configuración Valor Tipo de destino Direcciones IP Intervalos de direcciones IP de destino y CIDR 0.0.0.0/0 Tipo de próximo salto Aplicación virtual Siguiente dirección de salto Dirección IP privada del firewall que copió En el panel de navegación izquierdo, seleccione Subredes > Asociar.
En Red virtual, seleccione su red virtual integrada.
En subred, seleccione la subred de HDInsight en AKS que desea usar.
Seleccione Aceptar.
Configuración de directivas de firewall
El tráfico saliente de la subred de HDInsight en AKS ahora se enruta a través de la red virtual integrada al firewall. Para controlar el tráfico saliente, agregue una regla de aplicación a la directiva de firewall.
Vaya a la página de información general del firewall y seleccione su directiva de firewall.
En la página Directiva de firewall, en el panel de navegación izquierdo, agregue reglas de red y aplicación. Por ejemplo, seleccione Reglas de red > Agregar una colección de reglas.
En Reglas, agregue una regla de red con la subred como dirección de origen y especifique un destino de FQDN. Del mismo modo, agregue las reglas de aplicación.
- Deberá agregar las reglas de tráfico de salida dadas aquí. Consulte este documento para agregar reglas de aplicación y red para permitir que el tráfico del clúster funcione. (Es necesario agregar AKS ApiServer después de crear el clusterPool porque solo puede obtener AKS ApiServer después de crear el clusterPool).
- También puede agregar las puntos de conexión privados para los recursos dependientes de la misma subred para que el clúster acceda a ellos (ejemplo: almacenamiento).
Seleccione Agregar.
Comprobación de si se ha creado la dirección IP pública
Con el conjunto de reglas de firewall, puede seleccionar la subred durante la creación del grupo de clústeres.
Una vez creado el grupo de clústeres, puede observar en el grupo de MC que no hay ninguna dirección IP pública creada.
Importante
Antes de crear el clúster en la configuración del grupo de clústeres con la ruta de acceso de salida Outbound with userDefinedRouting, es necesario proporcionar al clúster de AKS, que coincide con el grupo de clústeres, el rol de Network Contributor en los recursos de red que se usan para definir el enrutamiento, como Red virtual, Tabla de rutas y NSG (si se usa). Obtenga más información sobre cómo asignar el rol aquí
Nota:
Al implementar un grupo de clústeres con la ruta de acceso de salida de UDR y un clúster de entrada privado, HDInsight en AKS creará automáticamente una zona DNS privada y asignará las entradas para resolver el FQDN para acceder al clúster.
Creación de grupos de clústeres con AKS privado
Con AKS privado, el servidor de la API o el plano de control tienen direcciones IP internas que se definen en el documento RFC1918 sobre la asignación de direcciones para conexiones privadas de Internet. Con esta opción de AKS privado, puede asegurarse de que el tráfico de red entre el servidor de API y HDInsight en clústeres de cargas de trabajo de AKS permanece solo en la red privada.
Al aprovisionar un clúster de AKS privado, AKS crea de forma predeterminada un FQDN privado con una zona DNS privada y un FQDN público adicional con un registro A correspondiente en un DNS público de Azure. Los nodos del agente siguen usando el registro en la zona DNS privada, con el fin de resolver la dirección IP privada del punto de conexión privado para la comunicación con el servidor de la API.
Como HDInsight en AKS insertará automáticamente el registro en la zona DNS privada en HDInsight en el grupo administrado creado por AKS para la entrada privada.
Clústeres con entrada privada
Al crear un clúster con HDInsight en AKS, tiene un FQDN público y una dirección IP a la que cualquier usuario puede acceder. Con la característica de entrada privada, puede asegurarse de que solo la red privada puede enviar y recibir datos entre el cliente y HDInsight en el clúster de AKS.
Nota:
Con esta característica, HDInsight en AKS creará automáticamente registros A en la zona DNS privada para la entrada.
Esta característica impide el acceso público a Internet al clúster. El clúster obtiene un equilibrador de carga interno y una dirección IP privada. HDInsight en AKS usa la zona DNS privada que creó el grupo de clústeres para conectar la red virtual del clúster y realizar la resolución de nombres.
Cada clúster privado contiene dos FQDN: FQDN público y FQDN privado.
FQDN público: {clusterName}.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
El FQDN público solo se puede resolver en un CNAME con subdominio, por lo que debe usarse con el Private DNS zone setting correcto para asegurarse de que el FQDN se pueda resolver finalmente para corregir la dirección IP privada.
La zona DNS privada debe poder resolver el FQDN privado en una dirección IP (privatelink.{clusterPoolName}.{subscriptionId}).
Nota:
HDInsight en AKS crea una zona DNS privada en el grupo de clústeres, la red virtual. Si las aplicaciones cliente están en la misma red virtual, no debe volver a configurar la zona DNS privada. En caso de que esté utilizando una aplicación cliente en una red virtual diferente, deberá utilizar el emparejamiento de la red virutal y enlazar con la zona DNS privada en la red virtual del grupo de clústeres o utilizar puntos de conexión privados en la red virutal, y zonas DNS privadas, para añadir el registro A a la IP privada del punto de conexión privado.
FQDN privado： {clusterName}.privatelink.{clusterPoolName}.{subscriptionId}.{region}.hdinsightaks.net
El FQDN privado se asignará solo a clústeres con la entrada privada habilitada. Es un registro A en la zona DNS privada que se resuelve en la dirección IP privada del clúster.