Configurar Azure Workload Identity en AKS

Esta página resume los elementos que deben configurarse para que los descubrimientos Kubernetes vía kubeconfig de una instancia Cyberwatch desplegada en un clúster AKS se autentiquen ante la API Kubernetes del clúster con Azure Workload Identity.

Azure Workload Identity se basa en la federación OIDC entre el clúster AKS y Microsoft Entra ID. Así, los pods de Cyberwatch obtienen un token sin secreto almacenado en el clúster. Un webhook de mutación inyecta al crear los pods las variables de entorno de Azure que la aplicación utiliza después para consultar la API Kubernetes.

Configuración en Azure

Clúster AKS

El clúster debe disponer de las siguientes funcionalidades:

• el emisor OIDC activado (oidcIssuerProfile.enabled a true)
• Workload Identity activado (opción --enable-workload-identity en la creación o actualización del clúster). El webhook de mutación azure-wi-webhook estará entonces presente en el clúster
• la autorización Kubernetes por Azure RBAC activada (aadProfile.enableAzureRbac a true). Los derechos de acceso a la API Kubernetes se gestionan entonces por asignaciones de roles de Azure, y no por ClusterRoleBinding

La URL del emisor OIDC del clúster es necesaria para lo siguiente:

az aks show --resource-group <resource-group> --name <cluster-name> --query oidcIssuerProfile.issuerUrl

Identidad administrada

Crear una identidad administrada dedicada, de tipo user-assigned, que llevará los derechos de acceso del descubrimiento.

Identificador federado

Crear un identificador federado (federated identity credential) sobre la identidad administrada, con los siguientes parámetros:

• issuer: la URL del emisor OIDC del clúster
• subject: la identidad de la cuenta de servicio dedicada descrita más abajo
• audience: api://AzureADTokenExchange

El subject tiene el siguiente formato, donde <namespace> es el espacio de nombres donde Cyberwatch está desplegado y <service-account> el nombre del ServiceAccount:

system:serviceaccount:<namespace>:<service-account>

Asignaciones de roles

Asignar a la identidad administrada el rol Lector RBAC Azure Kubernetes Service (Azure Kubernetes Service RBAC Reader) en cada clúster AKS a escanear. Este rol autoriza las llamadas a la API Kubernetes del clúster, como listar los pods, los espacios de nombres y los workloads.

El identificador federado solo debe configurarse una vez, para el clúster que aloja Cyberwatch. Los demás clústeres a escanear solo necesitan este rol y deben pertenecer al mismo tenant de Microsoft Entra que la identidad administrada.

Sin este rol en el clúster, las llamadas a la API Kubernetes fallan con el error User does not have access to the resource in Azure.

Configuración en el clúster Kubernetes

La configuración se aplica en el espacio de nombres donde Cyberwatch está desplegado, cyberwatch en los ejemplos siguientes.

Cuenta de servicio dedicada

Crear un ServiceAccount anotado con el client ID de la identidad administrada:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: workload-identity-sa
  namespace: cyberwatch
  annotations:
    azure.workload.identity/client-id: <client-id>

Despliegues Cyberwatch

El chart Helm de Cyberwatch expone los dos ajustes necesarios para el despliegue: extraLabels aplica la etiqueta en la plantilla del pod y serviceAccountName indica el ServiceAccount del pod. El ServiceAccount no lo crea el chart y debe existir previamente en el espacio de nombres.

web:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiq:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiqMaster:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"
sidekiqNode:
  serviceAccountName: workload-identity-sa
  extraLabels:
    azure.workload.identity/use: "true"

Para aplicar el mismo ServiceAccount a todos los componentes, es posible indicarlo una sola vez mediante global.serviceAccountName.

Aplicar los cambios del chart Helm con un helm upgrade.

Verificar el funcionamiento

Una vez reiniciados los pods, cada pod correspondiente debe contener las variables de entorno AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE y AZURE_AUTHORITY_HOST, así como un token proyectado en /var/run/secrets/azure/tokens/azure-identity-token:

kubectl -n cyberwatch exec deploy/web -- env | grep AZURE_

El descubrimiento Kubernetes vía kubeconfig puede crearse después desde la aplicación siguiendo la documentación de los descubrimientos Kubernetes vía kubeconfig.