Como Usar AKS no Azure: Integração com AAD, ACR e Azure Monitor em Produção Já leu

O que é AKS e por que dominar sua integração? Azure Kubernetes Service (AKS) é uma plataforma gerenciada que simplifica a implantação, administração e operações do Kubernetes no Azure. Diferentemente de gerenciar um cluster Kubernetes manualmente, o AKS cuida da camada de controle (control plane), deixando você responsável apenas pelos nós de trabalho e pela orquestração de suas aplicações. Quando você integra AKS com Azure Active Directory (AAD), Azure Container Registry (ACR) e Azure Monitor, cria um ecossistema robusto onde autenticação, armazenamento de imagens e observabilidade funcionam em harmonia. A integração desses três serviços resolve problemas críticos: controle de acesso baseado em identidade corporativa (AAD), pull de imagens de forma segura sem expor credenciais (ACR), e visibilidade completa do comportamento de suas aplicações em produção (Monitor). Este artigo o guiará através de cada integração com exemplos práticos que você pode aplicar imediatamente. Integração com Azure Active Directory (AAD) Por que integrar AAD ao AKS? Quando você integra AAD ao AKS,

O que é AKS e por que dominar sua integração?

Azure Kubernetes Service (AKS) é uma plataforma gerenciada que simplifica a implantação, administração e operações do Kubernetes no Azure. Diferentemente de gerenciar um cluster Kubernetes manualmente, o AKS cuida da camada de controle (control plane), deixando você responsável apenas pelos nós de trabalho e pela orquestração de suas aplicações. Quando você integra AKS com Azure Active Directory (AAD), Azure Container Registry (ACR) e Azure Monitor, cria um ecossistema robusto onde autenticação, armazenamento de imagens e observabilidade funcionam em harmonia.

A integração desses três serviços resolve problemas críticos: controle de acesso baseado em identidade corporativa (AAD), pull de imagens de forma segura sem expor credenciais (ACR), e visibilidade completa do comportamento de suas aplicações em produção (Monitor). Este artigo o guiará através de cada integração com exemplos práticos que você pode aplicar imediatamente.

Integração com Azure Active Directory (AAD)

Por que integrar AAD ao AKS?

Quando você integra AAD ao AKS, habilita autenticação e autorização baseadas em identidades corporativas. Seus desenvolvedores se autenticam no cluster usando suas credenciais corporativas, eliminando a necessidade de gerenciar certificados e tokens manualmente. Além disso, você pode granularizar permissões usando Role-Based Access Control (RBAC) nativo do Kubernetes, vinculado aos grupos do AAD.

Configurando integração com AAD

Primeiro, você precisa criar um cluster AKS com AAD integrado ou habilitar em um existente. Vou mostrar como criar um novo cluster com essa configuração:

#!/bin/bash

# Variáveis
RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"
LOCATION="eastus"
AAD_TENANT_ID="seu-tenant-id"
AAD_ADMIN_GROUP_ID="seu-grupo-aad-id"

# Criar Resource Group
az group create --name $RESOURCE_GROUP --location $LOCATION

# Criar cluster AKS com AAD integrado
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --enable-aad \
  --aad-admin-group-object-ids $AAD_ADMIN_GROUP_ID \
  --aad-tenant-id $AAD_TENANT_ID \
  --node-count 2 \
  --vm-set-type VirtualMachineScaleSets \
  --enable-managed-identity

Após criar o cluster, você obtém credenciais para acessá-lo. A primeira vez que um usuário tenta acessar o cluster via kubectl, ele é redirecionado para autenticação AAD:

# Obter credenciais do cluster
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --overwrite-existing

# Na primeira execução, você será solicitado a fazer login no navegador
kubectl get nodes

Configurando RBAC com AAD

Depois da autenticação, você controla o que cada usuário pode fazer usando RBAC. Crie um ClusterRoleBinding que atribua um grupo do AAD a um papel (role) específico:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: aks-developers-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- kind: Group
  name: "aks-developers@seudominio.com"
  apiGroup: rbac.authorization.k8s.io

