Editar

Compartir a través de

Protección del acceso de red a Kubernetes

Azure Bastion
Azure DNS
Azure Kubernetes Service (AKS)
Azure Private Link
Azure Virtual Network

En este artículo se comparan los modos de red de Azure Kubernetes Service (AKS) y Amazon Elastic Kubernetes Service (Amazon EKS). En el artículo se describe cómo mejorar la seguridad de conexión con el servidor de API administrado de un clúster de AKS y las distintas opciones para restringir el acceso a la red pública.

Nota:

Este artículo forma parte de una serie de artículos que ayudan a los profesionales que están familiarizados con Amazon EKS a comprender Azure Kubernetes Service (AKS).

Modos de red de Amazon EKS

Con Amazon Virtual Private Cloud (Amazon VPC) puede iniciar recursos de Amazon Web Services (AWS) en una red virtual compuesta de subredes públicas y privadas, o intervalos de direcciones IP en la VPC. Una subred pública hospeda recursos que deben estar conectados a Internet y una subred privada hospeda recursos que no están conectados a la red pública de Internet. Amazon EKS puede aprovisionar grupos de nodos administrados en subredes públicas y privadas.

El control de acceso de punto de conexión permite configurar si el punto de conexión del servidor de API es accesible desde la red pública de Internet o a través de VPC. EKS proporciona varias maneras de controlar el acceso al punto de conexión del clúster. Puede habilitar el punto de conexión público predeterminado, un punto de conexión privado o ambos puntos de conexión simultáneamente. Al habilitar el punto de conexión público, puede agregar restricciones de Enrutamiento de interdominios sin clases (CIDR) para limitar las direcciones IP de cliente que pueden conectarse al punto de conexión público.

La forma en que los nodos de Amazon EKS se conectan al plano de control de Kubernetes administrado está determinada por la configuración del punto de conexión definida para el clúster. Puede cambiar la configuración del punto de conexión en cualquier momento a través de la consola de Amazon EKS o la API. Para más información, consulte Control de acceso al punto de conexión del clúster de Amazon EKS.

Solo punto de conexión público

Exponer el plano de control a través de un punto de conexión público es el modo predeterminado para los nuevos clústeres de Amazon EKS. Cuando solo está habilitado el punto de conexión público para el clúster, las solicitudes de API de Kubernetes que se originan desde dentro de Amazon VPC, como el nodo de trabajo para controlar la comunicación del plano, salga de la VPC, pero no de la red de Amazon. Para que los nodos se conecten al plano de control, deben usar una dirección IP pública y una ruta a una puerta de enlace de Internet, o una ruta a una puerta de enlace de traducción de direcciones de red (NAT), donde pueden usar la dirección IP pública de la puerta de enlace NAT.

Puntos de conexión públicos y privados

Cuando se habilitan los puntos de conexión públicos y privados, las solicitudes de API de Kubernetes desde la VPC se comunican con el plano de control a través de las interfaces de red elástica (ENI) administradas por Amazon EKS en la VPC. El servidor de API de clúster es accesible desde Internet.

Solo punto de conexión privado

Cuando solo está habilitado el punto de conexión privado, todo el tráfico al servidor de API de clúster, como kubectl o comandos helm, debe proceder de la VPC del clúster o de una red conectada . El acceso público al servidor de API desde Internet está deshabilitado. Puede implementar este modo de acceso mediante AWS Virtual Private Network (AWS VPN) o AWS DirectConnect a la VPC. Para restringir el acceso al punto de conexión sin AWS VPN o DirectConnect, puede agregar restricciones CIDR al punto de conexión público para limitar las conexiones sin configurar más redes.

