Overzicht van Azure Kubernetes Application Network-beveiliging (preview)

Belangrijk

AKS preview-functies zijn beschikbaar op selfservice, opt-in basis. Previews worden geleverd 'zoals het is' en 'voor zover beschikbaar' en zijn uitgesloten van de serviceovereenkomsten en beperkte garantie. AKS-previews worden gedeeltelijk gedekt door klantondersteuning naar best vermogen. Zodoende zijn deze functies niet bedoeld voor productiegebruik. Zie de volgende ondersteuningsartikelen voor meer informatie:

Azure Kubernetes Application Network beveiligt de communicatie tussen services in verbonden AKS-clusters (Azure Kubernetes Service) via automatische wederzijdse TLS (mTLS) en op identiteit gebaseerde autorisatie. Het geeft workloadidentiteiten uit en beheert certificaatuitgifte, rotatie en validatie om versleutelde, geverifieerde en expliciet geautoriseerde service-naar-service-communicatie zonder handmatige configuratie in te schakelen, met FIPS-compatibele versleuteling tijdens overdracht.

Dit artikel bevat een overzicht van de beveiligingsfuncties in Azure Kubernetes Application Network, waaronder mTLS, workloadidentiteiten, certificaatbeheer en autorisatiebeleid. Ook worden beperkingen en volgende stappen beschreven voor het implementeren van beveiligde communicatie in uw Azure Kubernetes Application Network-omgeving.

Beperkingen

Certificaten worden momenteel uitgegeven door een door azure Kubernetes Application Network beheerde certificeringsinstantie (CA) en worden niet gekoppeld aan een openbare CA.

mTLS

Application Network maakt gebruik van mTLS om op identiteit gebaseerde, versleutelde communicatie tussen workloads te bieden. Elke service in een cluster dat is verbonden met een toepassingsnetwerk ontvangt automatisch een certificaat waarmee de identiteit kan worden bewezen en vertrouwde, versleutelde verbindingen met andere services in hetzelfde toepassingsnetwerk tot stand kan worden gebracht. Versleuteling in transit maakt gebruik van FIPS-compatibele cryptografie.

mTLS-migratiestrategie

Application Network staat momenteel versleuteld en niet-versleuteld verkeer toe. Deze aanpak zorgt ervoor dat bestaande workloads normaal blijven werken terwijl nieuwe of bijgewerkte workloads automatisch mTLS gebruiken voor veilige communicatie. Dit betekent dat u mTLS kunt gebruiken voor veilige communicatie tussen uw workloads zonder uitvaltijd. Nadat de migratie is voltooid, kunt u overschakelen naar de strikte modus, zodat verificatie wordt afgedwongen.

Voordelen van mTLS in Azure Kubernetes Application Network

mTLS in Azure Kubernetes Application Network helpt u bij het volgende:

Gegevens tijdens overdracht beveiligen: al het service-naar-serviceverkeer kan automatisch worden versleuteld (FIPS-compatibel).
Controleer de service-id: elke workload heeft een uniek door het toepassingsnetwerk beheerde basis- en tussencertificaat.
Vereenvoudig bewerkingen: Application Network verwerkt certificaatuitgifte, rotatie en intrekking voor gebruikers.

Certificaatbeheer

Azure Kubernetes Application Network biedt certificaatbeheer dat wordt ondersteund door Azure Key Vault die de certificaten onderhoudt die worden gebruikt voor mTLS. Met deze service wordt een gedeelde vertrouwensgrens vastgesteld voor alle AKS-clusters die zijn verbonden met dezelfde Application Network-resource.

Application Network beheert automatisch de volledige levenscyclus van certificaten voor basis- en tussenliggende certificaten, waaronder inrichten, vernieuwen en rouleren. Dit zorgt ervoor dat workloadidentiteiten geldig blijven en communicatie in de loop van de tijd veilig blijft. U hoeft geen certificaten handmatig te maken, op te slaan of te roteren.

In het volgende diagram ziet u de certificaathiërarchie in Application Network, waarin wordt getoond hoe de basis-CA,tussenliggende CA's en workloadcertificaten zijn gestructureerd om een vertrouwensrelatie tot stand te brengen tussen verbonden clusters:

Certificaathiërarchie en levenscyclus

Wanneer een toepassingsnetwerkresource wordt gemaakt, wordt een basis-CA ingericht om te fungeren als vertrouwensanker voor het toepassingsnetwerk. Wanneer een AKS-cluster lid wordt van het toepassingsnetwerk, geeft Application Network een tussenliggend certificaat uit voor dat lid dat is ondertekend door de basis-CA van het toepassingsnetwerk. Elk verbonden AKS-cluster maakt gebruik van het tussenliggende toepassingsnetwerkcertificaat om kortdurende workloadcertificaten uit te geven aan workloads in dat cluster.