Aplique este manifesto no seu cluster:

kubectl apply -f clusterrolebinding.yaml

Agora, qualquer membro do grupo aks-developers pode editar recursos (pods, deployments, etc.) no cluster, mas não pode criar ou deletar namespaces ou gerenciar RBAC.

Integração com Azure Container Registry (ACR)

A necessidade de pull seguro de imagens

Quando você executa containers no AKS, precisa que o cluster puxe imagens de algum lugar. O ACR é o registro de imagens nativo do Azure, integrado perfeitamente com AKS. A vantagem: você não precisa armazenar credenciais docker em secrets do Kubernetes. Em vez disso, usa Managed Identity, um mecanismo seguro onde o cluster se autentica automaticamente.

Criando um ACR e integrando ao AKS

Primeiro, crie um Azure Container Registry:

#!/bin/bash

ACR_NAME="meuregistry"
RESOURCE_GROUP="meu-rg"
LOCATION="eastus"
CLUSTER_NAME="meu-aks"

# Criar ACR
az acr create \
  --resource-group $RESOURCE_GROUP \
  --name $ACR_NAME \
  --sku Standard \
  --location $LOCATION

# Habilitar integração entre AKS e ACR
az aks update \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP \
  --attach-acr $ACR_NAME

Esse comando automaticamente configura o Managed Identity do AKS para ter permissão de pull no ACR. Nenhuma credencial extra necessária.

Fazendo push de imagens e testando o pull

Faça login no ACR e envie uma imagem de teste:

#!/bin/bash

ACR_NAME="meuregistry"
RESOURCE_GROUP="meu-rg"

# Fazer login no ACR
az acr login --name $ACR_NAME

# Build de uma imagem local (exemplo simples)
cat > Dockerfile << 'EOF'
FROM nginx:latest
RUN echo "Hello from AKS" > /usr/share/nginx/html/index.html
EOF

docker build -t minha-imagem:v1 .

# Tag da imagem com o repositório ACR
docker tag minha-imagem:v1 $ACR_NAME.azurecr.io/minha-imagem:v1

# Push para ACR
docker push $ACR_NAME.azurecr.io/minha-imagem:v1

Agora, crie um deployment no AKS que puxe essa imagem:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: meuregistry.azurecr.io/minha-imagem:v1
        ports:
        - containerPort: 80
kubectl apply -f deployment.yaml

# Verificar se os pods estão rodando
kubectl get pods

Graças à integração Managed Identity, o AKS puxou a imagem do ACR sem você ter criado nenhum ImagePullSecret.

Integração com Azure Monitor para Observabilidade

O tripé da observabilidade: logs, métricas e traces

Azure Monitor é a plataforma de observabilidade do Azure. Quando integrado ao AKS, coleta logs de seus containers, métricas de CPU/memória, eventos do cluster e muito mais. Essa visibilidade é crítica em produção: você sabe quando algo está errado antes que seus usuários reclamem.

Habilitando Container Insights no AKS

Container Insights é a solução de monitoramento específica para containers. Habilite durante a criação do cluster ou em um cluster existente:

#!/bin/bash

RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"

# Se o cluster já existe, habilitar Container Insights
az aks enable-addons \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --addons monitoring \
  --workspace-resource-id "/subscriptions/SEU_ID_SUBSCRIPTION/resourcegroups/$RESOURCE_GROUP/providers/microsoft.operationalinsights/workspaces/SEU_WORKSPACE"

Se você não tem um Log Analytics Workspace, crie um:

WORKSPACE_NAME="meu-workspace"

az monitor log-analytics workspace create \
  --resource-group $RESOURCE_GROUP \
  --workspace-name $WORKSPACE_NAME

Consultando logs e métricas

Depois de habilitar, o Container Insights começa a coletar dados. Você pode consultar tudo via Azure Portal ou usar queries KQL (Kusto Query Language). No portal, vá para seu cluster AKS → Insights.

Para consultas avançadas, use o Log Analytics Workspace diretamente:

// Listar todos os pods e seu uso de CPU/memória
ContainerInventory
| where TimeGenerated > ago(1h)
| join kind=inner (Perf | where ObjectName == "K8SContainer") on ContainerID
| project ContainerName, PodName, CpuPercent, MemoryRss
| sort by CpuPercent desc
// Contar restarts de containers nos últimos 24h
ContainerInventory
| where TimeGenerated > ago(24h)
| where ContainerState == "Restarting"
| summarize RestartCount = count() by ContainerName, PodName

Alertas baseados em métricas

Crie um alerta que o notifique quando um pod consome mais de 80% de CPU:

#!/bin/bash

ALERT_NAME="alert-cpu-alto"
RESOURCE_GROUP="meu-rg"
CLUSTER_NAME="meu-aks"
WORKSPACE_RESOURCE_ID="/subscriptions/SEU_ID/resourcegroups/$RESOURCE_GROUP/providers/microsoft.operationalinsights/workspaces/meu-workspace"

az monitor metrics alert create \
  --name $ALERT_NAME \
  --resource-group $RESOURCE_GROUP \
  --scopes $WORKSPACE_RESOURCE_ID \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action email-receiver --email seu@email.com

Enviando logs customizados de sua aplicação

Sua aplicação pode enviar logs estruturados para o Monitor. Use a Application Insights SDK em sua linguagem favorita. Aqui está um exemplo em Python:

from applicationinsights import TelemetryClient
import os

# Obter a chave de instrumentação do Application Insights
instrumentation_key = os.getenv("APPINSIGHTS_INSTRUMENTATION_KEY")
client = TelemetryClient(instrumentation_key)

# Registrar um evento de negócio
client.track_event("PedidoProcessado", {"id_pedido": "12345", "valor": 99.99})

# Registrar uma métrica customizada
client.track_metric("TempoProcessamento", 150)  # em ms

# Registrar um erro
try:
    1 / 0
except Exception as e:
    client.track_exception()

# Enviar dados
client.flush()

Configure a variável de ambiente no seu deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: minha-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: minha-app
  template:
    metadata:
      labels:
        app: minha-app
    spec:
      containers:
      - name: app
        image: meuregistry.azurecr.io/minha-app:v1
        env:
        - name: APPINSIGHTS_INSTRUMENTATION_KEY
          valueFrom:
            secretKeyRef:
              name: appinsights-secret
              key: instrumentation-key
        ports:
        - containerPort: 8000

Crie o secret com a chave:

INSTRUMENTATION_KEY="seu-chave-aqui"

kubectl create secret generic appinsights-secret \
  --from-literal=instrumentation-key=$INSTRUMENTATION_KEY

Colocando tudo junto: um cenário real

Você tem uma aplicação Python que processa pedidos. Quer rodar no AKS com segurança corporativa (AAD), imagens armazenadas seguramente (ACR) e monitoramento completo (Monitor). Aqui está o fluxo completo:

  1. Desenvolvedor faz login: Autentica via AAD. Seu grupo corporativo tem permissão de deploy no namespace "production".

  2. Pipeline CI/CD: Build da aplicação, tag com versão, push para ACR automaticamente.

  3. Deploy no AKS: Kubernetes pull da imagem do ACR usando Managed Identity. Nenhuma credencial exposta.

  4. Telemetria em tempo real: Aplicação envia logs e métricas para Application Insights. Você vê erros, latência, uso de recursos em um dashboard unificado.

Esse é o padrão moderno de entrega segura e observável de software no Azure.

Conclusão

Dominar a integração entre AKS, AAD, ACR e Azure Monitor significa que você não apenas roda containers, mas faz isso de forma segura, rastreável e eficiente. O primeiro aprendizado é que Managed Identity elimina a necessidade de armazenar credenciais — é autenticação baseada em confiança entre serviços Azure. O segundo aprendizado é que RBAC granular com AAD permite governança real de acesso sem complexidade operacional. O terceiro aprendizado é que observabilidade não é opcional — logs, métricas e alertas bem configurados te colocam em controle, não em reação.

Referências


Artigos relacionados