Si ha deshabilitado el acceso público para el punto de conexión del servidor de API de Kubernetes del clúster, puede acceder al punto de conexión del servidor de API de Kubernetes de una de las maneras siguientes:

  • de red conectada: conecte la red a la VPC con una puerta de enlace de tránsito de AWS u otras opciones de conectividad de y, a continuación, use un equipo en la red conectada. Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS contiene reglas para permitir el tráfico de entrada en el puerto 443 desde la red conectada.
  • host bastión de Amazon EC2: puede iniciar una instancia de Amazon EC2 en una subred pública en la VPC del clúster y, a continuación, iniciar sesión a través de SSH en esa instancia para ejecutar comandos kubectl. Para obtener más información, consulte hosts bastión de Linux en AWS. Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS contiene reglas para permitir el tráfico de entrada en el puerto 443 desde el host bastión. Para obtener más información, consulte Ver los requisitos del grupo de seguridad de Amazon EKS para clústeres. Al configurar kubectl para el host bastión, asegúrese de usar las credenciales de AWS que ya están asignadas a la configuración de RBAC del clúster o agregue la entidad de seguridad de IAM de que usará el bastión para la configuración de RBAC antes de quitar el acceso público del punto de conexión. Para obtener más información, consulte Conceder acceso de roles y usuarios de IAM a las API de Kubernetes y acceso denegado o no autorizado (kubectl).
  • IDE de AWS Cloud9: AWS Cloud9 es un entorno de desarrollo integrado (IDE) basado en la nube que le permite escribir, ejecutar y depurar el código solo con un explorador. Puede crear un IDE de AWS Cloud9 en la VPC del clúster y usar el IDE para comunicarse con el clúster. Para obtener más información, consulte Creación de un entorno en AWS Cloud9. Debe asegurarse de que el grupo de seguridad del plano de control de Amazon EKS contiene reglas para permitir el tráfico de entrada en el puerto 443 del grupo de seguridad IDE. Para obtener más información, consulte Ver los requisitos del grupo de seguridad de Amazon EKS para clústeres. Al configurar kubectl para el IDE de AWS Cloud9, asegúrese de usar las credenciales de AWS que ya están asignadas a la configuración de RBAC del clúster o agregue la entidad de seguridad de IAM que usará el IDE a la configuración de RBAC antes de quitar el acceso público del punto de conexión. Para obtener más información, consulte Conceder acceso de roles y usuarios de IAM a las API de Kubernetes y acceso denegado o no autorizado (kubectl).

Para más información sobre las opciones de conectividad, consulte Acceso a un servidor de API solo privado.

Acceso de la red de AKS al servidor de API

Hay dos opciones para proteger el acceso de red a la API de Kubernetes en AKS, un clúster de AKS privado o intervalos IP autorizados.

Clúster privado de AKS

Una clúster de AKS privado garantiza que el tráfico de red entre el servidor de API y los nodos del agente permanezca dentro de la red virtual. En un clúster de AKS privado, el plano de control o el servidor de API tiene direcciones IP internas que se definen en el documento RFC1918: asignación de direcciones para internet privado. Mediante el uso de un clúster privado, puede asegurarse de que el tráfico de red entre el servidor de API y los grupos de nodos permanece solo en la red privada.

En un clúster de AKS privado, el servidor de API tiene una dirección IP interna que solo es accesible a través de un punto de conexión privado de Azure ubicado en la misma red virtual. Cualquier máquina virtual (VM) de la misma red virtual puede comunicarse de forma privada con el plano de control a través de este punto de conexión privado. El plano de control o el servidor de API se hospeda en la suscripción administrada por Azure, mientras que el clúster de AKS y sus grupos de nodos se encuentran en la suscripción del cliente.

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 de A correspondiente en dns público de Azure. Los nodos del agente siguen usando el registro A en la zona DNS privada para resolver la dirección IP privada del punto de conexión privado para la comunicación con el servidor de API.

En el diagrama siguiente se muestra una configuración de clúster de AKS privada.

Diagrama que muestra un clúster de AKS privado.

Descargue un archivo Visio de esta arquitectura.

Para aprovisionar un clúster de AKS privado, el proveedor de recursos de AKS crea un nombre de dominio completo (FQDN) privado para el grupo de recursos del nodo en una zona DNS privada. Opcionalmente, AKS también puede crear un FQDN público con un registro de dirección (A) correspondiente en la zona DNS pública de Azure. Los nodos del agente usan el registro A en la zona DNS privada para resolver la dirección IP del punto de conexión privado para la comunicación con el servidor de la API.

El proveedor de recursos de AKS puede crear la zona DNS privada en el grupo de recursos del nodo, o bien usted puede crear la zona DNS privada y pasar su id. de recurso al sistema de aprovisionamiento. Puede crear un clúster privado cuando use Terraform con Azure, Bicep, plantillas de ARM, la CLI de Azure, el módulo de Azure PowerShell o API REST de Azure para crear el clúster.

Puede habilitar un FQDN público para el servidor de API durante el aprovisionamiento o mediante el comando az aks update con el parámetro --enable-public-fqdn en clústeres existentes. Si habilita el FQDN público, cualquier VM que tenga acceso al servidor, como un agente autohospedado de Azure DevOps o un ejecutor autohospedado de Acciones de GitHub, debe estar en la misma red virtual que hospeda el clúster o en una red conectada a través del emparejamiento de red virtual o VPN de sitio a sitio.

