Azure InfraGurus articles

Detectando Anomalias de Custo no Azure com FinOps Hub + SRE Agent

arsilvan — Thu, 23 Apr 2026 12:59:25 GMT

Introdução

Um dos maiores desafios em ambientes cloud é manter a visibilidade sobre os custos. Picos inesperados podem passar despercebidos por dias e quando chegam na fatura, já é tarde demais.

Neste artigo, vou mostrar como configurei uma análise automática diária de anomalias de custo usando o Azure SRE Agent, conectado ao FinOps Hub (Azure Data Explorer), com notificação automática no Microsoft Teams quando algo fora do padrão é detectado.

🏗️ Arquitetura da Solução

FinOps Hub (ADX) → SRE Agent (Scheduled Task) → KQL Anomaly Detection

↓ anomalia detectada?

SIM → Adaptive Card → Teams Channel

NÃO → Log: 'custos dentro do esperado'

Pré-requisitos

	Requisito	Detalhe
✅	FinOps Hub implantado	Com dados de custo sendo ingeridos no Azure Data Explorer
✅	Azure SRE Agent configurado	Com acesso à subscription onde o FinOps Hub está
✅	Canal no Microsoft Teams	Onde as notificações serão postadas
✅	Permissões adequadas	Managed Identity com Viewer no database Hub do ADX

Passo a Passo

① Identificar o Cluster ADX do FinOps Hub

O primeiro passo é localizar o cluster Azure Data Explorer onde o FinOps Hub armazena os dados de custo. No Azure SRE Agent, usamos o Azure Resource Graph:

az graph query -q "Resources | where type =~ 'Microsoft.Kusto/clusters'" --first 10 --subscription <subscription-id>

No meu caso como exemplo, o cluster retornado foi:

Propriedade	Valor
Nome	finopshubadx
URI	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
SKU	Dev(No SLA)_Standard_D11_v2
Região	North Central US

② Configurar Permissões (RBAC no ADX)

A managed identity do SRE Agent precisa de acesso Viewer ao database Hub do ADX. Sem isso, a query KQL falhará com erro 403.

Opção A — Azure CLI:

az kusto database-principal-assignment create \
--cluster-name finopshubadx \
--database-name Hub \
--resource-group <resource-group> \
--subscription <subscription-id> \
--principal-assignment-name "sre-agent-viewer" \
--principal-id "<managed-identity-client-id>" \
--principal-type App --role Viewer

Opção B — Portal:

ADX → Cluster → Database Hub → Permissions → Add → Viewer → Selecionar managed identity

Opção C — KQL (ADX Web UI):

.add database Hub viewers ('aadapp=<client-id>') 'SRE Agent'

③ A Query KQL de Detecção de Anomalias

Esta query utiliza series_decompose_anomalies do Kusto para detectar padrões anômalos nos custos diários ao longo dos últimos 12 meses:

let numberOfMonths = 12;
let start = startofmonth(ago(numberOfMonths * 30d));
let end = now();
let interval = 1d;

Costs()
| where ChargePeriodStart between (start .. end)
| summarize DailyCost = sum(EffectiveCost)
by bin(ChargePeriodStart, interval)
| make-series CostSeries = sum(DailyCost)
on ChargePeriodStart from start to end step interval
| extend anomalies = series_decompose_anomalies(CostSeries)
| project ChargePeriodStart, CostSeries, anomalies

💡 Como a query funciona

Costs() → Função do FinOps Hub que retorna dados de custo consolidados
make-series → Cria série temporal diária contínua (sem gaps)
series_decompose_anomalies → Algoritmo ML nativo do Kusto que detecta spikes e drops usando decomposição sazonal + STL
Score > 0 → custo acima do esperado | Score < 0 → abaixo do esperado
Quanto maior o |score|, mais significativa a anomalia

④ Configurar Webhook no Microsoft Teams

Para receber notificações no Teams, criamos um Incoming Webhook via Power Automate Workflows (método recomendado pela Microsoft):

No canal do Teams, clique nos 3 pontos (...) → Workflows
Pesquise "Post to a channel when a webhook request is received"
Selecione o Team e Channel desejados → Add workflow
Copie a URL gerada (formato: https://prod-xx...logic.azure.com/...)
Ative o workflow no Power Automate (My flows → Turn on)

⚠️ Atenção: O workflow pode ser criado com status 'Suspended'. Ative em: Power Automate → My flows → Turn on.

⑤ Criar a Scheduled Task no SRE Agent

Agora a parte principal: criar a tarefa agendada (Scheduled Task) no Azure SRE Agent. Basta pedir em linguagem natural:

"Crie uma tarefa diária para analisar anomalias de custo no FinOps Hub e me notificar pelo Teams quando houver anomalias detectadas."

O SRE Agent criará a task com os seguintes parâmetros:

Parâmetro	Valor
Nome	Daily FinOps Cost Anomaly Analysis
Schedule	0 8 * * * (diariamente às 08:00 UTC)
ADX Cluster	https://finopshubadx.northcentralus.kusto.windows.net
Database	Hub
Query	KQL com series_decompose_anomalies (12 meses)
Notificação	Adaptive Card no Teams via webhook
Escalação	HIGH se anomalias por 3+ dias consecutivos
Idempotência	Sem anomalia = 'custos dentro do esperado'

Task details:

Obs: Modificar os campos na task para adequar seu ambiente

Autonomous Scheduled Run - Daily FinOps Cost Anomaly Analysis ## Scope - Subscription: xxxxxxx-xxxxxxx-xxxxxx-xxxx-xxxxx - ADX Cluster: https://finopshub.northcentralus.kusto.windows.net - Database: Hub - Resource Group: finopshub-rg ## Goal Detect cost anomalies in Azure spending using the FinOps Hub data. Run the KQL query against the ADX cluster, analyze results, and notify via Teams if anomalies are found. ## Step 1: Execute KQL Query Use the KustoQuery subagent to run this query against the ADX cluster (https://finopshubadx.northcentralus.kusto.windows.net, database: Hub): ```kql let numberOfMonths = 12; let start = startofmonth(ago(numberOfMonths * 30d)); let end = now(); let interval = 1d; Costs() | where ChargePeriodStart between (start .. end) | summarize DailyCost = sum(EffectiveCost) by bin(ChargePeriodStart, interval) | make-series CostSeries = sum(DailyCost) on ChargePeriodStart from start to end step interval | extend anomalies = series_decompose_anomalies(CostSeries) | project ChargePeriodStart, CostSeries, anomalies ``` ## Step 2: Analyze Results - Parse the anomalies array from series_decompose_anomalies output - Identify days where anomaly score is significantly positive (cost spike) or negative (unusual drop) - For each anomaly found, calculate: the date, actual cost value, expected baseline, and percentage deviation - Focus on the last 7 days of data for actionable anomalies, but use the full 12-month history for context ## Step 3: Generate Report Create a summary with: - Total anomalies detected in the last 7 days - For each anomaly: date, cost value, deviation from expected, severity (high/medium/low) - Trend analysis: whether costs are trending up, down, or stable - Top recommendations (e.g., investigate specific resource groups, check for new deployments, review reserved instances) ## Step 4: Teams Notification (ONLY if anomalies detected in last 7 days) If anomalies are found, send a notification to Microsoft Teams using the executing_code skill (ExecutePythonCode) to POST to this webhook URL: https://839eace659ab424397eca5b8fcc104.e4.environment.api.powerplatform.com:443/powerautomate/automations/direct/workflows/88ec6b6c43014d8f8cb13999714dddd8/triggers/manual/paths/invoke?api-version=1&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=br2rNi4x1zKjWp6CgKWcajvEUW_7EUBkHrkbnp6Hk2g Use Adaptive Card format for the Teams message with: - Title: "⚠️ Azure Cost Anomaly Detected" - Summary of anomalies (dates, values, deviations) - Severity indicator - Link back to this SRE Agent thread for details Python code example for the webhook POST: ```python import urllib.request import json webhook_url = "<colar-url-webhook-aqui>" card = { "type": "message", "attachments": [{ "contentType": "application/vnd.microsoft.card.adaptive", "content": { "$schema": "http://adaptivecards.io/schemas/adaptive-card.json", "type": "AdaptiveCard", "version": "1.4", "body": [ {"type": "TextBlock", "text": "⚠️ Azure Cost Anomaly Detected", "weight": "Bolder", "size": "Large"}, {"type": "TextBlock", "text": "<ANOMALY_SUMMARY_HERE>", "wrap": True}, {"type": "FactSet", "facts": [ {"title": "Date", "value": "<DATE>"}, {"title": "Actual Cost", "value": "<COST>"}, {"title": "Expected", "value": "<EXPECTED>"}, {"title": "Deviation", "value": "<DEVIATION>%"}, {"title": "Severity", "value": "<SEVERITY>"} ]} ], "actions": [{"type": "Action.OpenUrl", "title": "View in SRE Agent", "url": "https://sre.azure.com/agents/subscriptions/<sua-subscricao>/resourceGroups/finopshub-rg/providers/Microsoft.App/agents/finopshub/views/thread/7314d219-77d6-4e12-a3fb-f30606d13077"}] } }] } req = urllib.request.Request(webhook_url, data=json.dumps(card).encode('utf-8'), headers={'Content-Type': 'application/json'}, method='POST') response = urllib.request.urlopen(req) ``` ## Step 5: Report in Thread Always post a summary in this thread with: - Whether anomalies were found or not - Key metrics and trends - If no anomalies: "No material cost anomalies detected. Daily costs within expected range." ## Constraints - Read-only operations only against ADX - Max 5 KQL queries per execution - Do not modify any Azure resources ## Idempotence If no anomalies detected in the last 7 days and costs are within normal thresholds, output: "No material cost anomalies detected. Daily costs within expected range." ## Escalation If anomalies are detected for 3+ consecutive days, flag as HIGH severity in the Teams notification and recommend immediate investigation.

⑥ Notificação no Teams (Adaptive Card)

Quando anomalias são detectadas, o SRE Agent envia um Adaptive Card rico para o Teams:

⚠️ AZURE COST ANOMALY DETECTED
🔴 HIGH — 2026-04-21
Custo Real	$1,847.32
Custo Esperado	$623.15
Desvio	+196.5% (↑ $1,224.17)
Score Anomalia	4.7 (threshold: 1.5)

🟡 MEDIUM — 2026-04-20
Custo Real	$987.44
Desvio	+59.5% (↑ $368.54)
📊 Trend (7d)	$601 → $615 → $622 → $619 → $987 → $1,847

Exemplo de Adaptive Card enviado ao canal do Teams

O card inclui botões: Ver Detalhes no SRE Agent e Abrir FinOps Hub (ADX) para investigação.

⑦ Testar a Integração (Simular Anomalia)

Antes de confiar no agendamento, teste pedindo ao SRE Agent:

"Simular uma anomalia de custo para eu receber no Teams"

O agente enviará um Adaptive Card de teste com dados simulados para validar que o webhook está funcionando.

Dica: Se o webhook retornar erro 400 - WorkflowTriggerIsNotEnabled, ative o flow em: Power Automate → My flows → Turn on.

Como Funciona no Dia a Dia

Horário	Ação	Resultado
08:00 UTC	SRE Agent executa query KQL no ADX	Dados de custo (12 meses)
08:01 UTC	Análise de anomalias (últimos 7 dias)	Identifica spikes e drops
08:02 UTC	Se anomalia → Teams notification	Adaptive Card no canal
08:02 UTC	Se normal → log no thread	"Custos dentro do esperado"
Contínuo	3+ dias anomalia → escalação HIGH	Investigação recomendada

Gerenciamento da Task

Após criada, a tarefa pode ser gerenciada pelo SRE Agent:

Pausar: "Pausar a tarefa de anomalia de custo"
Retomar: "Retomar a tarefa"
Alterar horário: "Mudar para executar às 10h UTC"
Ver histórico: "Mostrar histórico de execuções"
Cancelar: "Cancelar a tarefa de anomalia"

Conclusão

Com essa configuração, você tem um sistema inteligente de vigilância de custos que:

🔍 Analisa 12 meses de histórico para detectar padrões sazonais

🤖 Usa ML nativo do Kusto — sem infraestrutura adicional

📱 Notifica proativamente no Teams — só quando há anomalia

📈 Escala automaticamente a severidade em anomalias persistentes

💬 Mantém histórico completo no thread do SRE Agent

🔧 É gerenciável por linguagem natural — sem YAML, sem pipelines

A combinação FinOps Hub + Azure SRE Agent + Teams transforma a governança de custos de reativa (olhar dashboards) em proativa e automatizada.

🚀 Quer implementar na sua organização?

Se você quer testar, o Azure SRE Agent está disponível como preview. Configure um agente na sua subscription e comece a conversar em linguagem natural.

Já usa FinOps Hub? Conte nos comentários como você monitora anomalias de custo hoje!

#FinOps #Azure #SREAgent #CostManagement #AzureDataExplorer #CloudGovernance #DevOps #MicrosoftTeams #AIOps

FinOps Hub Privado: Implementação Manual em Ambientes Corporativos

carolinamelo — Fri, 10 Apr 2026 16:51:20 GMT

O que é o FinOps Hub?

O FinOps Hub é uma solução open source da Microsoft, parte do FinOps Toolkit, que fornece uma base escalável e extensível para análise, governança e otimização de custos em nuvem. A solução centraliza dados de custos por meio de recursos de armazenamento e pipelines de dados, permitindo que as organizações padronizem a forma como analisam seus gastos na nuvem, adotando o modelo de dados FOCUS definido pela FinOps Foundation.

Além de disponibilizar relatórios e dashboards prontos, o FinOps Hub expõe os dados de custos de forma estruturada por meio do Azure Data Explorer ou do Microsoft Fabric, possibilitando a criação de relatórios customizados no Power BI e o desenvolvimento de soluções internas sob medida, de acordo com as necessidades do negócio.

Objetivo

Esse artigo visa orientar a implementação manual do acesso privado ao FinOps Hub após uma implementação pública, sem usar diretamente a opção de implementação privada oferecida pelo template.

Por que implementar o FinOps Hub com acesso privado de forma manual?

O template disponibilizado para a implementação do FinOps Hub permite que selecionemos duas formas de implementação:

Pública: forma de implementação mais simples e comum. Os recursos são provisionados com acesso público habilitado, sendo acessados por meio de seus endpoints públicos padrões do Azure. O controle de acesso é feito exclusivamente via permissões RBAC.
Privada: forma de implementação mais segura. Os recursos são provisionados com acesso público desabilitado e expostos apenas por meio de private endpoints, ficando acessíveis somente através de redes privadas que possuem conectividade com a rede onde esses endpoints estão implementados.

Embora a comunicação privada traga ganhos significativos de segurança, sua habilitação através do template do FinOps Hub introduz algumas implicações importantes no processo de implantação. O template, de forma automática, tenta:

Criar uma rede virtual (/26);
Provisionar Private DNS Zones;
Criar os registros DNS associados aos private endpoints;
Configurar os links entre as VNets e as zonas DNS.

Em muitas organizações, esse tipo de configuração é restrito por políticas internas. A criação de redes, zonas DNS e seus respectivos vínculos costuma ser responsabilidade de times especializados, que garantem a padronização e a aderência às diretrizes arquiteturais definidas pela empresa.

Em cenários onde a organização adota, por exemplo, uma topologia Hub & Spoke, com landing zones bem definidas para workloads e conectividade, é fundamental considerar alguns pontos adicionais:

Garantir que a rede criada para os private endpoints não tenha sobreposição (overlap) com outras redes existentes;
Assegurar que exista peering com a VNet de hub;
Integrar os registros DNS dos novos private endpoints às Private DNS Zones centralizadas;
Configurar corretamente os VNet links;
Garantir que a resolução de nomes esteja funcional no ambiente on-premises, permitindo o acesso ao FinOps Hub por meio de VPN, ExpressRoute ou outras formas de conectividade híbrida.

Esses fatores explicam por que, em muitos casos, o uso do template com configuração privada se torna inviável quando utilizado de forma isolada. Isso ocorre porque, frequentemente, o time de FinOps não é o mesmo time responsável por redes e DNS, possuindo permissão para implantar apenas parte dos recursos necessários.

Nesses cenários, a implementação privada exige a orquestração entre diferentes times, cada um atuando dentro de suas responsabilidades. Como resultado, algumas etapas que o template tenta executar automaticamente precisam ser realizadas manualmente, conforme descrito nas próximas seções.

Passo a Passo para Implementação

Faça a implementação do template seguindo o tutorial documentado, com “Networking” em modo público.
Assim que o template é implementado, alguns scripts de configuração são executados. Aguarde até que esses scripts sejam executados, ou seja, desapareçam do grupo de recursos onde o FinOps Hub foi implementado para seguir com os próximos passos. Exemplos dos “Deployment Scripts” que desaparecerão:

Crie uma rede de tamanho mínimo /26 – valide com o time de infraestrutura o espaçamento que pode ser utilizado. Dentro dessa rede implemente uma subrede:
- private-endpoint-subnet (/28) – subrede para os private endpoints.
Garanta a existência das Private DNS Zones: se seu ambiente possui zonas de DNS privadas centralizadas pré-configuradas. Garanta que as seguintes zonas já existam na subscription padrão para os seus recursos de rede:
- privatelink.blob.core.windows.net– para o Data Explorer e storage
- privatelink.dfs.core.windows.net– para o Data Explorer and o data lake hospedando os dados de FinOps data e configuração das pipelines
- privatelink.table.core.windows.net– para Data Explorer
- privatelink.queue.core.windows.net– para o Data Explorer
- privatelink.{location}.kusto.windows.net– para Data Explorer

Configurando a Storage Account com Acesso Privado

O primeiro recurso que a ser configurado será a Storage Account.

A configuração a seguir deve ser realizada duas vezes uma para o target sub-resource “blob” e outra para o target sub-resource “dfs”.
- Acesse “Networking” e a aba “Private Endpoints”
- Na aba “Basics” defina:
  - Subscription: mesma que o FinOps Hub foi implementado
  - Resource Group: mesmo que o FinOps Hub foi implementado
  - Name: use um nome que remeta ao recurso criado (private endpoint) e o sub recurso que ele fará exposição (blob/dfs). Exemplo: pe-storageaccount-blob/ pe-storageaccount-dfs
- Na aba “Resource” defina o target sub-resource para o qual a configuração está sendo feita. No caso, primeiro foi feito para “blob” e depois “dfs”.
- Na aba “Virtual Network”, deve-se selecionar a rede criada para os private endpoints bem como a subrede (private-endpoint-subnet).
- Na aba “DNS” selecione a private DNS zone na qual são realizados os registros do seus private endpoints. Quando estiver configurando o private endpoint para blob será privatelink.blob.core.windows.net e para dfs privatelink.dfs.core.windows.net.
- Adicione Tags caso seja necessário.
- Clique em “Review + create”.
- Ao final, dois private endpoints devem estar criados para a storage account:

Agora será necessário configurar o private endpoint usado pelo Data Factory para acessar a Storage Account.
- Acesse o Data Factory e clique em "Launch Studio".
- No menu lateral, selecione a opção "Manage" -> "Linked services":
- Selecione o serviço correspondente ao Azure Data Lake Storage Gen2.
- Em “Connect via integration runtime” substitua “AutoResolveIntegrationRuntime” por New+:
- Em “Integration runtime setup” selecione “Azure” -> Botão “Continue”:
- Na aba “Settings”, apenas altere o campo “Name”. Use algo como “ManagedIntegrationRuntime”. Os demais campos, mantenha como estão:
- Na aba “Virtual Network”, configure conforme a imagem abaixo:
- Por fim, na aba “Data flow runtime”, use as configurações abaixo:
- Clique em “Create”.
- Agora, voltando a página “Edit linked Service”, adicione o “Managed Private Endpoint”. Ele ficará em estado “Pending”.
- Clique em “Save”.
- Além disso, use a managed identity fornecida na página “Edit linked Service”, e lhe dê os seguintes acessos na storage account:
  - Reader
  - Storage Account Contributor
  - Storage Blob Data Contributor
- Por fim, acesse a seção “Networking” da Storage Account novamente, selecione o private endpoint criado pelo Data Factory e clique no botão “Approve”.

Configurando o Linked Service ftkRepo no Data Factory

Voltando na seção “Manage” do Azure Data Factory, será necessário editar o serviço “ftkRepo”. Nele, o único campo a ser alterado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.

Clique em “Save”.

Configurando o Azure Data Explorer com Acesso Privado

Acesse a seção “Networking” cluster do Data Explorer criado pelo script do FinOps Hub e acesse a aba “Private Endpoint Connections”
Clique em “+ Private Endpoint”.
Em “Basics” inclua um nome para o private endpoint e garanta que a região selecionada é a de implementação do seu FinOps Hub e da vnet criada para ele.
Na aba “Virtual Network” selecione a rede e subrede criadas para os private endpoints.
Na aba “DNS”, associar cada configuração a sua private DNS zone correspondente. Se essas zonas já existirem no ambiente e forem utilizadas de forma centralizada, usar as existentes. Caso contrário, a configuração poderá criar private DNS zones novas:
Novamente será preciso configurar o private endpoint gerenciado pelo Data Factory. Para isso, acesse “Managed” -> “Linked Services” e selecione o serviço referente ao Azure Data Explorer.
Nessa seção, o único campo a ser editado é o “Connect via integration runtime” usando o “ManagedIntegrationRuntime” criado na etapa de configuração da storage account.
Agora ainda em “Manage” no Data Factory, selecione a opção “Managed Private Endpoints”. Clique em “+New” -> “Azure Data Explorer (Kusto)”
Forneça um nome para o private endpoint, marque a subscription na qual o Data Explorer foi implementado e em "Cluster" selecione o recurso implementado via template do FinOps Hub:
Ao final, deve-se ter dois private endpoints configurados no Azure Data Explorer:

Ajustes Finais e Validações de Conectividade

Tanto para a Storage Account quanto para o Data Explorer, acesse as configurações de rede e altere o Public network access para “Disabled”.
Por fim, no seu servidor local de DNS, crie o registro para o Data Explorer apontando para o forwarder correto no Azure seja ele uma máquina virtual ou o inbound endpoint do Azure Private Resolver. Não use o domínio com privatelink, mas sim o padrão, no caso do Data Explorer a forma geral é <localização>.kusto.windows.net conforme o exemplo abaixo:

Ao configurar os apontamentos corretamente, será possível configurar os dashboards em máquinas locais/on-premises que tenham acesso privado ao ambiente Azure. Os dashboards precisam ser capazes de resolver a URL do cluster Data Explorer que é apontado como parâmetro do Dashboard em PowerBI.
Se desejar validar a comunicação antes de configurar o dashboard de Power BI, teste da sua máquina local a resolução da URI do Data Explorer implementado para o FinOps Hub, usando nslookup conforme o exemplo abaixo.

Segurança Corporativa no Azure VMware Solution (AVS): Como Inspecionar o Tráfego com Firewall NVA

LeandroBarbosa — Wed, 11 Mar 2026 14:50:40 GMT

Muitas vezes faz sentido usar uma NVA (Network Virtual Appliance) como firewall dentro do AVS, porque permite reaproveitar a solução de firewall já existente (Palo Alto, Check Point, etc..) e manter a proficiência do time de segurança, evita parte da complexidade de roteamento que pode surgir ao forçar o tráfego passar por um firewall “fora” do AVS . Além disso, administrar esse firewall dentro do AVS continua familiar para quem já opera VMware, e você ganha acesso a recursos avançados de inspeção do fabricante (como filtragem por aplicação em camada 7 e inspeção SSL/TLS), que são muito úteis para controle de tráfego outbound e políticas corporativas.

Neste artigo eu demonstro e um laboratório prático de inspeção de tráfego Norte-Sul e Leste-Oeste, fazendo isolamento por ambiente (DEV/PRD) dentro do Azure VMware Solution (AVS) usando NSX-T (Tier-0/Tier-1) e um Firewall NVA (pfSense) implantado no SDDC. Também serão demonstradas as principais configurações no NSX (criação/associação de segments, gateways T0/T1 e ajustes de roteamento necessários para forçar o tráfego a passar pela NVA).

Arquitetura

Informações do Laboratório

Segmentos de Trânsito

Transit_Outside | CIDR: 192.168.30.0/24 | GW: 192.168.30.1
Transit_PRD | CIDR: 192.168.21.0/24 | GW: 192.168.21.1
Transit_DEV | CIDR: 192.168.22.0/24 | GW: 192.168.22.1

Segmentos de Workloads

PRD_WEB | CIDR: 192.168.70.0/24 | GW: 192.168.70.1
PRD_DATA | CIDR: 192.168.71.0/24 | GW: 192.168.71.1
DEV_WEB | CIDR: 192.168.80.0/24 | GW: 192.168.80.1
DEV_DATA | CIDR: 192.168.81.0/24 | GW: 192.168.81.1

Interfaces da NVA (pfSense)

Transit_Outside: 192.168.30.5
Transit_PRD: 192.168.21.5
Transit_DEV: 192.168.22.5

Configuração do Azure VMware Solution

Na configuração Internet connectivity (egress/ingress) do Azure VMware Solution (AVS) irei utilizar a opção "Connect using Public IP down to the NSX Edge". Isso permite usar o NSX Data Center para criar regras de outbound e inbound (DNAT/SNAT) usando esses IPs públicos diretamente no Edge do AVS.

Configuração de SNAT e NoSnat no NSX

Regras “No SNAT” : Define que não deve haver tradução de origem quando o tráfego vai para redes privadas RFC1918. Isso preserva o IP original de origem para comunicação interna (ex.: on-prem, Azure, spoke VNets/rotas privadas), evita quebra de roteamento/retorno.
Regra “SNAT”: Aplica tradução de origem para o restante do tráfego (Internet). Ou seja, quando uma VM com IP privado sai para fora, o NSX troca o IP de origem pelo IP público configurado ( 20.20.138.0/32).

Criação dos Gateways TIER-1 (PRD e DEV).

Importante: Estes gateway são "Isolados", portando não serão conectados ao TIER-0

T1_PRD_Isolado

T1_DEV_Isolado

Resultado

Criação dos Segmentos de Trânsito PRD e DEV

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_Isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

TRANSIT_PRD

TRANSIT_DEV

Criação do Segmento PRD WEB e DATA

Importante: Estes Segmentos estarão conectados ao Tier-1 Gateway PRD (T1_PRD_isolado) e DEV ( T1_DEV_Isolado) respectivamente criados na etapa anterior

PRD_WEB

PRD_DATA

DEV_WEB

DEV_DATA

Visão Geral dos Segmentos

Configuração de Rotas

Rotas no Gateway T1 Default

No Gateway T1 Default que está conectado ao T0 , irei configurar rotas para todos os segmentos com Next Hop ao ip da interface Outside do meu PFsense (192.168.30.5) .

obs: o nome do gateway T1 é diferente em cada AVS SDDC, no meu ambiente é "TNT13-T1"

Informei o CIDR da Rede , neste caso é para o segmento TRANSIT_PRD

Next Hop aqui é o ip da interface Outside do PFsense ( 192.168.30.5) , que está conectada diretamente a este GW T1.

Repeti os mesmos passos para todos os outros Segmentos, sempre com next hop para 192.168.30.5.

Interfaces Firewall Pfsense

Neste cenário o Firewall possui apenas três interfaces.

Deve ser configurada a rota default ( 0.0.0.0/0) para o gateway do Segmento Transit Outside ( 192.168.30.1)

Interfaces do Pfsense

Rotas no Gateways de Transito : T1_PRD_isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.21.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Rotas no Gateways de Transito : T1_DEV_Isolado

Estarei criado uma rota default ( 0.0.0.0/0 ) , com next hop para a interface do Inside do PFsense (192.168.22.5 ) conectada ao Gateway T1 PRD. Devido a limitações do NSX, é necessário "quebrar" em duas: 0.0.0.0/1 e 128.0.0.1/1

Configuração da Rodas default

Next Hop para ip da Interface Inside PFsense.

Teste de Acesso

Tráfego Norte-Sul ( Saída Internet)

Para comprovar que conseguimos agora ter o tráfego Norte-Sul, pelo NVA PFense , irei fazer um teste a partir da máquina no segmento PRD_WEB , com ip 192.168.70.1

É possivel observar que o ip públlico de saída é do AVS

Agora vou criar uma regra no Pfsense bloqueando a porta 443 , mas deixando liberada as outras portas.

Podemos comprovar que o tráfego está sendo inspersionado fazendo um teste de conexão na porta 53 e outro teste https.

No Pfsense podemos ver o bloqueio

Tráfego Leste-Oeste

Para testar o tráfego leste oeste entre os Segmentos PRD_WEB ( VM 192.168.70.10 ) e DEV_WEB ( VM 192.168.80.10) , irei deixar ICMP liberado e bloquear a porta 3389 ( RDP)

Fazendo o teste a partir da máquina 192.168.70.10

Verificando no PFsense o bloqueio da porta 3389

Resumo

Neste laboratório demonstrei como integrar uma NVA ao Azure VMware Solution usando NSX-T com Tier-0/Tier-1, criando T1s isolados para DEV e PRD, segments de trânsito e a configuração de SNAT/NoSNAT no NSX para controlar o egress. Também mostrei o ajuste de rotas para garantir que o tráfego siga pelo caminho de inspeção no firewall. Validei a arquitetura com testes práticos de tráfego Norte-Sul (saída para Internet com IP público do AVS) e Leste-Oeste (controle entre DEV e PRD), comprovando a inspeção via logs e bloqueios aplicados no pfSense. Como próximos passos para produção, recomenda-se padronizar regras, logging, e revisar resiliência/HA do firewall e rotas para reduzir pontos únicos de falha.

Referências

Protegendo Máquinas no Azure VMware Solution com Azure Firewall

LeandroBarbosa — Fri, 17 Oct 2025 20:49:10 GMT

O Azure VMware Solution oferece três opções principais de conectividade outbound para a Internet.

A primeira é o Managed SNAT, opção padrão e totalmente gerenciada pela plataforma, em que o próprio AVS realiza a tradução de endereços (SNAT) para permitir o acesso à Internet. Essa abordagem é simples e não requer configuração adicional, porém não oferece controle sobre os endereços IP públicos utilizados.

A segunda opção é o uso de Public IPs no NSX-T Edge, onde o administrador atribui endereços públicos diretamente ao edge do ambiente AVS. Com isso, o tráfego de saída das máquinas virtuais utiliza esses IPs específicos, permitindo maior controle, ideal para cenários em que é necessário manter IPs fixos ou previamente autorizados em listas de acesso externas.

Por fim, há a opção de rotear o tráfego via rede Azure (ou Azure Virtual WAN), em que uma rota padrão é anunciada por meio do ExpressRoute, direcionando o tráfego de saída para uma rede Azure que contém NVAs, Azure Firewall ou proxies. Essa abordagem oferece o maior nível de controle e segurança, pois permite aplicar inspeção, políticas e NAT centralizados, de forma integrada à arquitetura de rede do cliente.

Neste artigo será demonstrado em um ambiente de laboratório como utilizar o Virtual Wan com Azure Firewall para inspeção do tráfego de saída das Vms em um segmento do AVS

A arquitetura do laboratório.

Virtual Wan com Azure Firewall
ER Gateway conectado ao Express Route do Azure VMware Solution

Os passos necessários são:

Configuração da opção de Internet Connectivity do AVS
Habilitar a propagação da Rota no Vwan
Configuração do Routing Intent

Configuração do Azure VMware Solution.

Acesse o Private Cloud no portal do Azure e certifique que a opção abaixo esteja selecionada.

Fazendo um "dump" das rotas no T0 do NSX, é possível verificar que não temos a rota default sendo propagada.

Portanto não temos conectividade para internet a partir da máquina VM1 que está no AVS.

Habilitando a propagação da Rota default no Virtual Wan

Devemos agora habilitar a propagação da rota default pelo Virtual Wan , e para isso é necessário editar a conexão do Express Route do AVS, conectado ao Hub do Vwan .

Habilite a propagação da Rota default

Routing Intent

O Routing Intent no Azure Virtual WAN é um recurso que simplifica e automatiza o roteamento de tráfego dentro do hub do Virtual WAN. Ele define como o tráfego entre redes (VNets, branches, e Internet) deve ser direcionado, sem necessidade de configurar manualmente tabelas de rotas complexas

Observação: Em geral, no Brasil, caso já exista um Express Route On-premises, o Routing Intent já deve estar ativado para permitir o tráfego na comunicação com o Express Route do AVS, devido a não disponibilidade na região do Brasil do Express Route Global Reach

Nas configurações do HUB, habilite o Routing Intent.

Fazendo um novo "dump"das rotas BGP no NSX, agora é possível observar a rota default sendo propagada.

Testando a partir da VM no AVS

Conforme esperado é o mesmo IP público do meu Firewall no Vwan

Nos Logs do Azure Firewall, comprovamos que o tráfego da VM (10.145.0.10) realmente está passando pelo Azure Firewall

Referências: https://learn.microsoft.com/en-us/azure/azure-vmware/disable-internet-access

Zonas de Disponibilidade no Azure: Entendendo a Diferença entre Zonas Lógicas e Físicas

fabiodasilva — Tue, 26 Aug 2025 13:17:42 GMT

O que é o mapeamento de zonas do Azure (Zona Lógica vs Zona Física)

No Azure, as Zonas de Disponibilidade (AZs) são agrupamentos de datacenters fisicamente separados dentros de uma mesma região. Cada zona possui infraestrutura independente - energia, refrigeração e rede - garantindo alta disponibilidade e resiliência.

Porém, há uma distinção entre:

Tipo de Zona	Definição
Zona Lógica	Identificador exibido no portal do Azure (AZ1, AZ2, AZ3).
Zona Física	Grupo real de datacenters. O mapeamento entre lógica e física varia por assinatura

O mapeamento entre zonas lógicas e físicas não é fixo. Isso significa que:

AZ1 na assinatura A pode ser fisicamente igual à AZ3 na assinatura B.
Sem verificação, você pode estar executando produção e DR na mesma infraestrutura física, anulando os benefícios da separação.

Esse comportamento é intencional e inspirado no modelo da AWS, que também não garante consistência entre zonas lógicas em diferentes contas.

Qual o objetivo desse design?
A motivação por trás desse mapeamento dinâmico é:

Distribuir a carga de consumo de forma mais eficiente entre os datacenters.
Evitar hotspots e garantir resiliência operacional.
Permitir flexibilidade de alocação conforme a capacidade física disponível.

Esse modelo ajuda a balancear o uso da infraestrutura global, sem expor diretamente a topologia física aos clientes — o que também reforça a segurança e abstração da plataforma.

Essa distinção é essencial: a zona lógica AZ1 em uma assinatura pode, na prática, ser a mesma zona física que a AZ3 em outra. Sem uma verificação adequada, o cliente pode acabar executando cargas de produção e de DR (Disaster Recovery) na mesma infraestrutura física, o que anula os benefícios esperados da separação entre zonas.

Exemplo prático de risco

Vamos considerar o seguinte cenário de um cliente:

Produção: AZ1 e AZ2 em uma assinatura A
DR: AZ3 em outra assinatura B, na mesma região

O cliente acredita estar distribuindo suas cargas entre três zonas distintas. No entanto, ao verificar o mapeamento real, encontra a seguinte saída:

[

{ "logicalZone": "1", "physicalZone": "brazilsouth-az3" },

{ "logicalZone": "2", "physicalZone": "brazilsouth-az1" },

{ "logicalZone": "3", "physicalZone": "brazilsouth-az2" }

]

Neste exemplo, a AZ3 lógica está mapeada para a AZ2 física, que já está sendo usada na produção. Ou seja, não há separação física real.

Como verificar o mapeamento de zonas?

Para evitar esse problema, é essencial verificar o mapeamento entre zonas lógicas e físicas em cada assinatura. Use o seguinte comando via Azure CLI:

az rest --method get \

--uri "/subscriptions/<subscription-id>/locations?api-version=2022-12-01" \

--query "value[?name=='<region-name>'].{displayName: displayName,name: name,availabilityZoneMappings: availabilityZoneMappings }" \

-o json

Substitua <subscription-id> e <region-name> (ex: brazilsouth) conforme necessário.

Veja abaixo um exemplo de saída obtida no meu ambiente de laboratório, onde tenho duas assinaturas. Vou executar o mapeamento de zonas entre elas para a região Brazil South.

Na primeira subscription 1 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az1
Zona lógica: 2 – Zona Física: brazilsouth-az2
Zona lógica: 3 – Zona Física: brazilsouth-az3

Na segunda subscription 2 temos o seguinte mapeamento.

Zona lógica: 1 – Zona Física: brazilsouth-az3
Zona lógica: 2 – Zona Física: brazilsouth-az1
Zona lógica: 3 – Zona Física: brazilsouth-az2

Resumindo: Se minha estratégia de DR envolve o uso das zonas lógicas 1 e 2 na subscription 1, pois elas estão mapeadas fisicamente para as zonas AZ1 e AZ2, então, na subscription 2 destinada ao DR, devo utilizar a zona lógica 1 — já que, nessa assinatura, ela está mapeada fisicamente para a AZ3.

Boas práticas

Sempre verifique o mapeamento entre zonas lógicas e físicas antes de definir sua estratégia de DR.
Evite assumir que AZ1, AZ2 e AZ3 representam zonas físicas distintas entre diferentes assinaturas.
Considere utilizar regiões diferentes para DR quando a separação física for um requisito crítico.
Documente e compartilhe o mapeamento com sua equipe de arquitetura e operações para garantir alinhamento e evitar riscos.

Referência oficial

Para mais detalhes, consulte a documentação oficial da Microsoft:

https://learn.microsoft.com/en-us/azure/availability-zones/az-overview

Comparing AWS and Azure regions and zones - Azure Architecture Center | Microsoft Learn

Conectando o Azure Vmware Solution (AVS) com VPN Site to Site em topologia Hub Spoke.

LeandroBarbosa — Mon, 05 May 2025 14:46:04 GMT

A conexão de VPN entre AVS e o ambiente On-premises na maioria das vezes é realizada através do Virtual WAN, conforme descrito em: https://learn.microsoft.com/en-us/azure/azure-vmware/configure-site-to-site-vpn-gateway.

Contudo, caso necessário utilizar em uma topologia Hub-Spoke, existem componentes adicionais que devem ser considerados para permitir o trânsito entre o ExpressRoute do AVS e o VPN Gateway, bem como a propagação das rotas para o ambiente On-premises, assim como é feito por padrão com o Virtual WAN.

Nesta topologia, o Azure Route Server deve ser integrado para habilitar esse trânsito (propagação de rotas)

O objetivo deste artigo é demonstrar em um ambiente de laboratório como conectar um ambiente On-premises com o Azure VMware Solution (AVS) através de uma VPN Site-to-Site em topologia Hub-Spoke.

Arquitetura do Laboratório com topologia Hub-Spoke.

Componentes Azure.

Vnet 10.90.0.0/16 com 3 Subnets.
- Gateway Subnet - 10.90.0.0/24
- RouteServerSubnet - 10.90.1.0/24
- VmSubnet : 10.90.2.0/24
Virtual Network Gateway - VPN
Virtual Network Gateway - Express Route
Azure Route Server
Azure Vm Linux Ubuntu

Componentes On-premises

Firewall VPN PfSense - 192.168.90.0/24 , 192.168.200.0/22 , 192.168.92.0/24

Componetes Azure Vmware Solution

VMware SDDC
Circuito Express Route

*Este laboratório presume que os componentes como o Azure Vmware Solution e ambiente On-premises com Pfsense ou qualquer outro equipamento esteja presente.

1. Deploy componentes Azure

# 1. Variáveis - Altere conforme necessário RESOURCE_GROUP="rg-avs-lab" LOCATION="eastus2" VNET_NAME="vnet-avs-lab" VNET_ADDRESS_PREFIX="10.90.0.0/16" SUBNET_GATEWAY_PREFIX="10.90.0.0/24" SUBNET_ROUTE_SERVER_PREFIX="10.90.1.0/24" SUBNET_GATEWAY_NAME="GatewaySubnet" SUBNET_ROUTE_SERVER_NAME="RouteServerSubnet" EXPRESSROUTE_GW_NAME="er-avs-lab" VPN_GW_NAME="vpn-avs-lab" VPN_GW_IP1_NAME="vpn-gw-ip1" VPN_GW_IP2_NAME="vpn-gw-ip2" VPN_GW_ASN=65515 EXPRESSROUTE_IP_NAME="er-ip" LOCAL_NETWORK_GATEWAY_NAME="local-gw-avs-lab" BGP_PEER_IP="192.168.90.1" ASN_LOCAL=65503 ROUTE_SERVER_NAME="rserver-avs-lab" # Variáveis para subnet e VM SUBNET_VM_NAME="subnet-vm" SUBNET_VM_PREFIX="10.90.5.0/24" VM_NAME="vm-ubuntu" VM_ADMIN_USERNAME='azureuser' VM_ADMIN_PASSWORD='P@ssword123!' # Use um método seguro em produção VM_NIC_NAME="vm-ubuntu-nic" VM_IMAGE="Canonical:0001-com-ubuntu-server-focal:20_04-lts:latest" VM_SIZE="Standard_B2ms" # 2. Criar grupo de recursos az group create --name $RESOURCE_GROUP --location $LOCATION # 3. Criar VNet e subnets az network vnet create \ --resource-group $RESOURCE_GROUP \ --location $LOCATION \ --name $VNET_NAME \ --address-prefixes $VNET_ADDRESS_PREFIX \ --subnet-name $SUBNET_GATEWAY_NAME \ --subnet-prefix $SUBNET_GATEWAY_PREFIX az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_ROUTE_SERVER_NAME \ --address-prefix $SUBNET_ROUTE_SERVER_PREFIX # Criar subnet para a VM az network vnet subnet create \ --resource-group $RESOURCE_GROUP \ --vnet-name $VNET_NAME \ --name $SUBNET_VM_NAME \ --address-prefix $SUBNET_VM_PREFIX # 4. Criar IP público para ExpressRoute az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_IP_NAME \ --sku Standard \ --allocation-method Static # 5. Criar Gateway ExpressRoute az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $EXPRESSROUTE_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $EXPRESSROUTE_IP_NAME \ --gateway-type ExpressRoute \ --sku Standard # 6. Criar IPs públicos para VPN Gateway ativo-ativo az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP1_NAME \ --sku Standard \ --allocation-method Static az network public-ip create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_IP2_NAME \ --sku Standard \ --allocation-method Static # 7. Criar VPN Gateway az network vnet-gateway create \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --location $LOCATION \ --vnet $VNET_NAME \ --public-ip-addresses $VPN_GW_IP1_NAME $VPN_GW_IP2_NAME \ --gateway-type Vpn \ --vpn-type RouteBased \ --sku VpnGw1 # Após a criação, configurar ativo-ativo e BGP az network vnet-gateway update \ --resource-group $RESOURCE_GROUP \ --name $VPN_GW_NAME \ --set activeActive=true enableBgp=true bgpSettings.asn=$VPN_GW_ASN # 8. Criar Local Network Gateway com BGP e ASN az network local-gateway create \ --resource-group $RESOURCE_GROUP \ --name $LOCAL_NETWORK_GATEWAY_NAME \ --gateway-ip-address $BGP_PEER_IP \ --local-address-prefixes "192.168.90.0/24" \ --asn $ASN_LOCAL \ --bgp-peering-address $BGP_PEER_IP \ --location $LOCATION # 9. Criar conexão VPN entre o Gateway de VPN e o Local Network Gateway az network vpn-connection create \ --resource-group $RESOURCE_GROUP \ --name vpn-s2s-connection \ --vnet-gateway1 $VPN_GW_NAME \ --local-gateway2 $LOCAL_NETWORK_GATEWAY_NAME \ --shared-key 'teste@123' \ --enable-bgp # 10. Criar NIC para a VM az network nic create \ --resource-group $RESOURCE_GROUP \ --name $VM_NIC_NAME \ --vnet-name $VNET_NAME \ --subnet $SUBNET_VM_NAME # 12. Criar VM com Ubuntu az vm create \ --resource-group $RESOURCE_GROUP \ --name $VM_NAME \ --nics $VM_NIC_NAME \ --image $VM_IMAGE \ --admin-username $VM_ADMIN_USERNAME \ --admin-password $VM_ADMIN_PASSWORD \ --size $VM_SIZE \ --location $LOCATION

2. Conectando o Express Route do AVS no VPN Gateway da Hub.

No Virtual Network Gateway de ER , adicione uma conexão

Defina o connection type como ExpressRoute

No AVS, copie o authorization key e o ExpressRoute ID

Para este cenário será utilizado o modelo de resiliência standard, o Virtual network gateway, informe um nome para conexão, insira a "authorization key" e "ExpressRoute ID" (per cirtuit URI) copiados nos passos acima e execute o deploy.

Verificando que a conexão foi estabelecida com sucesso.

Verificando as rotas na Vm de teste.

Ao verificar as rotas do Pfsense ( onprem) , é possível observar que não temos as rotas do AVS, somente da Vnet do Azure.

Para habilitar o trânsito e troca de rotas entre o Express Route do AVS e o VPN gateway precisamos inserir o Azure Route Server.

3. Deploy do Azure Route Server.

#Criar Azure Route Server #Cria Public IP para o Route Server az network public-ip create --resource-group $RESOURCE_GROUP --name routeserver-pip --sku Standard --allocation-method Static # Identifica o ID da Subnet do Route Server SUBNET_ID=$(az network vnet subnet list --resource-group $RESOURCE_GROUP --vnet-name $VNET_NAME --query "[?name=='$SUBNET_ROUTE_SERVER_NAME'].id" --output tsv) # Cria o Route Server az network routeserver create \ --resource-group $RESOURCE_GROUP \ --name $ROUTE_SERVER_NAME \ --hosted-subnet $SUBNET_ID \ --location $LOCATION \ --public-ip-address routeserver-pip

Após criado habilitamos a opção Branch-to-Branch

Podemos verificar que agora as rotas do AVS (172.30.0.0/22), agora foram propagadas para o Pfsense.

Validando acesso ao Vcenter do AVS.

Referências:

https://learn.microsoft.com/en-us/azure/route-server/overview

https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke

Acessar o Azure ARC com Private Endpoint e Azure Firewall Explicit Proxy - Parte 1

fabiodasilva — Wed, 22 Jan 2025 17:03:37 GMT

Benefícios de Usar o Azure ARC

O Azure ARC permite gerenciar recursos de TI, independentemente de onde eles estejam hospedados, seja no Azure, em outras nuvens ou em infraestruturas locais (on-premises).

Azure Arc solution overview architecture

Fonte: Azure Arc overview - Azure Arc | Microsoft Learn

Entre os principais benefícios de usar o Azure ARC podemos citar os seguintes.

Gestão Centralizada: Permite o gerenciamento de recursos multi-cloud e on-premises
Consistência de Ferramentas: Com o Azure ARC, é possível usar as mesmas ferramentas e processos que você já utiliza no Azure para gerenciar recursos em qualquer infraestrutura, proporcionando uma experiência consistente.
Segurança e Conformidade: A tecnologia permite aplicar políticas de segurança e conformidade de maneira uniforme em todos os ambientes, garantindo que os padrões corporativos sejam mantidos em qualquer lugar.
Escalabilidade: O Azure ARC facilita a escala de operações de TI de acordo com as necessidades do negócio, sem as limitações típicas das infraestruturas locais.
Automatização: A automatização de processos de gerenciamento através de scripts e ferramentas Azure Resource Manager (ARM) pode ser estendida a recursos fora do Azure, melhorando a eficiência operacional.
Monitoramento e Insights: O Azure ARC integra-se com ferramentas de monitoramento do Azure, permitindo visibilidade centralizada e insights detalhados sobre o desempenho e a integridade de todos os recursos.

Ao utilizar o Azure ARC, as organizações podem maximizar os investimentos existentes em infraestrutura, melhorar a governança e aprimorar a flexibilidade e a agilidade operacionais, tudo isso enquanto mantêm uma gestão centralizada e consistente.

Benefício de usar Private Endpoints

Utilizando o Azure ARC com private endpoints, o tráfego de rede entre os recursos gerenciados e o Azure permanece dentro da rede privada, aumentando a segurança, proteção dos dados e o desempenho. Essa configuração reduz a exposição a ameaças externas e cumpre exigências regulatórias ao assegurar que os dados sensíveis não transitem pela internet pública.

Desafios no Acesso ao Azure Arc com Azure Firewall, Explicit Proxy e Private Endpoint

Conectar um recurso local ao Azure por meio do Azure Arc e utilizar extensões habilitadas para Arc requer comunicação com um conjunto de serviços do Azure, cada um com seus próprios endpoints de destino. Para clientes que utilizam proxies corporativos, é necessário permitir o acesso a todos esses endpoints.
Atualmente, o gateway do Arc reduz o número de url's que precisam ser permitidos por meio de um proxy corporativo, mas exige que o tráfego seja roteado para o Azure pela Internet pública. No entanto, alguns clientes precisam que todo o tráfego alcance o Azure por meio do seu circuito de ExpressRoute ou através da VPN Site a Site.
Embora parte dos endpoints necessários podem ser roteados pelo Microsoft Peering ou Private Peering do ExpressRoute, nem todos os endpoints são compatíveis com essas opções.

Firewall do Azure como um proxy sobre ER ou VPN site a site

Os clientes que precisam que todo o tráfego alcance o Azure por meio do ExpressRoute ou VPN Site-to-Site pode hospedar um proxy de encaminhamento em sua rede virtual do Azure.
O agente Arc pode então se comunicar com esse proxy de encaminhamento por meio de um IP privado, seja por meio do ExpressRoute ou VPN Site-to-Site.
O Firewall do Azure com o recurso Proxy Explícito (Visualização Pública) pode ser aproveitado como esse proxy de encaminhamento.

Disclaimer: O Azure Firewall com Explicit Proxy é um recurso atualmente em preview. Isso significa que ele está sujeito a alterações e pode não estar disponível em todas as regiões ou com todas as funcionalidades de produção. Para mais informações, consulte os termos de uso para preview.

O diagrama abaixo representa essa arquitetura

Etapas para o uso do Azure Firewall com explicit proxy

Passo 1: Precisamos habilitar o uso do Azure Firewall com a feature de Explicit Proxy conforme a documentação de referência aqui

Passo 2: Em seguida realizado o onboard dos servidores para o Azure ARC. Observe que o IP privado do Firewall do Azure como o proxy de encaminhamento nas configurações.

No Portal do Azure

Usando a CLI de comando

Servidores ARC

azcmagent config set proxy.url <Azure Firewall Private IP:Port>

azcmagent config CLI reference - Azure Arc | Microsoft Learn

Passo 3: Crie uma regra de aplicativo para permitir os endpoints necessários do Azure ARC para seu cenário de acesso através do Firewall

No próximo artigo, vamos montar um laboratório passo a passo, detalhando as configurações e os requisitos necessários para utilizar o private endpoint e o explicit proxy do Azure Firewall, conforme ilustrado no diagrama abaixo

Referências:

Azure Arc overview - Azure Arc overview - Azure Arc | Microsoft Learn
Informações gerais e preço - Azure Arc – Hybrid and Multi-Cloud Management and Solution (microsoft.com)
Azure Firewall Explicit Proxy - Azure Firewall Explicit proxy (preview) | Microsoft Learn

Passo a Passo para Criar um Filtro de Tag no FinOps Hub

arsilvan — Fri, 20 Sep 2024 15:01:20 GMT

Recentemente, publiquei um blog sobre implementação e gerenciamento de custos do Azure usando FinOps Hub no formato FOCUS. Confira aqui. Agora, vou explicar como criar um filtro de Tag no FinOps Hub para otimizar a gestão de custos.

1. Acesse o Dashboard CostSummary do FinOps Hub

Primeiro, abra o seu dashboard CostSummary do FinOps Hub. Esta versão que estamos trabalhando seria a V0.4. Em seguida, clique na aba de Resources. Você vai notar na tabela que existe uma coluna de Tag, porém ela não está formatada e não possui um filtro. O objetivo é corrigir a coluna e adicionar um filtro de tag para centro de custo. As Tags são referentes ao meu ambiente.

De acordo com a figura abaixo, selecione a opção para transformar dados e adicionaremos o filtro de tag.

2. Navegue até a Seção de Filtragem

No painel principal, localize e clique em CostDetails. Em seguida, encontre a coluna x_TagsDictionary, clique no item ao lado do nome e selecione a Tag centro_de_custo. No meu exemplo, também adicionei a Tag Environment. Antes de clicar em OK, desmarque a opção "Use original column name as prefix." E em seguida clique em OK

3. Selecione "Criar Novo Filtro"

Ao clicar em OK, serão adicionadas mais duas colunas, centro_de_custo e Environment, conforme ilustrado no exemplo abaixo. Em seguida clique em Close & Apply

4. Criação do Fitro de Tag

Na View de Resources, copie e cole o filtro de subscription com Ctrl+C e Ctrl+V e arraste-o para perto da view de Total Savings.

5. Alterar o Filtro Subscription para Filtro de Tag

Selecione o filtro Subscription e, em Data, localize a tag centro_de_custo. Arraste o item centro_de_custo para field e depois exclua o Field Subscription.

6. Nova View para o Filtro Centro de Custo

A visualização será parecida com o exemplo a seguir

7. Alterar a Tabela para fitrar por Tag Centro De Custo

Precisamos agora modificar a tabela para aplicar o filtro ao centro de custo.

Selecione a tabela e encontre no campo Data a tag centro_de_custo.

Arraste o item centro_de_custo nas Colunas, como mostrado abaixo, e remova Tags da coluna.

Com essas etapas concluídas, você deve ter uma nova visualização que reflete o filtro aplicado ao centro de custo. Essa configuração permitirá uma análise mais detalhada e específica, facilitando a identificação de gastos associados a cada centro de custo.

Finalmente, salve as alterações feitas e atualize o dashboard para garantir que todas as modificações foram aplicadas corretamente. Agora, ao utilizar o filtro de centro de custo, você poderá visualizar apenas os dados relevantes conforme sua necessidade, tornando a análise financeira mais eficiente e direcionada.

Configurando Azure ARC com Private Link.

LeandroBarbosa — Wed, 26 Jun 2024 00:03:02 GMT

O Azure Arc facilita o gerenciamento em ambientes híbridos e multi-cloud por meio de um único painel. Com o Azure Arc, é possivel aplicar os recursos de gerenciamento e segurança do Azure aos seus recursos de outras nuvens, e on-premises, como servidores, clusters Kubernetes e serviços de dados.

Gerenciar recursos do Azure Arc em diferentes redes e firewalls pode apresentar alguns desafios como por exemplo precisar expor pontos de extremidade públicos para seus recursos, o que pode aumentar o risco de acesso não autorizado e ataques maliciosos.

Desta forma, o Azure Arc Private Links é uma solução que facilita e segura a conexão entre seus recursos do Azure Arc e o Azure. Com o Azure Arc Private Links, é possiível criar pontos de extremidade privados para seus recursos do Azure Arc dentro de uma rede virtual do Azure e acessá-los usando endereços IP privados e assim evitar expor pontos de extremidade públicos e proteger seus recursos de riscos de rede. Você também pode diminuir a latência e os custos de largura de banda da rede, direcionando o tráfego pela rede principal do Azure.

Ao utilizar extensões de VM que funcionam com os servidores no Azure Arc, como por exemolo : Gerenciamento de Atualizações, Automação do Azure ou o Azure Monitor, esses recursos se conectam a outros recursos do Azure, como o Workspace do Log Analytics, Conta de Automação do Azure, Cofre de Chave do Azure e o Armazenamento de Blobs que também devem ter seus próprios links privados.

No entanto, até o momento deste artigo, existem algumas restrições em que o tráfego ainda precisa ser realizadas para URLS públicas, como por exemplo, para acesso ao Entra ID, Azure Resource Manager, Windows Admin Center e SSH. A figura abaixo apresenta este fluxo de conexão.

Objetivo

O propósito deste artigo é demostrar em um ambiente de laboratório como configurar o Azure ARC com private link e ajustar o agente do azure arc para acessar as urls públicas por meio de um proxy.

O ambiente de laborátorio consiste em:

On-premises

Servidor Active Directory - Domain Controller (ADDS) : 10.168.101.4
Servidor (para onboard no arc) com Windows Sever 2022 : VM01
Proxy Server ( Pfsense/squid) : 192.168.101.1
VPN Site to Site

Azure

Vnet Hub com :
- Servidor Active Directory - Domain Controller (ADDS) : 10.10.0.4
- VPN Gateway

Arquitetura do ambiente de laboratório.

Criando o ARC Private Scope

No portal do Azure , pesquise por Azure ARC e selecione “Private link scopes” e depois em “Create”

Insira a subscription , resource goup , região e o nome para o Private link Scope.

Selecione “Create” para criar o Private Endpoint e complete as informações a direita. Utilizarei uma já existente chamada “Vnet-Arc” e Mantenha habilitada a opção de DNS Integration

Valide as informações e depois vai em : “create”.

Valide os recursos criados no RG.

Realizando Link do Private DNS Zone.

Ao acessar a zona de DNS privada que foi criada, é possível ver que o link com a Vnet-Arc já foi feito automaticamente. Como meu servidor de DNS (Controlador de Domínio) está em uma vnet diferente, eu também preciso criar o link com ela.

Integração DNS do Private Endpoint

Para integração de dns com private endpoint existem vários modelos : Azure Private Endpoint DNS integration | Microsoft Learn

No meu caso utilizarei o modelo de integração com custom DNS, pois já tenho um Domain Controller no Azure. Assim, vou usar encaminhadores condicionais, conforme descrito em: https://github.com/dmauser/PrivateLink/tree/master/DNS-Integration-Scenarios#42-custom-dns-server.

Para isso irei configurar encaminhadores no meu DC on-premises e também no Azure.

DNS do Domain Controller on-premises.

No meu Domain Controller on-premises estarei criando o Encaminhador Condicional : his.arc.azure.com e guestconfiguration.azure.com apontando para meu Domain Controller no Azure (10.10.0.4).

DNS do Domain Controller no Azure

No servidor Domain Controller do Azure eu crios os mesmos Contional Forwarders his.arc.azure.com e guestconfiguration.azure.com , porém apontando para o Ip do Azure DNS (168.63.129.16) .

Validando a Resolução de nomes.

Vou testar com nslookup a resolução dos endereços gbl.his.arc.azure.com e gbl.privatelink.his.arc.azure.com, o resultado esperado é o ip 10.13.0.10 conforme abaixo.

A partir do servidor on-premises, o resultado é conforme esperado.

Conectando no ARC

Para fazer o onboarding no ARC vou gerar um o Script de Configuração.

Pesquisar por ARC , na coluna selecione “Machines” , depois em add/create .

Para este lab criarei o script para somente um servidor.

Selecione o Método de conectividade como Private Endpoint e selecione o Link Scope criado anteriormente e “Download and run”

Será apresentado o script para copiar ou fazer o download.

Instalação do Agente no Servidor on-premises.

Conforme Documentação oficial mesmo com private link algumas URLS, públicas ainda precisam ser liberadas.

https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#urls

Após a liberação das URLs no servidor proxy realizei a configuração de proxy settings na máquina onde irei rodar o script, inclusive inserindo as urls do private endpoint para o não uso de proxy.

Porém ao executar o script de onboarding recebi o erro: “The remote server returned an error: (504) Gateway Timeout”

Devido este cenário de "rede dividida", em que algumas URLs, como por exemplo de autenticação no Entra ID, devem ir pela internet via proxy, mas o tráfego para os endpoints privados do ARC não. É necessário configurar o agente do ARC para os serviços que devem usar o proxy.

Para isto pode-se configurar dois parâmetros :

config set proxy.url : Endereço do Proxy.
config set proxy.bypass : Valor conforme tabela abaixo da URls privadas

Desta forma, vou fazer a instalação do agente de forma manual direto pelo link https://aka.ms/AzureConnectedMachineAgent , (em um ambiente Entreprise poderia ser via SCCM, Gpo ,Intune, etc.)

Ao realizar um check de conectividade com o comando :

*Altere o parâmetro “location” conforme foi região onde foi criado o private link. No meu caso é EastUS

azcmagent check --location "eastus" --enable-pls-check

É possível observar no resultado que os endpoints privados estão sendo alcançados, porém os públicos não.

No script de onboarding gerado anteriormente vou comentar as linhas que fazem a instalação do agente ( já instalado) e adicionar as linhas a seguir com os parâmetros para o proxy.

& “$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" config set proxy.url "http://192.168.101.1:3128"

& "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" config set proxy.bypass "Arc"

Ao executar novamente o script recebo o prompt para login e insiro as credenciais.

Realizando a verificação de conectividade novamente pelo comando :

azcmagent check --location "eastus" --enable-pls-check

É possível observar que agora todos os endpoints estão alcançáveis. E os endereços públicos estão com o proxy configurado ( set) e realizando o bypass para o endereços privados.

Ao acessar o portal do azure é possível que a máquina está com o status de conectada no ARC.

Referências

Como Implementar e Gerenciar Seus Custos do Azure com FinOps Hub no Formato FOCUS 🚀

arsilvan — Mon, 03 Jun 2024 16:48:40 GMT

Tutorial Implementação do FinOps Hub para Análise de Custos

Se você está buscando uma plataforma confiável para analisar seus custos, obter insights e tomar ações baseadas em dados, está no lugar certo. Neste artigo, vou mostrar o passo a passo de como implementar a solução do FinOps Hub no seu ambiente e aproveitar os diversos relatórios de custos disponíveis no repositório deste projeto.

O Que é o FinOps?

Antes de começarmos, é importante entender o que é o FinOps e como o kit de Ferramentas do FinOps Hub vai ajudá-lo na análise de custos.

FinOps é uma estrutura operacional e prática cultural que maximiza o valor comercial da nuvem. Ela permite a tomada de decisões baseadas em dados e cria responsabilidade financeira por meio da colaboração entre equipes de engenharia, finanças, tecnologia e operações comerciais. Esta disciplina envolve o uso de ferramentas de gerenciamento de custos na nuvem, como o Microsoft Cost Management, e práticas recomendadas, como:

Analisar e acompanhar os gastos com a nuvem.
Identificar oportunidades de redução de custos.
Alocar custos para equipes, projetos ou produtos específicos.

A Microsoft recentemente anunciou uma parceria estratégica com a FinOps.org, uma organização líder no desenvolvimento de práticas de gerenciamento financeiro em nuvem. Essa colaboração visa aprimorar as capacidades de governança financeira e otimização de custos para empresas que utilizam a plataforma Azure.

Combinando a expertise da Microsoft em tecnologia de nuvem com as práticas recomendadas e frameworks desenvolvidos pela FinOps.org, as organizações poderão obter maior transparência, controle e eficiência em seus investimentos em nuvem. Essa aliança promete fortalecer as ferramentas e recursos disponíveis para empresas, facilitando uma gestão financeira mais inteligente e estratégica no ambiente digital.

Benefícios do FinOps Hub

O FinOps Hub vai ampliar o gerenciamento de custos ao exportar detalhes para uma conta de armazenamento consolidada, superando algumas limitações quando coletamos estes dados por API. Na sua forma básica, ele habilita opções adicionais de relatórios no Power BI. Em um nível avançado, ele serve como base para criar sua própria solução de gerenciamento e otimização de custos.

Princípios de Design do FinOps Hub

O FinOps Hub se concentra em três princípios básicos de design:

Padronizado: Este princípio se esforça para ser o exemplo máximo do Framework de FinOps, demonstrando seus princípios, práticas e valores de forma exemplar.
Construído para Escala: Projetado para suportar as maiores contas e organizações.
Aberto e Extensível: Abraça o ecossistema e prioriza a habilitação da plataforma.

Comparação com o Microsoft Cost Management

Uma pergunta comum é por que usar o FinOps Hub se já existe o Cost Management. Muitas organizações que utilizam o Microsoft Cost Management encontram obstáculos quando necessitam de recursos que não estão disponíveis nativamente. Nessas situações, as opções são limitadas a utilizar ferramentas de terceiros ou desenvolver uma solução do zero. O FinOps Hub oferece uma base para facilitar a criação de soluções personalizadas de gerenciamento de custos.

Vantagens do FinOps Hub

Acesso Simplificado: Você não precisa conceder acesso no portal do Azure para utilizar o Cost Management.
Templates de Relatórios: Ele oferece templates de relatórios do Power BI que podem ser publicados online.

Funcionamento do FinOps Hub

A exportação é baseada no FinOps Open Cost and Usage Specification (FOCUS), uma iniciativa para definir um formato comum para dados de faturamento. O FOCUS inclui dados atuais e amortizados, reduzindo até 30% de dados no storage account e processamento, e está alinhado com o Framework do FinOps.

Processo de Exportação e Ingestão de Dados

O Gerenciamento de Custos exporta detalhes de custo bruto para o contêiner msexports.
O pipeline de msexports_ExecuteETL inicia o processo ETL (extract-transform-load) quando os arquivos são adicionados ao armazenamento.
O pipeline msexports_ETL_ingestion salva os dados exportados em formato parquet no contêiner de ingestão.
O Power BI lê dados de custo do contêiner de ingestão.

Custos do FinOps Hub

O custo médio é de 25 dólares por 1 milhão de linhas, mas o custo exato da solução pode variar, principalmente devido ao armazenamento de dados e à frequência de ingestão dos dados. Os pipelines operam uma vez por dia por exportação, ajudando a manter os custos sob controle e garantindo uma gestão eficiente dos dados.

Conclusão

Considerando os ganhos em termos de eficiência, automação e precisão que essa solução pode oferecer, o investimento pode ser justificado, trazendo retorno em médio a longo prazo. Agora, vamos para a prática!

O FinOps Hub é projetado pela comunidade. Você pode se juntar à discussão pelo link na descrição do vídeo e comentar o que gostaria de ver a seguir ou aprender a contribuir e fazer parte da equipe.

Quer assistir ao vídeo com o passo a passo para implementar o FinOps Hub baseado no Focus? Aperte o play no vídeo abaixo ou, se preferir, acesse

Deseja contribuir com o projeto e interagir com a comunidade? Visite o FinOps hubs - FinOps toolkit (microsoft.github.io)

Até mais!

Azure Arc Enabled Servers (ESU) - BackBilling

fabiodasilva — Tue, 30 Jan 2024 13:08:23 GMT

Explorando a Gestão de Atualizações de Segurança Estendidas no Azure Arc Enabled Servers(ESU)

Introdução

Com o surgimento da computação híbrida e a necessidade de gerenciar servidores distribuídos em vários locais, a Microsoft introduziu o Azure Arc. Essa plataforma permite estender os serviços do Azure para qualquer infraestrutura, incluindo servidores locais. Neste artigo, vamos explorar como o Azure Arc, para este exemplo foi utilizado o Azure Update Management (também podemos usar soluções como Windows Update, Windows Server Update Service e Catalogo) e Atualizações de Segurança Estendidas (ESU), oferece uma solução abrangente para manter servidores Windows Server 2012 e Windows Server 2012 R2 em conformidade e seguros.

Azure Arc Enabled Servers

O Azure Arc permite que você gerencie servidores Windows e Linux, independentemente de onde eles residam, como extensões do Azure. Com o Azure Arc Enabled Servers, você pode aproveitar recursos do Azure, como o Azure Policy, Azure Monitor e muito mais, mesmo em seus servidores onpremise ou em outros provedores de nuvem. Para saber mais sobre como conectar servidores para o Azure visite a documentação Visão geral do agente do Azure Connected Machine - Azure Arc | Microsoft Learn

Atualizações de Segurança Estendidas (ESU)

Alguns ambientes exigem suporte estendido para atualizações de segurança além dos ciclos de vida padrão. Aqui é onde entra o conceito de Atualizações de Segurança Estendidas (ESU). Com o Azure Arc Enabled Servers, você pode estender a cobertura de segurança para servidores que precisam de suporte adicional. Com ESUs, os clientes que executam o Windows Server 2012 e Windows Server 2012 R2 no local ou em outras nuvens podem obter mais três anos de atualizações críticas de segurança da Microsoft para proteger seu fim do suporte.

Entendendo o Back-Billing para Azure Arc (Windows Server 2012 e Windows Server 2012 R2)

No mundo do Azure Arc e suas extensões de segurança estendidas (ESU), o conceito de Back-Billing pode parecer desconhecido ou negligenciado por muitos. No entanto, é um aspecto crucial que merece atenção ao ativar serviços para sistemas como o Windows Server 2012 e 2012 R2 no Azure Arc.

O Que é Back-Billing?

Para elucidar, o Back-Billing refere-se a uma cobrança retroativa que pode ocorrer ao ativar serviços como ESU em determinados sistemas, como experimentei em primeira mão. Ao ativar o serviço em um determinado dia, podemos notar que vamos ter uma cobrança em nossa fatura retroativa, considerando-a como uma cobrança atrasada a partir de 10/10/2023 referente a ativação.

A seguir iremos verificar a funcionalidade do ESU na prática. Para o nosso laboratório não iremos detalhar a instalação do agente, ficará para um próximo artigo e sim iremos validar e ESU em um computador com Windows Server 2012 previamente conectado ao Azure Arc.

Pré-requisitos para o ESU

Prepare o agente do Azure Connected Machine (versão 1.34 ou superior) nos computadores com Windows Server 2012 e Windows Server 2012 R2 para conexão com o Azure Arc. O ESU terá suporte para as edições do Windows Server 2012 e Windows Server 2012 R2 Standard e Datacenter.
Siga a documentação KB5031043: Procedure to continue receiving security updates after extended support has ended on October 10, 2023 - Microsoft Support para a instalação do pacote de licenciamento e da atualização da stack de serviços (SSU) do servidores Windows Server 2012 e Windows Server 2012 R2 habilitados para Azure Arc.
Updates Windows Server 2012 e Windows Server 2012 R2
- Windows Server 2012 R2
  - Stack update (SSU) (KB5029368)
  - Extended Security Updates (ESU) Licensing Preparation Package that is dated August 10, 2022 (KB5017220).
- Windows Server 2012
  - Stack update (SSU) (KB5029369)
  - Extended Security Updates (ESU) Licensing Preparation Package that is dated August 10, 2022 (KB5017221)
Verifique o modo de conexão do agente com o Azure Arc. As opções de conectividade incluem o endpoints públicos, servidor proxy e link privado. Examine os pré-requisitos de rede para preparar ambientes não Azure para implantação no Azure Arc.
Se você estiver usando servidores habilitados para Azure Arc apenas para fins de Atualizações de Segurança Estendidas do Windows Server 2012 e Windows Server 2012 R2 (ESU), poderá habilitar o seguinte subconjunto de pontos de extremidade mencionados na documentação Como se preparar para fornecer Atualizações de Segurança Estendidas para o Windows Server 2012 por meio do Azure Arc - Azure Arc | Microsoft Learn

Em nosso laboratório temos um computador local com Windows Server 2012 previamente conectado aos serviços do Azure Arc e com as atualizações requeridas para o ESU.

Verificar licenças de ESU Windows 2012 e vincular ao Windows 2012

Não iremos passar pelas etapas de criação da licença do ESU, este será um tema dedicado para outro artigo, mas como referência visite a documentação Deliver Extended Security Updates for Windows Server 2012 - Azure Arc | Microsoft Learn

No nosso laboratório temos uma licença provisionado do ESU e vinculada para a nossa máquina de teste.

Por meio de um navegador, entre no portal do Azure.
Na página do Azure Arc, selecione Azure Arc | Extended Security Updates no painel esquerdo. Podemos visualizar nossa licença de Windows 2012 Datacenter esu-wk12.

Selecione a licença e em seguida clique em "Linked resources", podemos visualizar que a licença do ESU está atribuída para a nossa máquina srv1-2012.

Verificar Cost Management

Podemos verificar no Cost Analysis da nossa subscription o valor referente ao ESU Back Billing referente o total acumulado desde 10 de Outubro de 2023 até o momento que habilitado este recurso no meu ambiente e o valor.

FAQ

Consulte o documento de Perguntas Frequentes sobre Ciclo de Vida do Produto ‒ Atualizações de Segurança Estendida, temos informações como expectativas de suporte, critérios de classificação e implantação e muito mais.

Resumo

O Azure Arc Back Billing impõe cobranças retroativas para licenças provisionadas após a data de Fim do Suporte (EOS) em outubro de 2023. Por exemplo, uma licença ESU provisionada em dezembro de 2023 será faturada retroativamente para outubro e novembro após o provisionamento como mencionado na documentação Billing service for Extended Security Updates for Windows Server 2012 through Azure Arc

Mais informações

Visão geral de servidores habilitados para Azure Arc - Azure Arc | Microsoft Learn

KB5031043: Procedure to continue receiving security updates after extended support has ended on October 10, 2023 - Microsoft Support

Como se preparar para fornecer Atualizações de Segurança Estendidas para o Windows Server 2012 por meio do Azure Arc - Azure Arc | Microsoft Learn

Fornecer atualizações de segurança estendidas para o Windows Server 2012 - Azure Arc | Microsoft Learn

Billing service for Extended Security Updates for Windows Server 2012 through Azure Arc - Azure Arc | Microsoft Learn

Monitorando Recursos Criados na Azure com Kusto Query Language (KQL) e Log Analytics

fabiodasilva — Mon, 30 Oct 2023 14:35:03 GMT

Monitorando Recursos Criados na Azure com Kusto Query Language (KQL) e Log Analytics

Este artigo técnico destina-se a fornecer uma visão geral básica de como monitorar recursos recém-criados na plataforma Microsoft Azure usando a Linguagem de Consulta Kusto (KQL) e o recurso Log Analytics. O AzureActivity é uma tabela especial do Log Analytics que registra todas as atividades do Azure. Através da análise e filtragem dos registros nesta tabela usando KQL, é possível identificar e acompanhar recursos criados recentemente, auxiliando na detecção de possíveis eventos indesejados ou suspeitos.

Introdução

O monitoramento de atividades em nuvem é essencial para garantir a segurança, o desempenho e a conformidade das implantações na Microsoft Azure. A tabela AzureActivity, disponível no serviço Log Analytics, fornece informações detalhadas sobre todas as atividades realizadas em uma assinatura do Azure, incluindo criação de recursos, atualizações e exclusões. Usando a Linguagem de Consulta Kusto (KQL), podemos filtrar e analisar esses registros para obter insights valiosos sobre os recursos recém-criados.

Pré-requisitos:

Uma conta do Microsoft Azure com permissões de acesso ao serviço Log Analytics.
Familiaridade básica com Kusto Query Language (KQL) e conceitos de Log Analytics.

Passo 1: Acessando o Log Analytics e a tabela AzureActivity

Antes de começar a consulta, certifique-se de que possui acesso ao serviço Log Analytics e à tabela AzureActivity em sua assinatura do Azure. Verifique se você possui permissões adequadas para executar consultas no Log Analytics.

Passo 2: Escrevendo a Consulta Kusto (KQL)

A consulta Kusto que utilizaremos para monitorar recursos criados na Azure é a seguinte:

AzureActivity | where TimeGenerated > ago(7d) | extend isValidGuid = Caller matches regex "[A-Fa-f0-9]{8}-[A-Fa-f0-9]{4}-[1-5][A-Fa-f0-9]{3}-[89ABab][A-Fa-f0-9]{3}-[A-Fa-f0-9]{12}" | where OperationNameValue endswith "Write" and ActivitySubstatusValue contains "Created" and not (isValidGuid) | where not( OperationNameValue has_any ("Deployments","SSHPUBLICKEYS","NETWORKWATCHERS","VIRTUALMACHINES/EXTENSIONS","ACTIONGROUPS","SCHEDULEDQUERYRULES")) | order by TimeGenerated asc | project SubscriptionId, ResourceGroup, Caller, CallerIpAddress, OperationNameValue, ActivitySubstatusValue, _ResourceId

Passo 3: Explicação da Consulta Agora, vamos entender cada etapa da consulta Kusto:

A cláusula AzureActivity indica que estamos consultando a tabela AzureActivity.
| where TimeGenerated > ago(7d): Filtra os registros para incluir apenas aqueles gerados nos últimos 7 dias.
| extend isValidGuid = Caller matches regex "[A-Fa-f0-9]{8}-[A-Fa-f0-9]{4}-[1-5][A-Fa-f0-9]{3}-[89ABab][A-Fa-f0-9]{3}-[A-Fa-f0-9]{12}": Cria uma nova coluna chamada isValidGuid que verifica se o valor da coluna Caller corresponde a um padrão de GUID válido.
| where OperationNameValue endswith "Write" and ActivitySubstatusValue contains "Created" and not (isValidGuid): Filtra os registros para incluir apenas aqueles em que:

OperationNameValue termina com a string "Write".
ActivitySubstatusValue contém a string "Created".
isValidGuid é falso, ou seja, o valor da coluna Caller não corresponde a um GUID válido.

| where not( OperationNameValue has_any ("Deployments","SSHPUBLICKEYS","NETWORKWATCHERS","VIRTUALMACHINES/EXTENSIONS","ACTIONGROUPS","SCHEDULEDQUERYRULES")): Filtra os registros para excluir aqueles em que o valor da coluna OperationNameValue tem algumas strings específicas, como "Deployments" e "VIRTUALMACHINES/EXTENSIONS".
| order by TimeGenerated asc: Classifica os resultados em ordem crescente com base no valor da coluna TimeGenerated.
| project SubscriptionId, ResourceGroup, Caller, CallerIpAddress, OperationNameValue, ActivitySubstatusValue, _ResourceId: Exibe apenas as colunas SubscriptionId, ResourceGroup, Caller, CallerIpAddress, OperationNameValue, ActivitySubstatusValue e _ResourceId nos resultados.

Passo 4: Verificando os registros

Ao executar esta query no workspace do log Analytics onde os logs de atividades estão sendo armazenado, consigo verificar a lista de recursos criados nos últimos 7 dias.

Passo 5: Visualizando os dados através de um workbook

Uma possibilidade será criar um alerta ou visualizar as informações através de painel de monitoramento ou de um workbook.

Iremos comentar a linha 2 da query correspondente ao time range desejado, pois iremos usar um parâmetro de “TimeRange” do Workbook.

Para construir o workbook clique em “Pin to” conforme ilustrado na imagem e selecione a opção “Send to workbook”.

Podemos criar um workbook ou usar um existente, mas no nosso caso iremos criar um novo workbook para visualização dos recursos criados. Marque a opção “Add a time range parameter ans have generated steps reference it” e selecione o query correspondente conforme ilustrado na imagem.

Com isso temos nosso workbook que nos ajudará a visualizar os recursos criados na Azure.

Conclusão

Através da Linguagem de Consulta Kusto (KQL) e da tabela AzureActivity no Log Analytics, podemos monitorar e rastrear recursos recém-criados na plataforma Azure. A consulta apresentada neste artigo permite identificar atividades suspeitas e potencialmente indesejadas, ajudando os administradores a garantirem a segurança e o compliance de suas implantações na nuvem. Monitore constantemente a tabela AzureActivity e adapte suas consultas conforme necessário para manter seu ambiente seguro e eficiente na Microsoft Azure.

Mais informações

Azure activity log - Azure Monitor | Microsoft Learn

Kusto Query Language (KQL) overview | Microsoft Learn

Creating an Azure Workbook - Azure Monitor | Microsoft Learn

Overview of Azure Monitor alerts - Azure Monitor | Microsoft Learn

Provisionando um Azure Kubernetes Services (AKS) com AGIC + SSL

fabiodasilva — Wed, 18 Oct 2023 22:06:37 GMT

Introdução

A implantação de aplicativos em contêineres tem se tornado uma prática cada vez mais comum no mundo da tecnologia, oferecendo flexibilidade, escalabilidade e agilidade no desenvolvimento e na operação de aplicações. O Azure Kubernetes Service (AKS) é uma das soluções mais populares para orquestração de contêineres, permitindo que as equipes de desenvolvimento gerenciem de maneira eficiente clusters de contêineres em larga escala.

Um dos principais desafios ao implantar aplicativos em contêineres é fornecer uma maneira confiável e segura para que os usuários externos acessem esses aplicativos. É aqui que o Azure Application Gateway Ingress Controller (AGIC) desempenha um papel fundamental. O AGIC atua como um controlador de ingresso, direcionando o tráfego externo para os serviços corretos dentro do cluster AKS, tornando mais fácil e seguro o acesso a aplicativos em contêineres.

Além disso, para garantir a segurança dos dados transmitidos pela aplicação, a utilização de SSL (Secure Socket Layer) ou TLS (Transport Layer Security) é essencial. Isso ajuda a proteger as informações confidenciais durante a comunicação entre o cliente e o servidor.

A combinação do AKS com o AGIC e a implementação de SSL oferecem uma solução poderosa para implantar aplicativos de forma segura e confiável. Os benefícios incluem:

Balanceamento de Carga Avançado: O Azure Application Gateway oferece recursos de balanceamento de carga avançados, permitindo distribuir o tráfego de entrada de maneira eficiente entre os pods do AKS.
Roteamento Baseado em Regras: Com o AGIC, é possível configurar regras de roteamento personalizadas para direcionar solicitações para serviços específicos com base em caminhos de URL ou cabeçalhos HTTP.
Gerenciamento Centralizado: O AGIC é totalmente integrado ao AKS, facilitando o gerenciamento centralizado do tráfego de entrada para todos os serviços no cluster.
Segurança e Criptografia: A configuração de SSL/TLS com certificados gerenciados do Azure assegura que as comunicações entre os usuários e a aplicação sejam protegidas e criptografadas.
Redução de Complexidade: A combinação do AKS com o AGIC simplifica a configuração de infraestrutura, permitindo que as equipes de desenvolvimento se concentrem no código da aplicação.

Em resumo, a implantação do Azure Kubernetes Service com o Azure Application Gateway Ingress Controller e a implementação de SSL oferecem uma solução robusta para a execução confiável e segura de aplicativos em contêineres. Essa abordagem garante alta disponibilidade, escalabilidade e proteção dos dados, permitindo que as empresas entreguem seus aplicativos com confiança e eficiência.

Arquitetura AKS com Ingress Controller (AGIC)

O cenário desta arquitetura envolve o uso do Azure Application Gateway Ingress Controller (AGIC) com o Azure Kubernetes Service (AKS) para gerenciar o tráfego externo e encaminhá-lo para os pods desejados no AKS. Vamos dividir o processo em etapas:

Criação do AKS com AGIC:
- O AKS é um serviço gerenciado de Kubernetes fornecido pelo Azure. Você criou um cluster AKS que é a base da sua aplicação.
- O AGIC é instalado como um addon do AKS. Ele fornece a integração do AKS com o Azure Application Gateway (App Gateway), que é um balanceador de carga avançado do Azure.
Configuração do Azure Application Gateway (App Gateway):
- O App Gateway é criado e configurado para trabalhar como um ponto de entrada para o tráfego externo. Ele age como um balanceador de carga e um controlador de ingresso.
- O App Gateway é configurado para aceitar tráfego HTTPS (porta 443) dos usuários externos.
Configuração do DNS:
- Um registro DNS é configurado para apontar o domínio personalizado (exemplo: www.seusite.com) para o endereço IP público do App Gateway.
Requisições dos Usuários Externos:
- Quando um usuário externo faz uma requisição HTTPS para o domínio personalizado (www.seusite.com), a solicitação é enviada para o endereço IP público do App Gateway.
Encaminhamento do Tráfego pelo AGIC:
- O AGIC intercepta a requisição no App Gateway e encaminha a solicitação para o AKS.
- O AGIC atua como um controlador de ingresso (Ingress Controller), observando os recursos Ingress definidos no AKS para determinar como encaminhar o tráfego para os serviços corretos no cluster.
Encaminhamento pelo AKS:
- O AKS recebe a requisição e verifica o recurso Ingress definido para o domínio (www.seusite.com).
- O Ingress mapeia o domínio para o serviço apropriado dentro do cluster AKS.
Encaminhamento para o Pod:
- O serviço dentro do AKS encaminha a requisição para um dos pods que implementa o serviço.
- O pod contém a aplicação web ou aplicação de back-end que responde à requisição do usuário.
Resposta para o Usuário:
- O pod processa a requisição e retorna uma resposta ao App Gateway.
- O App Gateway, por sua vez, retorna a resposta ao usuário externo que fez a solicitação inicial.

Todo esse processo acontece de forma transparente para o usuário externo. O AGIC e o AKS trabalham em conjunto para gerenciar o tráfego de entrada e encaminhá-lo para a aplicação correta. O uso do App Gateway e do AGIC oferece recursos avançados de balanceamento de carga, gerenciamento de tráfego e segurança para o seu AKS, permitindo que você gerencie eficientemente o tráfego de entrada e saída da sua aplicação.

Implantação do Laboratório

Passo 1: Declarar variaveis

Antes de começar, certifique-se de ter o Azure CLI instalado no Terminal Bash (ex: Azure Cloud Shell bash), o que permitirá que você gerencie recursos na nuvem por meio de comandos de linha de comando. Em seguida atualize e declare as variáveis que usaremos para a implementação do nosso ambiente:

# Informações da Assinatura tenantId="<coloque o iD do seu Tenant aqui>" subscriptionId="<coloque o id da sua subscription aqui>" regionName="westus" # Informações do usuário (pode ser obtido em Azure AD > Users > Seu usuario > User principal name) userPrincipalName="<Coloque o seu UserPrincipalName aqui>" # Nomes dos Grupos de Recursos rgDnsName="rg-h-wus-dns01" rgNetName="rg-h-wus-net01" rgJmpName="rg-h-wus-jmp01" rgAksName="rg-h-wus-aks01" # Pares de Tags tagPairs="foo=bar baz=qux" # Informações do Domínio Público do Azure App Service publicDomainName="aksagiclab.com" # Informações da Rede Virtual do AKS vNetName="vnet-h-wus-01" # Informações do Cluster AKS aksClusterName="aks-h-wus-01"

Passo 2: Autenticação usando Azure CLI

Em seguida, autentique-se com sua conta do Azure usando o seguinte comando:

az login --tenant $tenantId az account set --subscription $subscriptionId

Passo 3: Criação dos Grupos de Recursos

Os grupos de recursos são contêineres lógicos que agrupam recursos relacionados. Execute os comandos abaixo para criar os grupos de recursos:

az group create --name $rgDnsName --location $regionName --tags $tagPairs az group create --name $rgNetName --location $regionName --tags $tagPairs az group create --name $rgAksName --location $regionName --tags $tagPairs

Passo 4: Implantação da Rede Virtual

Agora, criaremos a rede virtual (VNet) para o nosso ambiente AKS:

az network vnet create --name $vNetName --resource-group $rgNetName --address-prefixes "10.251.0.0/16" --location $regionName --subnet-name "snet-vnet-h-wus-aks-01" --subnet-prefixes "10.251.10.0/23" --tags $tagPairs az network vnet subnet create --name "snet-vnet-h-wus-agic-01" --resource-group $rgNetName --vnet-name $vNetName --address-prefix "10.251.20.0/24"

Passo 5: Implantação do Azure App Service Domain

O Azure App Service Domain permite que você gerencie domínios personalizados para os serviços do Azure. Vamos criar um domínio para o Application Gateway:

# Generate tree random characters randomCharcters=$(generate_random_char() { chars="abcdefghijklmnopqrstuvwxyz0123456789"; echo -n "${chars:$((RANDOM % ${#chars})):1}"; }; generate_random_string() { random_string=""; for ((i = 0; i < 3; i++)); do random_string+=`generate_random_char`; done; echo "$random_string"; }; random_string=$(generate_random_string); echo $random_string) # Download the contact_info form wget https://raw.githubusercontent.com/AzureAppServiceCLI/appservice_domains_templates/master/contact_info.json # Edit and update the contact_info form vi ./contact_info.json # Deploy Azure App Service Domain az appservice domain create --resource-group $rgDnsName --hostname "$randomCharcters$publicDomainName" --contact-info=@'./contact_info.json' --accept-terms --privacy --tags $tagPairs

Passo 6: Implantação do Azure Application Gateway

Agora, implantaremos o Application Gateway para fornecer um balanceador de carga para o AKS:

agicSubnetId=$(az network vnet subnet list --resource-group $rgNetName --vnet-name $vNetName --query "[?name=='snet-vnet-h-wus-agic-01'].id" --output tsv) az network application-gateway create --name "appgw-$aksClusterName" --resource-group $rgAksName --capacity 1 --frontend-port 80 --http-settings-cookie-based-affinity "Disabled" --http-settings-port 80 --http-settings-protocol "Http" --location $regionName --max-capacity 2 --min-capacity 1 --priority 100 --private-ip-address "10.251.20.10" --public-ip-address "appgw-$aksClusterName-pip" --sku "Standard_v2" --subnet $agicSubnetId --tags $tagPairs

Passo 7: Registro dos Nomes DNS

Agora, registraremos os nomes DNS para que nosso ambiente AKS seja acessível:

agicPubIp=$(az network public-ip show --resource-group $rgAksName --name "appgw-$aksClusterName-pip" --query "ipAddress" --output tsv) az network dns record-set a add-record --resource-group $rgDnsName --zone-name "$randomCharcters$publicDomainName" --record-set-name "app01" --ipv4-address $agicPubIp --ttl 300 az network dns record-set a add-record --resource-group $rgDnsName --zone-name "$randomCharcters$publicDomainName" --record-set-name "app02" --ipv4-address $agicPubIp --ttl 300 az network dns record-set a add-record --resource-group $rgDnsName --zone-name "$randomCharcters$publicDomainName" --record-set-name "app03" --ipv4-address $agicPubIp --ttl 300

Passo 8: Implantação do AKS Cluster

Agora é o momento de implantar o nosso Cluster AKS e atribuir as permissões de acesso:

aksSubnetId=$(az network vnet subnet list --resource-group $rgNetName --vnet-name $vNetName --query "[?name=='snet-vnet-h-wus-aks-01'].id" --output tsv) az aks create --name $aksClusterName --resource-group $rgAksName --auto-upgrade-channel "node-image" --disable-local-accounts --dns-name-prefix $aksClusterName --dns-service-ip "10.252.0.10" --enable-aad --enable-addons "azure-keyvault-secrets-provider" --enable-azure-rbac --enable-blob-driver --enable-cluster-autoscaler --enable-managed-identity --generate-ssh-keys --kubernetes-version "1.25.6" --load-balancer-sku "standard" --location $regionName --max-count 2 --max-pods 50 --min-count 1 --network-dataplane "azure" --network-plugin "azure" --network-policy "azure" --node-count 1 --node-osdisk-size 63 --node-vm-size "Standard_D2as_v4" --nodepool-labels "pooltype=system" --nodepool-name "syspool1" --service-cidr "10.252.0.0/16" --tags $tagPairs --tier "free" --vnet-subnet-id $aksSubnetId --yes az aks nodepool add --cluster-name $aksClusterName --name "usrpool1" --resource-group $rgAksName --enable-cluster-autoscaler --kubernetes-version "1.25.6" --labels "pooltype=user" --max-count 2 --max-pods 50 --min-count 1 --mode "User" --node-count 1 --node-osdisk-size 63 --node-vm-size "Standard_D2as_v4" --tags $tagPairs --vnet-subnet-id $aksSubnetId

Passo 9: Validar os recursos criados

Grupo de Recursos:

Cluster Azure Kubernetes Services (AKS):

App Domain e registros DNS:

Importante:

Perceba que temos alguns registros DNS para os seguintes FQDNs apontando para o IP Público do Application Gateway, o qual iremos integrar com nosso Cluster AKS como Ingress Controller (AGIC):

Atribuindo Permissões AKS RBAC

Para gerenciar o cluster AKS, é necessário atribuir permissões adequadas ao usuário principal. Execute os comandos abaixo para atribuir a função "Azure Kubernetes Service RBAC Cluster Admin" ao usuário:

userId=$(az ad user show --id $userPrincipalName --query "id" --output tsv) rgId=$(az group show --name $rgAksName --query "id" --output tsv) az role assignment create --assignee $userId --role "Azure Kubernetes Service RBAC Cluster Admin" --scope $rgId

Visualizando o resultado da atribuição ao usuário ao AKS pelo portal:

Integração AKS com Application Gateway

Agora, vamos integrar o AKS com o Application Gateway para redirecionar o tráfego externo para o cluster AKS:

agicResId=$(az network application-gateway show --name "appgw-$aksClusterName" --resource-group $rgAksName --query "id" --output tsv) az aks enable-addons --name $aksClusterName --resource-group $rgAksName --addon "ingress-appgw" --appgw-id $agicResId # Get application gateway id from AKS addon profile appGatewayId=$(az aks show --name $aksClusterName --resource-group $rgAksName -o tsv --query "addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId") # Get Application Gateway subnet id appGatewaySubnetId=$(az network application-gateway show --ids $appGatewayId -o tsv --query "gatewayIPConfigurations[0].subnet.id") # Get AGIC addon identity agicAddonIdentity=$(az aks show --name $aksClusterName --resource-group $rgAksName -o tsv --query "addonProfiles.ingressApplicationGateway.identity.clientId") # Assign network contributor role to AGIC addon identity to subnet that contains the Application Gateway az role assignment create --assignee $agicAddonIdentity --scope $appGatewaySubnetId --role "Network Contributor"

Revisão das Permissões do AKS Managed Identity (ingressapplicationgateway-cluster-name) para o Application Gateway

Certifique-se de que a Identidade Gerenciada do AKS tenha as permissões adequadas para o Application Gateway:

Grupo de Recursos do AKS - Função de Leitura (Reader)
Grupo de Recursos do AKS/Nodes MC (AKS Managed Clusters) - Função de Contribuinte (Contributor)
Recurso/Grupo de Recursos do Application Gateway - Função de Contribuinte (Contributor)
Sub-rede do Application Gateway - Função de Contribuinte de Rede (Network Contributor)

A identidade gerenciada “ingressapplicationgateway-cluster-name” foi criada automaticamente durante a integração entre o Application Gateway e o cluster AKS:

Implantação e Exposição de Aplicativos

Antes de prosseguir com a implantação dos aplicativos, certifique-se de ter o utilitário "kubectl" instalado. Se ainda não o tiver, você pode instalá-lo executando o seguinte comando:

az aks install-cli

Em seguida, faça o download das credenciais do cluster AKS para autenticação e a conversão para kubelogin:

az aks get-credentials --resource-group $rgAksName --name $aksClusterName kubelogin convert-kubeconfig -l azurecli

AGIC Sample App with Public IP

O AKS está configurado com uma integração completa com o Application Gateway, permitindo o roteamento de tráfego externo para aplicativos implantados no cluster. Você pode usar o utilitário "kubectl" para implantar os aplicativos no cluster e expô-los para acesso externo.

Vamos supor que você tenha um aplicativo ASP.NET Core para implantar. Crie um arquivo de manifesto para o aplicativo e, em seguida, faça a implantação:

vi AgicSampleApp-PUB.yml

apiVersion: v1 kind: Namespace metadata: name: aspnetapp01 labels: name: aspnetapp01 --- apiVersion: apps/v1 kind: Deployment metadata: name: aspnetapp01 namespace: aspnetapp01 labels: app: aspnetapp01 spec: replicas: 3 selector: matchLabels: app: aspnetapp01 template: metadata: labels: app: aspnetapp01 spec: nodeSelector: kubernetes.azure.com/mode: user containers: - name: aspnetapp-image image: "mcr.microsoft.com/dotnet/samples:aspnetapp" ports: - containerPort: 8080 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: aspnetapp01 namespace: aspnetapp01 spec: selector: app: aspnetapp01 ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: aspnetapp01 namespace: aspnetapp01 annotations: kubernetes.io/ingress.class: azure/application-gateway appgw.ingress.kubernetes.io/backend-path-prefix: "/" appgw.ingress.kubernetes.io/ssl-redirect: "false" appgw.ingress.kubernetes.io/connection-draining: "true" appgw.ingress.kubernetes.io/connection-draining-timeout: "60" appgw.ingress.kubernetes.io/cookie-based-affinity: "false" appgw.ingress.kubernetes.io/request-timeout: "30" appgw.ingress.kubernetes.io/use-private-ip: "false" appgw.ingress.kubernetes.io/backend-protocol: "http" spec: rules: - http: paths: - path: / backend: service: name: aspnetapp01 port: number: 80 pathType: Prefix

Salve o conteúdo acima em um arquivo chamado AgicSampleApp-PUB.yml. Em seguida, implante o aplicativo com o seguinte comando:

kubectl apply -f AgicSampleApp-PUB.yml

Verifique o ingress criado através do comando abaixo:

kubectl get ingress aspnetapp01 -n aspnetapp01 NAME CLASS HOSTS ADDRESS PORTS AGE aspnetapp01 <none> * 13.83.132.111 80 101s

Perceba que o ingress recebeu o IP “13.83.132.111” que é o IP Público do nosso Application Gateway como Ingress Controller do nosso cluster. Ao acessar no browser esse endereço IP batemos no Application Gateway/AGIC e ele o redirecionará para a aplicação no AKS.

Agora para a próxima implementação iremos realizar a implantação de uma aplicação com nome de host e certificado SSL com Ingress.

AGIC Sample App with Public IP + Host + Cert (issued by Cert-Manager with Let's Encrypt)

Agora vamos prosseguir com a implantação de um aplicativo no AKS usando o IP público no Application Gateway e um certificado gerenciado pelo Cert Manager.

Cert Manager

Primeiro, vamos implantar o Cert Manager para gerenciar os certificados TLS automaticamente. Cert Manager é uma ferramenta para automatizar a emissão e renovação de certificados TLS. Ele usa a Autoridade de Certificação ACME (Automatic Certificate Management Environment) para emissão e renovação de certificados Let's Encrypt:

# Install the CustomResourceDefinition resources separately kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.3/cert-manager.crds.yaml # Create the namespace for cert-manager kubectl create namespace cert-manager # Label the cert-manager namespace to disable resource validation kubectl label namespace cert-manager cert-manager.io/disable-validation=true # Add the Jetstack Helm repository helm repo add --force-update jetstack https://charts.jetstack.io # Update your local Helm chart repository cache helm repo update # Install the cert-manager Helm chart # Helm v3+ helm --install cert-manager jetstack/cert-manager --namespace cert-manager --version v1.12.3 --set extraArgs='{--logging-format=json}' --set webhook.extraArgs='{--logging-format=json}' --set cainjector.extraArgs='{--logging-format=json}'

Deploy Cluster Issuer Resource

Agora, vamos criar um objeto Cluster Issuer que nos permitirá emitir certificados automaticamente para o Application Gateway:

vi ClusterIssuer.yml

apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: # You must replace this email address with your own. # Let's Encrypt uses this to contact you about expiring # certificates, and issues related to your account. email: your.email@address.com # ACME server URL for Let’s Encrypt’s Prod environment. server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: # Secret resource used to store the account's private key. name: letsencrypt-secret # Enable the HTTP-01 challenge provider # you prove ownership of a domain by ensuring that a particular # file is present at the domain solvers: - http01: ingress: class: azure/application-gateway

kubectl apply -f ClusterIssuer.yml

Crie o arquivo de manifesto para implantação da aplicação com SSL

Agora, vamos criar um arquivo de manifesto para implantar nosso aplicativo no AKS usando um IP privado no Application Gateway e um certificado gerenciado pelo Cert Manager.

Crie o arquivo AgicSampleApp-PUB-Host-Cert-LE.yml e adicione o seguinte conteúdo:

apiVersion: v1 kind: Namespace metadata: name: aspnetapp03 labels: name: aspnetapp03 --- apiVersion: apps/v1 kind: Deployment metadata: name: aspnetapp03 namespace: aspnetapp03 labels: app: aspnetapp03 spec: replicas: 3 selector: matchLabels: app: aspnetapp03 template: metadata: labels: app: aspnetapp03 spec: nodeSelector: kubernetes.azure.com/mode: user containers: - name: aspnetapp-image image: "mcr.microsoft.com/dotnet/samples:aspnetapp" ports: - containerPort: 8080 protocol: TCP --- apiVersion: v1 kind: Service metadata: name: aspnetapp03 namespace: aspnetapp03 spec: selector: app: aspnetapp03 ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: aspnetapp03 namespace: aspnetapp03 annotations: kubernetes.io/ingress.class: azure/application-gateway cert-manager.io/cluster-issuer: letsencrypt-prod cert-manager.io/acme-challenge-type: http01 appgw.ingress.kubernetes.io/use-private-ip: "false" appgw.ingress.kubernetes.io/ssl-redirect: "true" appgw.ingress.kubernetes.io/connection-draining: "true" appgw.ingress.kubernetes.io/connection-draining-timeout: "60" appgw.ingress.kubernetes.io/cookie-based-affinity: "false" appgw.ingress.kubernetes.io/request-timeout: "30" spec: tls: - hosts: - app03.aksagiclab.com # update domain same as "$randomCharcters$publicDomainName" secretName: app03.aksagiclab.com-secret # update domain same as "$randomCharcters$publicDomainName" rules: - host: app03.aksagiclab.com # update domain same as "$randomCharcters$publicDomainName" http: paths: - path: / backend: service: name: aspnetapp03 port: number: 80 pathType: Prefix

Realize a implantação do manifesto através do comando abaixo:

kubectl apply -f AgicSampleApp-PUB-Host-Cert-LE.yml namespace/aspnetapp03 created deployment.apps/aspnetapp03 created service/aspnetapp03 created ingress.networking.k8s.io/aspnetapp03 created

Visualize o ingress no namespace aspnetapp03 através do comando abaixo:

kubectl get ingress -n aspnetapp03 NAME CLASS HOSTS ADDRESS PORTS AGE aspnetapp03 <none> app03.aksagiclab.com 13.83.132.111 80, 443 76

Acessando a aplicação pelo host "app03.aksagiclab.com" usando SSL:

Conclusão

Neste guia, você aprendeu como implantar um cluster Azure Kubernetes Service (AKS) com integração Azure Active Directory (AAD) e Application Gateway. Com esses recursos habilitados, você pode fornecer uma experiência segura e confiável para seus aplicativos em contêineres, permitindo um gerenciamento mais eficiente, escalabilidade elástica e uma resposta rápida a eventos críticos.

Agora que seu ambiente AKS está configurado e funcionando corretamente, você pode continuar explorando e implantando seus próprios aplicativos em contêineres para aproveitar ao máximo a infraestrutura de nuvem altamente disponível e resiliente que o Microsoft Azure oferece.

Mais informações

Engenharia de Confiabilidade no Microsoft Azure (Realiability)

fabiodasilva — Tue, 01 Aug 2023 13:58:16 GMT

Confiabilidade na Arquitetura em Nuvem

O pilar de confiabilidade do Well-Architected Framework concentra-se na capacidade do sistema de se recuperar automaticamente de falhas e gerenciar mudanças de forma segura e eficiente. Isso envolve a implementação de práticas e padrões para garantir que os sistemas sejam altamente disponíveis, resilientes e confiáveis.

Introdução

A confiabilidade é um aspecto crítico da arquitetura em nuvem que garante que aplicativos e sistemas operem perfeitamente, mesmo diante de falhas ou desafios imprevistos. No ambiente em nuvem, onde os recursos são dinâmicos e distribuídos, projetar para confiabilidade se torna fundamental para atender às demandas das aplicações modernas.

O Framework de Boas Práticas da Microsoft para Arquitetura (Well-Architected Framework) fornece um guia abrangente para construir soluções em nuvem robustas, confiáveis e resilientes. Dentro desse framework, o pilar de Confiabilidade concentra-se em permitir que aplicativos se recuperem automaticamente de falhas e se adaptem a mudanças, mantendo alta disponibilidade e desempenho.

Segue um breve resumo das áreas de domínio de confiabilidade (reliability) do Well-Architected Framework da Microsoft com os links da documentação relevante.

Fundamentos de Confiabilidade:

Descrição: Compreenda os princípios e as práticas fundamentais para construir sistemas confiáveis e resilientes.
Documentação: Fundamentos de Confiabilidade no Azure Well-Architected Framework

Recuperação de Falhas:

Descrição: Aprenda como projetar sistemas que possam se recuperar automaticamente de falhas para minimizar o impacto dos incidentes.
Documentação: Recuperação de Falhas no Azure Well-Architected Framework

Arquitetura Multi-Região e Recuperação de Desastres:

Descrição: Explore como criar arquiteturas distribuídas em várias regiões para garantir a disponibilidade contínua e a recuperação de desastres.
Documentação: Arquitetura Multi-Região e Recuperação de Desastres no Azure Well-Architected Framework

Monitoramento e Diagnóstico:

Descrição: Saiba como configurar monitoramento e diagnóstico eficientes para identificar problemas e tomar ações corretivas.
Documentação: Monitoramento e Diagnóstico no Azure Well-Architected Framework

Gestão de Capacidade:

Descrição: Entenda como dimensionar e gerenciar a capacidade de recursos para atender às demandas do sistema sem comprometer a performance.
Documentação: Gestão de Capacidade no Azure Well-Architected Framework

Essas áreas de domínio são essenciais para garantir que seus sistemas sejam altamente disponíveis, confiáveis e resilientes na nuvem do Microsoft Azure. Ao seguir as práticas recomendadas e utilizar as ferramentas fornecidas, você pode projetar e implementar soluções robustas e de alto desempenho.

Boas Práticas para a Confiabilidade

Design do Aplicativo: Comece criando uma arquitetura de aplicativo bem projetada, considerando princípios como modularidade, isolamento de falhas e degradação graciosa. Realize análise de modos de falha para antecipar pontos potenciais de falha e desenvolver estratégias para lidar com eles de forma eficaz.
- Design: Crie arquiteturas de aplicativos bem planejadas, considerando os princípios de design, para garantir que sejam altamente disponíveis e confiáveis. Design for reliability
- Failure Mode Analysis: Identifique possíveis pontos de falha e desenvolva estratégias para mitigar e lidar com falhas no sistema. Failure mode analysis
- Targets & Non-Functional Requirements: Estabeleça metas claras de desempenho e requisitos não funcionais para medir a confiabilidade do aplicativo e garantir que ele atenda aos padrões esperados. Targets and non-functional requirements

Modelagem e Monitoramento da Saúde: Devemos implementar o monitoramento abrangente nos níveis de aplicativo, recursos e infraestrutura. Colete métricas relevantes e configure mecanismos de alerta para detectar e responder a problemas de forma proativa.
- Application-Level Monitoring: Implemente monitoramento em nível de aplicativo para coletar métricas importantes e detectar problemas de desempenho ou confiabilidade. Application-level monitoring
- Resource and Infrastructure Level Monitoring: Monitore recursos e infraestrutura subjacentes para entender o impacto no desempenho e na disponibilidade do aplicativo. Resource and infrastructure monitoring
- Monitoring and Measurement: Defina métricas significativas e estabeleça acordos de nível de serviço (SLAs) para medir a saúde do aplicativo. Monitoring and measurement
- Dependencies: Identifique dependências externas e monitore seu comportamento para evitar problemas relacionados a interações externas. Dependencies
- Data Interpretation & Health Modelling: Analise os dados coletados para entender tendências, prever problemas e melhorar a confiabilidade geral. Data interpretation and health modeling
- Alerting: Estabeleça alertas e notificações para a equipe de operações reagir proativamente a eventos críticos. Alerting
Planejamento de Capacidade e Disponibilidade do Serviço: Planejar a escalabilidade e capacidade para lidar com a demanda esperada e os picos de tráfego. Garanta alta disponibilidade do serviço para minimizar o tempo de inatividade não planejado.
- Scalability & Capacity Model: Planeje a capacidade de recursos para acomodar a demanda esperada e os picos de tráfego. Scalability and capacity model
- Service Availability: Garanta alta disponibilidade dos serviços, minimizando o tempo de inatividade não planejado. Service availability
Disponibilidade da Plataforma de Dados: Escolher a camada de serviço apropriada e implementar replicação e redundância de dados para manter a consistência dos dados e garantir disponibilidade contínua é essencial em uma arquitetura para garantir a disponibilidade e resiliência da aplicação
- Service SKU: Escolha a camada de serviço apropriada para garantir o nível adequado de disponibilidade. Service SKU
- Consistency: Mantenha a consistência dos dados para garantir a integridade das operações e a confiabilidade geral. Mantendo a consistência dos dados no contexto de computação em nuvem e sistemas distribuídos é uma preocupação crítica para garantir a integridade das operações e a confiabilidade geral do ambiente. A consistência se refere à ideia de que os dados em um sistema distribuído estão sempre em um estado válido e coerente, independentemente do número de réplicas ou de como os dados são acessados. Consistency Level CosmosDB, Consistency Level EventHub
- Replication and Redundancy: Implemente replicação e redundância de dados para mitigar riscos de perda de dados e garantir a disponibilidade contínua. Replication and redundancy
Modelo Operacional e DevOps: Estabelecer procedimentos operacionais eficientes é fundamental para garantir que sua equipe possa responder rapidamente a eventos críticos e gerenciar incidentes de forma eficaz. Esses procedimentos são essenciais para manter a disponibilidade, segurança e integridade dos sistemas e serviços em nuvem. Defina claramente os papéis e responsabilidades dentro da equipe. Estabeleça procedimentos operacionais para o gerenciamento de incidentes e resposta rápida a eventos críticos.
- Roles & Responsibilities: Defina claramente os papéis e responsabilidades da equipe para garantir a eficiência operacional e a colaboração adequada. Roles and responsibilities
- Operational Procedures: Estabeleça procedimentos operacionais para garantir uma resposta rápida a eventos críticos e gerenciamento eficiente de incidentes. Operational procedures
Rede e Conectividade: Assegure uma conectividade confiável entre os componentes do aplicativo e serviços externos. Assegurar uma conectividade confiável entre os componentes do aplicativo e serviços externos é crucial para garantir o desempenho, a disponibilidade e a escalabilidade do sistema na nuvem. Além disso, o uso de serviços cientes de zona é uma prática importante para aumentar a tolerância a falhas e a resiliência do aplicativo.
- Connectivity: Garanta conectividade confiável entre os componentes do aplicativo e serviços externos. Connectivity
- Zone-Aware Services: Projete serviços para serem cientes da zona e tolerantes a falhas de zonas. Availabilit Service by Category
Gestão de Desempenho do Aplicativo: Gerencie o tamanho dos dados e seu crescimento, otimize o throughput da rede e projete aplicativos para escalar elasticamente com base na demanda.
- Service SKU: Escolha a camada de serviço apropriada para garantir a disponibilidade e o desempenho desejados. Service SKU
- Compute Availability: Garanta a disponibilidade dos recursos de computação para evitar falhas devido a escassez de recursos. Compute availability
Segurança e Conformidade: Utilize o Controle de Acesso Baseado em Função (RBAC) para garantir acesso autorizado aos recursos e manter um ambiente seguro.
- Control-plane RBAC: Utilize o controle de acesso baseado em função (RBAC) para garantir que as operações sejam executadas apenas por usuários autorizados. Control-plane RBAC
Procedimentos operacionais: Procedimentos operacionais bem definidos desempenham um papel fundamental na manutenção de operações confiáveis e na resposta rápida a eventos críticos. A adoção desses procedimentos operacionais no Microsoft Azure ajudará a garantir a confiabilidade do seu aplicativo ou serviço, minimizando o tempo de inatividade não planejado, melhorando a resiliência e proporcionando uma experiência positiva para os usuários finais. Lembre-se de revisar e atualizar regularmente esses procedimentos para atender às necessidades em constante evolução do seu ambiente na nuvem Azure.
- Recovery & Failover: Crie planos de recuperação e failover para garantir a disponibilidade contínua em caso de falhas ou desastres. Recovery and failover
- Configuration & Secrets Management: Gerencie as configurações e segredos do aplicativo de maneira segura para evitar riscos de segurança. Configuration and secrets management
Application Performance Management
- Data Size/Growth: Gerencie o tamanho dos dados e o crescimento para evitar gargalos de desempenho. Data size/growth
- Network Throughput and Latency: Otimize o throughput de rede e reduza a latência para melhorar o desempenho do aplicativo. Network throughput and latency
- Elasticity: Programe o aplicativo para escalar automaticamente com base na demanda para garantir desempenho adequado. Elasticity
Desenvolvimento e Testes: Implemente práticas seguras de implantação, crie ambientes de compilação padronizados e conduza testes e validações abrangentes.
- Application Code Deployments: Implemente práticas de implantação seguras e automatizadas para garantir a confiabilidade das implantações. Application code deployments
- Build Environments: Crie ambientes de compilação padronizados e consistentes para melhorar a qualidade do código. Build environments
- Testing & Validation: Realize testes e validações para garantir que o aplicativo atenda aos requisitos de confiabilidade e desempenho. Testing and validation

Resumo

A confiabilidade é um pilar fundamental na construção de soluções em nuvem bem-sucedidas. Ao seguir as boas práticas delineadas no Framework de Boas Práticas da Microsoft para Arquitetura, você pode projetar, implantar e gerenciar aplicativos altamente disponíveis, resilientes e capazes de se recuperar de falhas com elegância.

Destacando um design de aplicativo robusto, implementando um monitoramento efetivo e planejando a capacidade e disponibilidade da plataforma de dados, você dará passos cruciais para garantir uma arquitetura em nuvem confiável. Aliado a procedimentos operacionais sólidos, práticas eficientes de DevOps e aderência aos padrões de segurança, seus aplicativos baseados em nuvem estarão preparados para enfrentar desafios, entregar desempenho consistente e proporcionar uma experiência de usuário perfeita.

Incorporar esses princípios de confiabilidade em sua arquitetura em nuvem elevará não apenas o desempenho de seus aplicativos, mas também contribuirá para construir uma base sólida para o sucesso no ambiente dinâmico e em constante evolução da nuvem.

Adicionar sub-rede para um nodePool do AKS usando plugin Azure CNI

fabiodasilva — Fri, 14 Jul 2023 13:55:33 GMT

O Plugin de rede CNI usado nos ambientes produtivos requer um bom planejamento para os clusters do Azure Kubernetes Services (AKS) para evitar que a exaustão de endereços IP fornecidos pela sub-rede do cluster devido ao crescimento do ambiente, tendo a necessidade de recriar o cluster para atender a essa demanda.

Este artigo irá passar sobre este cenário que encontramos em muitos ambientes produtivos, com a possibilidade de adicionar um novo bloco de endereçamento IP da rede virtual do AKS e dedicá-la para um conjunto de nodepool.

Introdução

Um aspecto importante na arquitetura de um cluster do Azure Kubernetes Services (AKS) é relacionado ao seu planejamento de conectividade de rede e segurança. Dentro deste planejamento a escolha do modelo de rede entre CNI ou Kubelet é um fator essencial para a administração do cluster.

Uma breve explicação entre os dois modos de rede no AKS:

Azure CNI

Plugin indicado para ambientes produtivos, requer um planejamento adequado, pois requer uma rede virtual e sub-rede para alocações dos nodes e pods do cluster AKS.

Pontos importantes sobre a CNI:

Cada node e pod recebe um endereço IP na rede virtual do Azure, sem necessidade de roteamento extra para se comunicar com outros serviços ou recursos.
A sub-rede deve ser grande o suficiente para fornecer endereços IP para cada node, pods e garantir nodes adicionais para escala e upgrade do cluster.
Cada node tem um parâmetro de configuração para o número máximo de pods aos quais ele dá suporte, portanto a quantidade de endereçamento IP é reservada antecipadamente na sub-rede para uso no cluster.

Importante!

O uso do plugin CNI Azure requer planejamento para não levar à exaustão de endereço IP ou à necessidade de recriar o cluster para uma nova sub-rede.

Azure Kubelet

Opção de rede usando kubelet é considerada modelo básico padrão para clusters do AKS

Pontos importantes:

Os Nodes recebem endereçamento IP da sub-rede virtual do Azure.
Os Pods recebem endereçamento IP de outro bloco de endereço diferente da rede virtual.
Tráfego entre Pods e Nodes usando roteamento extra através de UDR pode reduzir o desempenho da rede.
NAT é configurado para que os Pods possam alcançar recursos na rede virtual.
Conexões com as redes locais existentes ou entre peering com outras redes virtuais podem ser tornar complexas.

Quando considerar o uso do plugin kubelet:

Workloads pequenos, ambientes de teste ou desenvolvimento.
Sites simples com baixo tráfego.

Cenário

Temos um cluster AKS com dois nodepool sendo um de system e outro de user conforme a ilustração abaixo.

Para saber mais sobre a diferença entre node system e user system recomendo a leitura da documentação Use system node pools in Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

O cluster está alocado em uma rede virtual com o bloco de endereço 10.200.0.0/23 e uma única sub-rede no qual está ocupando todo o endereçamento IP.

Adicionar um novo nodepool para uma sub-rede dedicada

Uma aplicação dentro do AKS pode exigir que os nodes de um cluster sejam divididos em nodepools separados para isolamento lógico. Essa separação também pode se beneficiar com o suporte de sub-redes dedicadas a cada nodepool o que também atende a necessidade de maior alocação de endereço IP usando CNI.

Primeira Etapa:

Adicionar novo bloco de endereço IP na rede virtual e criar a sub-rede correspondente.

Segunda etapa:

Iremos usar a CLI para adição do novo nodepool na sub-rede SNT-AKS-2

Importante!

Valide a versão do AZ CLI está na versão 2.35.0 ou acima

Encontrar o ID da Subnet

# az network vnet subnet show -g AKS-PRD-BR -n SNT-AKS-2 --vnet-name VNET-AKS-PRD-BR { "addressPrefix": "10.100.0.0/24", "addressPrefixes": null, "applicationGatewayIpConfigurations": null, "delegations": [], "etag": "W/\"6c3026f7-0a21-4fd6-af97-d9eb41c1ef3b\"", "id": "/subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/AKS-PRD-BR/providers/Microsoft.Network/virtualNetworks/VNET-AKS-PRD-BR/subnets/SNT-AKS-2", "ipAllocations": null, "ipConfigurationProfiles": null, "ipConfigurations": null,

A saída do comando copie a linha correspondente ao seu SubnetID

Verificar os nodes do cluster

# kubectl get node -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP aks-agentpool-41582112-vmss000000 Ready agent 45m v1.24.9 10.200.0.53 aks-prdnode01-41582112-vmss000000 Ready agent 45m v1.24.9 10.200.0.4

Na saída do comando visualizamos os nodes "agentpool" e "prdnode01" recebendo endereçamento IP do bloco 10.200.0.0/23

Adicionar nodepool prdnode02 na sub-rede SNT-AKS-2

Como adicionados um novo bloco de endereço IP na rede virtual devemos atualizar o cluster com o comando "az aks update -g <resourceGroup> -n <clusterName>" sem argumentos opcionais. Esse comando executará uma operação de atualização sem fazer nenhuma alteração.

Para mais informações veja a documentação Use multiple node pools in Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

az aks update -g AKS-PRD-BR -n aks-prd-br-01

Após execução do comando az aks update, execute o bloco de comandos abaixo para adicionar o novo nodepool na sub-rede dedicada.

az aks nodepool add \ --resource-group AKS-PRD-BR \ --cluster-name aks-prd-br-01 \ --name prdnode02 \ --node-count 2 \ --vnet-subnet-id /subscriptions/xxxxxxxxxxxxxxxxxxxxxxxxxxxx/resourceGroups/AKS-PRD-BR/providers/Microsoft.Network/virtualNetworks/VNET-AKS-PRD-BR/subnets/SNT-AKS-2

Após a execução do comando podemos visualizar novamente os nodes do cluster AKS.

kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP aks-agentpool-41582112-vmss000000 Ready agent 83m v1.24.9 10.200.0.53 aks-prdnode01-41582112-vmss000000 Ready agent 83m v1.24.9 10.200.0.4 aks-prdnode02-14816076-vmss000000 Ready agent 3m31s v1.24.9 10.100.0.4 aks-prdnode02-14816076-vmss000001 Ready agent 3m34s v1.24.9 10.100.0.33

Adicionados um novo nodepool "prdnode02" com duas instancias e visualizamos que estes novos nodes recebem endereço IP da sub-rede dedicada 10.100.0.0/24.

Verificando as informações pelo portal.

Tela do Azure mostrando o novo nodepool criado.

Tela do Azure com as propriedades do novo nodepool, visualizamos em qual sub-rede os nodes estão associados.

Conclusão

Neste artigo vimos como podemos adicionar um novo nodepool de um cluster do AKS em uma sub-rede dedicada em cenários nos quais os clientes precisam isolamento lógico dos nodes em sub-redes separadas ou resolver problemas de exaustão de endereçamento IP sem a necessidade de recriar o cluster.

Atualização do diagrama com a adição do novo nodepool em uma subre-rede dedicada.

Referências

Use multiple node pools in Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

Concepts - Networking in Azure Kubernetes Services (AKS) - Azure Kubernetes Service | Microsoft Learn

Configure Azure CNI networking in Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

Best practices for network resources in Azure Kubernetes Service (AKS) - Azure Kubernetes Service | Microsoft Learn

Inspeção do tráfego destinado aos Private Endpoints para o Azure Firewall ou NVA

fabiodasilva — Tue, 13 Jun 2023 17:37:57 GMT

Este artigo possui a finalidade de demonstrar como podemos inspecionar o tráfego com destino aos recursos de Private Endpoint para o Azure Firewall ou NVA.

O que é private Endpoint?

Um private Endpoint fornece um endereço IP privado para uma lista de serviços de plataforma na Azure permitindo a comunicação privada com estes recursos.

Como usar uma solução de firewall para inspecionar o tráfego destinado a um private endpoint?

Um requisito de segurança talvez seja inspecionar ou bloquear o tráfego de clientes para os serviços expostos de forma privada por meio do private Endpoint. Porém para atingir esse objetivo devemos conhecer algumas características referente ao uso do private Endpoint.

As seguintes características se aplicam ao uso do private endpoint:

O tráfego dos grupos de segurança de rede (NSG) é ignorado nos private endpoints
O tráfego das rotas definidas pelo usuário (UDR) é ignorado nos private endpoints. As rotas definidas pelo usuário podem ser usadas para substituir o tráfego destinado ao private Endpoint.
Uma única tabela de rotas pode ser anexada a uma sub-rede
Uma tabela de rotas dá suporte a até 400 rotas

Ao criar um private Endpoint com o serviço do private link é injetado nas sub-redes uma rota mais especifica /32 contendo o endereçamento ip privado destinado ao private Endpoint, devido a este cenário temos alguns cenários de como inspecionar o tráfego destinado ao private Endpoint para uma solução do Azure Firewall ou NVA (Network Virtual Applicance)

A seguinte documentação Use Azure Firewall to inspect traffic destined to a private endpoint - Azure Private Link | Microsoft Learn relata 4 cenários possíveis para inspeção do private endpoint, porém irei cobrir aqui um novo cenário usando o recurso de Network Policy no qual irá facilitar o nosso objetivo.

A documentação relata quatro opções possíveis para realizar a inspeção do private endpoint para o Azure Firewall.

Cenário 1: Arquitetura Hub e Spoke usando uma rede virtual dedicada para private endpoint.

Neste cenário de arquitetura Hub e Spoke usamos uma rede virtual inteira para o private endpoint.

Hub Vnet: 10.0.0.0/16
Spoke VNET: 10.1.0.0/16
Private vNET: 10.2.0.0/16

Neste cenário é criado uma Route Table da sub-rede da rede virtual Spoke VNET com a seguinte regra para alcançar a rede 10.20.0./16 passando pelo Azure Firewall. Essa configuração reduz a sobrecarga administrativa e impedindo a possibilidade de alcançar o limite de 400 rotas da UDR

Este cenário se aplica nos clientes que possuem uma rede virtual dedicada para o serviço do private endpoint.

Cenário 2: Arquitetura Hub e Spoke usando rede virtual compartilhada entre as máquinas virtuais e private endpoint

Este cenário cobre grande parte das arquiteturas encontradas nos clientes no qual temos uma rede virtual Spoke com sub-rede para as máquinas virtuais e outra sub-rede para o private endpoint. Este cenário é implementado quando não é possível ter uma rede virtual dedicada para os private endpoints.

Neste caso será injetado rotas de sistema nas sub-redes das máquinas /32 apontando para cada private endpoint.

Veja abaixo o exemplo das rotas efetivas de uma máquina virtual

Neste caso para que o tráfego destinado ao private endpoint seja encaminhado para o firewall será necessário adicionar uma rota para cada endereço ip privado dos private endpoints o que aumenta a carga administrativa de manutenção das tabelas de rota e a possibilidade de atingir o limite de 400 rotas.

Cenário 3: Rede virtual única

Neste cenário temos apenas uma única rede virtual e as mesmas considerações do cenário 2 são aplicadas aqui.

Isso acontece devido a injeção das rotas /32 dos private endpoints para as subnets.

Cenário 4: Tráfego on-premises para private endpoints

Neste cenário temos a necessidade de inspecionar no Firewall tráfego vindo do datacenter para os private endpoints. Também temos as mesmas considerações do cenário 2. Para que o tráfego destinado aos private endpoints sejam inspecionados pelo Azure Firewall devemos adicionar na tabela de rota da GatewaySubnet uma rota para cada endereço IP /32 dos private endpoints para o Firewall.

Irei cobri aqui um novo cenário cobrindo os cenários dois e quatro, usando o recurso de Network Policy o que irá auxiliar no controle de rotas.

Cenário 5: Hub e Spoke usando Network Policy

Este cenário seria uma adição do cenário dois e do cenário quatro, porém iremos habilitar o recurso de Network Policy na sub-rede dedicada para private endpoint.

O que é Network Policy?

Por padrão, as políticas de rede são desabilitadas para uma sub-rede em uma rede virtual. Para utilizar políticas de rede como suporte a Rotas Definidas pelo Usuário e Grupos de Segurança de Rede será necessário habilitar este serviço do Network Policy na sub-rede dos private endpoints pois essa configuração é aplicável somente a estes recursos.

Ao habilitar o Network Policy as rotas /32 que são geradas pelos private endpoints e propagadas para todas as sub-redes em sua própria VNet e VNets diretamente emparelhadas serão invalidadas.

Etapa 1: Cenário antes de habilitar o Network Policy

Por padrão o Network Policy não é habilitado nas sub-redes. Com isso ao criar um private endpoint uma rota de sistema /32 com endereço ip privado do private endpoint será automaticamente injetada nas sub-redes da rede virtual.

O diagrama abaixo ilustra este comportamento das rotas efetivas na máquina virtual 10.100.0.4 e percebemos que a rota de sistema foi adicionada automaticamente após a criação do private endpoint para uma conta de armazenamento recebendo o endereçamento privado 10.100.1.4.

Etapa 2: Cenário após habilitar o Network Policy

No nosso laboratório habilitamos o Network Policy na sub-rede 10.100.1.0/25 dedicada para private endpoints.

As rotas injetadas /32 serão invalidadas conforme a imagem abaixo.

O diagrama abaixo ilustra as atividades executadas aqui.

Etapa 3: Adicionado rotas para inspeção passando pelo Azure Firewall

Com isso será possível configurar nas UDRs todo tráfego destinado à sub-rede do private endpoint 10.100.1.0/25 serão encaminhadas para o Firewall sem a necessidade de adicionar cada rota /32 individualmente para casa private endpoint existente dentro do ambiente.

Tabela de rota aplicada na sub-rede da máquina virtual:

Tabela de rota aplicada na SubnetGateway

Podemos adicionar a rota na GatewaySubnet na rede virtual hub, para que o tráfego vindo do on-premises para os serviços de private endpoints também seja encaminhado para o Firewall.

Olhando novamente no nosso desenho do laboratório vemos as respectivas tabelas de rota configuradas e como o uso do Network Policy facilita essa configuração pois não temos a necessidade de adicionar individualmente cada endereço IP /32 na tabela rota.

Ao final temos arquitetura do nosso laboratório como ilustrado na imagem abaixo.

Teste e validações:

Para simular os testes temos uma conta de armazenamento com private endpoint configurado para a sub-rede destinada aos private endpoints 10.100.1.0/25 recebendo o endereçamento privado 10.100.4.4

No Azure Firewall temos uma regra de rede negando as conexões para a sub-rede 10.100.1.0/25 de qualquer origem, porta e protocolo. Relembrando está é a nossa sub-rede dedicada para os private endpoints.

Faremos os testes de resolução DNS e de conexão com a storage Account a partir das máquinas virtuais simulando on-premises e Spoke. A resolução DNS para a conta de armazenamento com private endpoint irá retornar o IP privado, porém a conexão para listar os Blobs dentro da conta de armazenamento usando a CLI irá falhar devido a regra de DENY do Firewall

Comandos utilizados:

nslookup stalabnonprod01.blob.core.windows.net
az storage blob list --account-name stalabnonprod01 --container-name teste --account-key <KEY DA CONTA DE ARMAZENAMENTO> --output table

Conexão a partir da máquina On-premises

VM-Onpremises
- IP: 192.168.10.11

Resolução DNS OK

Tentativa de listar os blobs da conta de armazenamento stalabnonprod01 sem sucesso

Conexão a partir da máquina virtual Spoke

VM-Spoke:
- IP: 10.100.0.4

Resolução DNS OK

Tentativa de listar os blobs da conta de armazenamento stalabnonprod01 sem sucesso

No Log do Firewall podemos validar a tentativa de conexão através da seguinte query de NetworkRule adicionado apenas ao final da query para trazer as conexões com a ação de “DENY”.

// Network rule log data // Parses the network rule log data. AzureDiagnostics | where Category == "AzureFirewallNetworkRule" | where OperationName == "AzureFirewallNatRuleLog" or OperationName == "AzureFirewallNetworkRuleLog" //case 1: for records that look like this: //PROTO request from IP:PORT to IP:PORT. | parse msg_s with Protocol " request from " SourceIP ":" SourcePortInt:int " to " TargetIP ":" TargetPortInt:int * //case 1a: for regular network rules | parse kind=regex flags=U msg_s with * ". Action\\: " Action1a "\\." //case 1b: for NAT rules //TCP request from IP:PORT to IP:PORT was DNAT'ed to IP:PORT | parse msg_s with * " was " Action1b:string " to " TranslatedDestination:string ":" TranslatedPort:int * //Parse rule data if present | parse msg_s with * ". Policy: " Policy ". Rule Collection Group: " RuleCollectionGroup "." * | parse msg_s with * " Rule Collection: " RuleCollection ". Rule: " Rule //case 2: for ICMP records //ICMP request from 10.0.2.4 to 10.0.3.4. Action: Allow | parse msg_s with Protocol2 " request from " SourceIP2 " to " TargetIP2 ". Action: " Action2 | extend SourcePort = tostring(SourcePortInt), TargetPort = tostring(TargetPortInt) | extend Action = case(Action1a == "", case(Action1b == "",Action2,Action1b), split(Action1a,".")[0]), Protocol = case(Protocol == "", Protocol2, Protocol), SourceIP = case(SourceIP == "", SourceIP2, SourceIP), TargetIP = case(TargetIP == "", TargetIP2, TargetIP), //ICMP records don't have port information SourcePort = case(SourcePort == "", "N/A", SourcePort), TargetPort = case(TargetPort == "", "N/A", TargetPort), //Regular network rules don't have a DNAT destination TranslatedDestination = case(TranslatedDestination == "", "N/A", TranslatedDestination), TranslatedPort = case(isnull(TranslatedPort), "N/A", tostring(TranslatedPort)), //Rule information Policy = case(Policy == "", "N/A", Policy), RuleCollectionGroup = case(RuleCollectionGroup == "", "N/A", RuleCollectionGroup ), RuleCollection = case(RuleCollection == "", "N/A", RuleCollection ), Rule = case(Rule == "", "N/A", Rule) | project TimeGenerated, msg_s, Protocol, SourceIP,SourcePort,TargetIP,TargetPort,Action, TranslatedDestination, TranslatedPort, Policy, RuleCollectionGroup, RuleCollection, Rule | where Action contains "Deny"

Visualizamos que o tráfego originando das máquinas 10.100.0.4 (SpokeVM) e 192.168.10.11 (VM Onpremises) para o destino 10.100.1.4 (endereço ip do private endpoint da conta de armazenamento) foi negado este tráfego pela regra do Azure Firewall “DenyPrivateEndpoint”.

Com isso validamos a inspeção do tráfego destinado para o private endpoint encaminhando esse tráfego para tratamento pelo Azure Firewall.

Para finalizar iremos excluir a regra de Deny no Azure Firewall, e com isso o acesso para a conta de armazenamento será permitida.

Testando novamente:

Acesso permitido a partir da VM Onpremises

Acesso permitido a partir da VM Spoke

Resumo:

Network Policy habilitado na sub-rede destinado aos private endpoints.
A injeção da rota de sistema /32 nas sub-redes será invalidada.
Adicionar a rota com destino a sub-rede do private endpoint com Next Hop o Azure Firewall ou outra solução de NVA de terceiros
Caso o tráfego de origem vindo do on-premises para o private endpoint também seja encaminhado para o firewall basta adicionar a rota na UDR da SubnetGateway

Links para mais informações:

What is a private endpoint? - Azure Private Link | Microsoft Learn

Use Azure Firewall to inspect traffic destined to a private endpoint - Azure Private Link | Microsoft Learn

Manage network policies for private endpoints - Azure Private Link | Microsoft Learn

Manage blob containers using Azure CLI - Azure Storage | Microsoft Learn