Protección del acceso a la red de AKS
Elección del modelo de aislamiento de servidor de API adecuado
El servidor de la API de Azure Kubernetes Service (AKS) es el único punto de conexión con el plano de control para su clúster. Recibe cada comando kubectl, admite todas las cargas de trabajo y procesa cada cambio de configuración. Exponerlo a la red pública de Internet amplía la superficie expuesta a ataques a todas las direcciones IP de Internet. AKS proporciona dos controles para restringir el acceso al servidor de API: clústeres privados y intervalos IP autorizados. La elección adecuada depende de la arquitectura y la tolerancia a riesgos.
Eliminación del servidor de API de Internet con un clúster privado
Un clúster de AKS privado quita completamente el servidor de API de la red pública de Internet. En lugar de una dirección IP pública, el servidor de API recibe una dirección IP privada dentro de la red virtual. La resolución DNS del FQDN del servidor de API devuelve la dirección privada, por lo que el punto de conexión solo es accesible desde dentro de la red virtual o desde redes conectadas, redes locales a través de VPN o ExpressRoute o redes virtuales emparejadas.
Los clústeres privados son la opción adecuada cuando los requisitos de cumplimiento exigen una infraestructura solo privada, cuando las cargas de trabajo requieren el nivel más alto de segmentación de red o cuando necesite asegurarse de que la administración del clúster solo se produzca desde ubicaciones de red de confianza.
Cree un clúster privado con la --enable-private-cluster marca :
az aks create \
--resource-group <resource-group> \
--name <cluster-name> \
--enable-private-cluster \
--enable-aad \
--aad-admin-group-object-ids <group-object-id>
Nota:
Después de crear un clúster privado, no puede acceder al servidor de API desde fuera de la red virtual ni a una red conectada. Planee el modelo de acceso administrativo (un host bastión, una máquina virtual de jumpbox o agentes de compilación autohospedados dentro de la red virtual) antes de habilitar el modo de clúster privado.
Restricción del acceso al servidor de API con intervalos IP autorizados
En el caso de los clústeres que no pueden ser privados, ya que las canalizaciones de CI/CD, los patrones de acceso de asociados o los requisitos operativos necesitan puntos de conexión accesibles a Internet, los intervalos IP autorizados proporcionan una reducción significativa de la superficie expuesta a ataques. Especifique una lista de direcciones IP y intervalos CIDR permitidos para llegar al servidor de API. La capa de red rechaza las conexiones de todas las demás direcciones de origen.
Los intervalos IP autorizados no quitan el punto de conexión público. El servidor API conserva su dirección IP pública y el DNS se resuelve a una dirección pública. Sin embargo, un atacante que obtiene credenciales válidas solo puede usarlas desde una dirección IP de la lista de permitidos.
az aks update \
--resource-group <resource-group> \
--name <cluster-name> \
--api-server-authorized-ip-ranges "203.0.113.0/24,198.51.100.10/32"
Actualice la lista de permitidos a medida que cambie la infraestructura administrativa. Incluya las direcciones IP de salida de la VPN, los rangos de direcciones IP del agente de compilación y las direcciones de las estaciones de trabajo de los administradores. Revise la lista periódicamente para quitar entradas obsoletas.
Controla el tráfico de pod a pod con directivas de red
Los controles del servidor de API protegen el plano de control. Las directivas de red protegen el tráfico entre cargas de trabajo dentro del clúster. De forma predeterminada, todos los pods de un clúster de AKS pueden comunicarse con todos los demás pods: ningún límite de espacio de nombres o etiqueta de carga de trabajo restringe el tráfico interno. Un objeto NetworkPolicy de Kubernetes cambia este valor predeterminado mediante la definición de reglas de entrada y salida explícitas para los pods seleccionados. Se deniega todo el tráfico que no coincide con una regla permitida.
La siguiente NetworkPolicy restringe el servicio backend para que acepte conexiones entrantes solo desde pods del mismo espacio de nombres que tengan la etiqueta app: frontend:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-frontend-to-backend
namespace: retail-app
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
Esta política se aplica a cualquier pod etiquetado como app: backend en el espacio de nombres retail-app. El único tráfico entrante permitido es TCP en el puerto 8080 desde pods etiquetados con app: frontend. Se deniega cualquier otro tipo de entrada.
Bloquear el acceso al servicio de metadatos de instancia de Azure
El servicio de metadatos de instancia (IMDS) de Azure se ejecuta en 169.254.169.254 en cada máquina virtual de Azure, incluidos los nodos de AKS. Proporciona información de configuración de nodo y, de forma crítica, la capacidad de recuperar tokens de acceso para la identidad administrada del nodo. Una carga de trabajo en un pod puede consultar IMDS y obtener el token de identidad administrada del nodo, obteniendo los mismos permisos de Azure que el propio nodo.
Bloquee la salida del pod al punto de conexión IMDS con una NetworkPolicy explícita:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: block-imds
namespace: retail-app
spec:
podSelector: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 0.0.0.0/0
except:
- 169.254.169.254/32
El elemento vacío podSelector: {} aplica esta política a todos los pods del espacio de nombres. La regla de salida permite todo el tráfico saliente, excepto las conexiones a 169.254.169.254/32. Aplique esta directiva en cada espacio de nombres de aplicación.
Habilitación de directivas de red en la creación del clúster
Las directivas de red requieren un motor de directivas de red implementado en el clúster. AKS admite tres motores de directivas de red:
| Engine | Descripción | Se utiliza cuando |
|---|---|---|
| Cilium (recomendado) | Motor basado en eBPF incluido con Azure CNI Powered by Cilium. Admite objetos NetworkPolicy estándar de Kubernetes, además de directivas L7 extendidas y filtrado de FQDN a través de ACNS. Mejor rendimiento y escalabilidad que las soluciones basadas en iptables. | Nuevos clústeres: recomendado para todas las nuevas implementaciones de AKS |
| Azure Network Policy Manager (NPM) | motor basado en iptables para Linux; HNS ACLPolicies para Windows. | se requiere compatibilidad con el grupo de nodos de Windows |
| Calico | Motor basado en iptables de código abierto. | Compatibilidad entre nubes con entornos que no son de Azure |
Nota:
Puede agregar o cambiar un motor de directivas de red en un clúster existente mediante az aks update --network-policy <engine>. Esto desencadena la regeneración de la imagen del grupo de nodos, parecida a una actualización de versión de Kubernetes, pero no requiere la recreación del clúster.
Cree un clúster con Cilium (Azure CNI Powered by Cilium( recomendado para nuevas implementaciones):
az aks create \
--resource-group <resource-group> \
--name <cluster-name> \
--network-plugin azure \
--network-plugin-mode overlay \
--network-dataplane cilium
O bien, use el complemento de directiva de red de Azure para admitir grupos de nodos de Windows:
az aks create \
--resource-group <resource-group> \
--name <cluster-name> \
--network-plugin azure \
--network-policy azure
O bien, use Calico para la compatibilidad entre nubes:
az aks create \
--resource-group <resource-group> \
--name <cluster-name> \
--network-plugin azure \
--network-policy calico
Con un clúster privado o intervalos IP autorizados que protegen el servidor de API y las directivas de red que rigen el tráfico de pods, la superficie expuesta a ataques de red de Contoso Retail se limita explícitamente. El tráfico solo fluye cuando la directiva lo permite.