En el caso de un clúster de AKS privado, deshabilite el FQDN público del servidor de API. Para comunicarse con el plano de control privado, una VM debe estar en la misma red virtual o en una red virtual emparejada con un vínculo de red virtual a la zona DNS privada. El registro A de la zona DNS privada resuelve el FQDN del servidor de API en la dirección IP del punto de conexión privado que se comunica con el plano de control subyacente. Para obtener más información, consulte Creación de un clúster privado de Azure Kubernetes Service.

Opciones de implementación de clúster privado

El proveedor de recursos de AKS expone los parámetros siguientes para personalizar la implementación de clústeres de AKS privada:

  • authorizedIpRanges (cadena) especifica los intervalos IP permitidos en formato CIDR.
  • disableRunCommand (Booleano) especifica si se va a deshabilitar o no el comando run para el clúster.
  • enablePrivateCluster (Booleano) especifica si se va a crear o no el clúster como privado.
  • enablePrivateClusterPublicFQDN (Booleano) especifica si se va a crear o no otro FQDN público para el clúster privado.
  • privateDnsZone (cadena) especifica una zona DNS privada en el grupo de recursos del nodo. Si no especifica un valor, el proveedor de recursos crea la zona. Puede especificar los siguientes valores:
    • El valor predeterminado es System.
    • None tiene como valor predeterminado el DNS público, por lo que AKS no crea una zona DNS privada.
    • <Your own private DNS zone resource ID> usa una zona DNS privada que se crea en el formato privatelink.<region>.azmk8s.io o <subzone>.privatelink.<region>.azmk8s.io.

En la tabla siguiente se muestran las opciones de configuración de DNS para implementar un clúster de AKS privado:

Opciones de zona DNS privada enablePrivateClusterPublicFQDN: true enablePrivateClusterPublicFQDN: false
Sistema Los nodos del agente y cualquier otra VM de la red virtual del clúster de AKS o cualquier red virtual conectada a la zona DNS privada, usan el registro A de zona DNS privada para resolver la dirección IP privada del punto de conexión privado.

Cualquier otra VM usa el FQDN público del servidor de API.		 Los nodos del agente y cualquier otra VM de la red virtual del clúster de AKS o cualquier red virtual conectada a la zona DNS privada, usan el registro A de zona DNS privada para resolver la dirección IP privada del punto de conexión privado.

No hay ningún FQDN de servidor de API público disponible.
None Todas las VM, incluidos los nodos del agente, usan el FQDN público del servidor de API disponible a través de un registro A en una zona DNS pública administrada por Azure. Configuración errónea. El clúster de AKS privado necesita al menos una zona DNS pública o privada para la resolución de nombres del servidor de API.
Su propio id. de recurso de zona DNS privada Los nodos del agente y cualquier otra VM de la red virtual del clúster de AKS o cualquier red virtual conectada a la zona DNS privada, usan el registro A de zona DNS privada para resolver la dirección IP privada del punto de conexión privado.

Cualquier otra VM usa el FQDN público del servidor de API.		 Los nodos del agente y cualquier otra VM de la red virtual del clúster de AKS o cualquier red virtual conectada a la zona DNS privada, usan el registro A de zona DNS privada para resolver la dirección IP privada del punto de conexión privado.

No hay ningún FQDN de servidor de API público disponible.

Administración y conectividad de clústeres privados

En un clúster de AKS privado, el punto de conexión del servidor de API no tiene ninguna dirección IP pública. Hay varias opciones para establecer la conectividad de red con el clúster privado:

  1. Cree una máquina virtual en la misma red virtual que el clúster de AKS mediante el comando az vm create con la marca --vnet-name.
  2. Use una máquina virtual en una red virtual independiente y configure emparejamiento de red virtual con la red virtual del clúster de AKS.
  3. Configure una azure ExpressRoute o VPN para conectarse a la red virtual del clúster.
  4. Cree una conexión de punto de conexión privado de Azure dentro de otra red virtual.
  5. Use una instancia de Cloud Shell implementada en una subred conectada al servidor de API para el clúster.

Con la CLI de Azure, puede usar el comando az aks invoke comando para acceder a clústeres privados sin necesidad de configurar una VPN o Express Route. Este comando permite invocar comandos de forma remota, como kubectl y helm, en el clúster privado a través de la API de Azure, sin tener que conectarse directamente al clúster. Para usar command invoke, debe tener los permisos necesarios configurados para las acciones Microsoft.ContainerService/managedClusters/runcommand/action y Microsoft.ContainerService/managedclusters/commandResults/read.

En Azure Portal, puede usar la característica Run command para ejecutar comandos en el clúster privado. Esta característica utiliza realmente la funcionalidad de command invoke para ejecutar comandos en el clúster. El pod creado por la característica Run command proporciona kubectl y herramientas de helm para administrar el clúster. Además, admite Bash con herramientas como jq, xargs, grepy awk disponibles.