Alle workloadcertificaten nemen vertrouwen over van de root-CA van het toepassingsnetwerk, waarbij een universele vertrouwensgrens over de resource wordt gehandhaafd. De rotatie van basis- en tussencertificaten wordt transparant verwerkt voor gebruikers zonder downtime of verkeersonderbrekingen te veroorzaken. Deze beheerde hiërarchie zorgt voor een consistente, verifieerbare vertrouwensrelatie in alle clusters in een toepassingsnetwerk, terwijl de geldigheid van elk certificaat automatisch wordt gehandhaafd.

Vanuit elk lidcluster kunt u het basis-CA-certificaat ophalen uit de configuratietoewijzing istio-root-cert onder naamruimte applink-system.

Certificaattypen en rotatieperioden

Certificaattype	Scope	Geldigheidsduur	Rotatieperiode	Purpose
Root-CA	Azure Kubernetes-toepassingsnetwerk	12 maanden	6 maanden	Hiermee wordt de vertrouwensgrens vastgesteld voor alle clusters die zijn verbonden met het Azure Kubernetes-toepassingsnetwerk
Tussenliggende CA	Cluster	90 dagen	45 dagen	Geeft workloadcertificaten af voor workloads binnen dat cluster
Workload-certificaat	Werklast	24 uur	12 uur	Verifieert workloads en beveiligt dienst-tot-dienst communicatie

Workload-identiteit en -autorisatie

Naarmate toepassingen groeien, moeten services vaak veilig communiceren tussen verschillende naamruimten en omgevingen binnen dezelfde implementatie. Het beheren van certificaten en ervoor zorgen dat elke service kan controleren met wie het praat, kan snel complex en foutgevoelig worden. Azure Kubernetes Application Network elimineert deze overhead door automatisch workloadidentiteiten toe te wijzen en te beheren.

Binnen een omgeving die is verbonden met een toepassingsnetwerk, communiceren workloads veilig binnen en tussen naamruimten. Om ervoor te zorgen dat elke service kan worden vertrouwd en geverifieerd, wijst Application Network elke workload een verifieerbare identiteit toe die de naamruimte en het serviceaccount vertegenwoordigt.

Elke workload van het toepassingsnetwerk ontvangt automatisch een unieke identiteit in de SPIFFE-indeling , waaronder de naamruimte en het serviceaccount. De identiteit is als volgt opgemaakt:

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

Deze identiteit is ingesloten in het workloadcertificaat en wordt gebruikt om de identiteit van de service te bewijzen bij het communiceren met andere workloads. Azure Kubernetes Application Network maakt gebruik van dit op SPIFFE gebaseerde identiteitsmodel met istio-autorisatiebeleid, zodat u duidelijke, consistente regels kunt definiëren waarvoor services mogen communiceren.

Toegangsbeleid definiëren

U kunt Istio AuthorizationPolicies gebruiken om te bepalen welke workloads binnen uw omgeving mogen communiceren. Met dit beleid kunt u toegang definiëren op basis van geverifieerde workloadidentiteiten in plaats van netwerklocaties of IP-adressen. Met deze aanpak kunt u consistente toegangsbeheer afdwingen, zelfs wanneer services worden geschaald en over knooppunten worden verplaatst. U kunt bijvoorbeeld alleen specifieke gateways of workloads van vertrouwde naamruimten toestaan om een service aan te roepen door te verwijzen naar hun SPIFFE-identiteiten in de lijst met principals van het beleid, zoals wordt weergegeven in het volgende voorbeeld:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

Richtlijnen voor beleidsontwerp

Houd bij het ontwerpen van autorisatiebeleid rekening met de volgende aanbevolen procedures:

Geef altijd zowel de naamruimte als het serviceaccount op om onbedoelde toegang tot meerdere naamruimten te voorkomen.
Gebruik principals om expliciete workloadidentiteiten te definiëren voor verfijnde toegang.
Gebruik naamruimten om bredere vertrouwensgrenzen te definiëren, indien van toepassing.
Vermijd regels die alleen overeenkomen met serviceaccountnamen zonder naamruimten, omdat dit toegang kan verlenen tussen clusters of omgevingen.
Combineer AuthorizationPolicies met Kubernetes NetworkPolicies om isolatie op basis van identiteiten en netwerken af te dwingen.

Opmerking

Azure Kubernetes Application Network-autorisatie is gebaseerd op geverifieerde workloadidentiteit in plaats van IP-adres. Dit zorgt voor consistente afdwinging, zelfs wanneer workloads worden geschaald of over knooppunten worden verplaatst.

Door Azure Kubernetes Application Network beheerde identiteiten, certificaten en beleidscontroles te combineren, kunt u op identiteit gebaseerde servicecommunicatie met minimale bevoegdheden implementeren, geverifieerd, versleuteld en expliciet geautoriseerd verkeer tussen workloads in clusters implementeren.

Zie de volgende artikelen voor meer informatie over Azure Kubernetes Application Network:

Feedback

Is deze pagina nuttig?

Laatst bijgewerkt om 2026-03-23