Hub & Spoke med AKS: Del 2

+--------+      +--------+      +--------+
| Public |      |  WAF   |      |  ILB   |
|Internet| <--> |        | <--> | (AKS)  |
+--------+      +--------+      +--------+
                  | |              |
                  | |              |
              +--------+       +--------+
              |        |       |  AKS   |
              |  Hub   |       |Service |
              |        |       +--------+
              +--------+
              | Azure  |
              |Firewall|
              +--------+

I innlegget "Hub & Spoke with AKS: A Balancing Act?" gikk vi gjennom noen av de ‘ut-av-boksen’ problemene med naturlig provisjonerte AKS-klynger, når vi bygger ut en typisk Hub & Spoke. I dette innlegget vil vi undersøke noen av konfigurasjonene vi kan bruke når vi oppretter klyngene dine. Holde applikasjonsdataene og DNS symmetriske og passere gjennom sikkerhetsapparatet ditt.

Konsept

Vi kommer ikke til å dekke CNI direkte i dette innlegget. CNI-er er allerede dekket i detalj hos Microsoft Learns. Oppsettet nedenfor vil fungere med både Azure CNI og Kubenet. Jeg vil dekke Overlay og Cilium CNI-alternativer i et annet innlegg.

Les mer om CNI i "Networking concepts for applications in Azure Kubernetes Service (AKS)" hos Microsoft Learn. 

Vi har vårt morsomme ASCii-diagram ovenfor. Nedenfor har vi en mer detaljert plan for hvordan vi ønsker at trafikken vår skal flyte;

Outbound type

Nå, la oss starte med Terraform som vi trenger for å faktisk provisjonere klyngen med de nødvendige nettverksendringene. En av de viktigste innstillingene kalles «outboundType» (ARM) eller «outbound_type» i Terraform. Som standard er dette satt til «loadBalancer», vi må endre dette til «userDefinedRouting» som vist nedenfor:

Når vi setter «userDefinedRouting» som «outbound_type», vil dette fjerne den AKS-administrerte rutingen for utgående trafikk, som normalt vil gå ut av lastbalanseren direkte til internett. Dette refereres til som «managedOutboundIPs» i Azure Resource Manager (ARM).

User assigned identity

Deretter må du knytte en route table til AKS subnet eller Azure API vil ikke tillate opprettelsen av klyngen. Vi må også sørge for at identity type er «UserAssigned».

Et steg til, du må manuelt tildele cluster roles til User Assigned Managed Identity (UAMI). Dette vil gi AKS Identity tilgang til de nødvendige ressursene.

Les mer om UAMI i "What are managed identities for Azure resources?" hos Microsoft Learn. 

Route table

Så dette er de grunnleggende byggeklossene for en klynge som kan rute trafikk gjennom Azure firewall eller din NVA. Jeg vil anbefale å bruke en Palo Alto-serie brannmur som kan installeres fra Azure marketplace. En merknad er at argumentet «next_hop_in_ip_address» er den faktiske IP-adressen til brannmuren. Dette vil/bør selvfølgelig være i et VNET peered Security/Hub-abonnement.

I tillegg må du opprette brannmuråpninger til Azure-ressurser før du begynner å bygge i Terraform.

Brannmurkravene finner du i "Outbound network and FQDN rules for Azure Kubernetes Service (AKS) clusters" hos Microsoft Learn.

DNS proxy

En siste del av puslespillet gjelder spoke VNET. Vi ønsker å kunne se de fullstendige FQDN DNS-forespørslene som kommer fra podene. Dette vil tillate deg å bruke applikasjonsregler hvis du bruker Azure firewall, og dermed øke synligheten av forespørslene som gjøres av de kjørende containerne betydelig. Dette er en engangsoppsett, så det kan gjøres i portalen. Vi må endre DNS-serverne til VNET til brannmurens IP.

Eksempelbrannmuren nedenfor er satt til «10.160.1.150», så vi har brukt det nedenfor også:

Husk å aktivere DNS-proxyen på brannmuren din for å få fullstendig synlighet i all trafikk som går ut av AKS-klyngen din.