Puede usar de Azure Bastion en la misma red virtual o en una red virtual emparejada para conectarse a una máquina virtual de administración de jump box. Azure Bastion es una plataforma como servicio (PaaS) totalmente administrada que le permite conectarse a una VM mediante el explorador y Azure Portal. Azure Bastion proporciona conectividad de VM segura e ininterrumpida de Protocolo de escritorio remoto (RDP) o Secure Shell (SSH) a través de la Seguridad de la capa de transporte (TLS), directamente desde Azure Portal. Cuando las VM se conectan a través de Azure Bastion, no necesitan una dirección IP pública, un agente ni software cliente especial.

Integración de red virtual de API Server

Un clúster de Azure Kubernetes Service (AKS) configurado con integración de red virtual del servidor de API proyecta el punto de conexión del servidor de API directamente en una subred delegada en la red virtual donde se implementa AKS. La integración con red virtual del servidor de API permite la comunicación de red entre el servidor de API y los nodos del clúster sin necesidad de un vínculo privado ni un túnel. El servidor de API está disponible detrás de una VIP interna del equilibrador de carga en la subred delegada, que los nodos están configurados para su uso. Mediante la integración con red virtual del servidor de API, puede asegurarse de que el tráfico de red entre el servidor de API y los grupos de nodos permanece solo en la red privada.

El plano de control o el servidor de API se encuentra en una suscripción de Azure administrada por AKS. El clúster o el grupo de nodos se encuentra en la suscripción de Azure. El servidor y las máquinas virtuales que componen los nodos de clúster pueden comunicarse entre sí a través de las direcciones IP VIP y pod del servidor de API que se proyectan en la subred delegada.

La integración con red virtual del servidor de API es compatible con clústeres públicos o privados. Puede agregar o quitar el acceso público después del aprovisionamiento del clúster. A diferencia de los clústeres integrados que no son de red virtual, los nodos del agente siempre se comunican directamente con la dirección IP privada del equilibrador de carga interno del servidor de API (ILB) sin usar DNS. Todo el tráfico del servidor de API se mantiene en redes privadas y no se requiere ningún túnel para la conectividad del servidor de API a nodo. Los clientes fuera del clúster que necesitan comunicarse con el servidor de API pueden hacerlo normalmente si está habilitado el acceso a la red pública. Si el acceso a la red pública está deshabilitado, debe seguir la misma metodología de configuración de DNS privada que los clústeres privados estándar . Para más información, consulte Creación de un clúster de Azure Kubernetes Service con la integración de red virtual del servidor de API.

Intervalos IP autorizados

La segunda opción para mejorar la seguridad del clúster y minimizar los ataques al servidor de API es usar intervalos IP autorizados. Las direcciones IP autorizadas restringen el acceso al plano de control de un clúster de AKS público a una lista conocida de direcciones IP y CIDR. Cuando se usa esta opción, el servidor de API todavía está expuesto públicamente, pero el acceso es limitado. Para más información, consulte Protección del acceso al servidor de la API con intervalos de direcciones IP autorizadas en Azure Kubernetes Service (AKS).

El siguiente comando de la CLI de Azure az aks update autoriza los intervalos IP:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Consideraciones sobre la conectividad de AKS

Al considerar la conectividad de AKS, hay varias consideraciones importantes que debe tener en cuenta. Estos son algunos de los puntos clave que se deben tener en cuenta:

  • Un clúster privado de AKS ofrece seguridad y aislamiento mejorados en comparación con las direcciones IP autorizadas. Sin embargo, no es posible convertir un clúster de AKS público existente en un clúster privado. En su lugar, las direcciones IP autorizadas se pueden habilitar para cualquier clúster de AKS existente.
  • Los intervalos IP autorizados no se pueden aplicar a un punto de conexión de servidor de API privado. Solo se aplican al servidor de API público.
  • Los clústeres privados no admiten agentes hospedados en Azure DevOps. Se recomienda usar agentes autohospedados en su lugar.
  • Para que Azure Container Registry funcione con un clúster de AKS privado, se debe configurar un vínculo privado para el registro de contenedor en la red virtual del clúster. Como alternativa, el emparejamiento se puede establecer entre la red virtual de Container Registry y la red virtual del clúster privado.
  • Las limitaciones del servicio Azure Private Link se aplican a los clústeres privados.
  • Si el punto de conexión privado de la subred del cliente de un clúster privado se elimina o modifica, el clúster dejará de funcionar.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Otros colaboradores:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes

Las siguientes referencias proporcionan vínculos a ejemplos de documentación y automatización para implementar clústeres de AKS con una API protegida: