Implementatiebeveiligingen gebruiken om best practices af te dwingen in Azure Kubernetes Service (AKS)

In dit artikel leest u hoe u Implementatiebeveiligingen gebruikt om best practices af te dwingen voor een AKS-cluster (Azure Kubernetes Service).

Overzicht

Notitie

Implementatiebeveiliging is standaard ingeschakeld in AKS Automatic.

Tijdens de ontwikkelingslevenscyclus is het gebruikelijk dat er fouten, problemen en andere problemen optreden als de eerste implementatie van uw Kubernetes-resources onjuiste configuraties bevat. Om de belasting van Kubernetes-ontwikkeling te vereenvoudigen, biedt Azure Kubernetes Service (AKS) implementatiebeveiligingen. Met implementatiebeveiligingen worden aanbevolen procedures voor Kubernetes in uw AKS-cluster afgedwongen via Azure Policy-besturingselementen.

Implementatiebeveiligingen bieden twee configuratieniveaus:

• Warn: Geeft waarschuwingsberichten weer in de codeterminal om u te waarschuwen voor eventuele niet-compatibele clusterconfiguraties, maar staat de aanvraag nog steeds toe.
• Enforce: Dwingt conforme configuraties af door implementaties te weigeren en te wijzigen als ze niet voldoen aan de aanbevolen procedures.

Nadat u Implementatiebeveiligingen hebt geconfigureerd voor 'Waarschuwen' of 'Afdwingen', worden uw Kubernetes-resources programmatisch beoordeeld bij het maken of bijwerken van uw Kubernetes-resources voor naleving. Implementatiebeveiligingen geven ook geaggregeerde nalevingsinformatie weer voor uw workloads op resourceniveau via het nalevingsdashboard van Azure Policy in Azure Portal of in uw CLI of terminal. Het uitvoeren van een niet-compatibele workload geeft aan dat uw cluster niet de aanbevolen procedures volgt en dat workloads op uw cluster risico lopen op problemen die worden veroorzaakt door de clusterconfiguratie.

Vereisten

Notitie

Clusterbeheerders hebben geen Azure Policy-machtigingen nodig om implementatiebeveiligingen in of uit te schakelen. De Azure Policy-invoegtoepassing moet echter zijn geïnstalleerd.

• U moet de Azure Policy-invoegtoepassing voor AKS inschakelen. Zie Azure Policy inschakelen in uw AKS-cluster voor meer informatie. Dit omvat het registreren van de Microsoft.PolicyInsights resourceprovider in uw abonnement.

Implementatiebeveiligingsbeleid

De volgende tabel bevat de beleidsregels die actief worden en de Kubernetes-resources waarop ze zijn gericht wanneer u Implementatiebeveiligingen inschakelt. U kunt de momenteel beschikbare implementatiebeveiligingen in Azure Portal weergeven als een Azure Policy-definitie of in ingebouwde Azure Policy-definities voor Azure Kubernetes Service. De bedoeling achter deze verzameling is om een algemene en algemene lijst met aanbevolen procedures te maken die van toepassing zijn op de meeste gebruikers en gebruiksvoorbeelden.

Beveiligingsbeleid voor implementaties	Mutatieresultaat indien beschikbaar
Kan afzonderlijke knooppunten niet bewerken	Niet van toepassing.
Cpu- en geheugenresourceaanvragen voor Kubernetes-clustercontainers moeten worden gedefinieerd	Hiermee stelt u standaard CPU- en geheugenaanvragen in en dwingt u minimumwaarden af. Zie voor meer informatie de mutator voor resourceaanvragen.
Moet antiaffiniteitsregels of topologySpreadConstraintsSet hebben	Hiermee worden antiaffiniteitsregels voor pods en topologiespreidingsbeperkingen toegevoegd om de workloaddistributie te verbeteren. Zie voor meer informatie Antiaffiniteit en topologie-mutator.
Geen AKS-specifieke labels	Niet van toepassing.
Kubernetes-clustercontainers mogen alleen toegestane images gebruiken.	Niet van toepassing.
Gereserveerde systeemgroep Taints	Hiermee verwijdert u de CriticalAddonsOnly taint uit een gebruikersknooppuntgroep als deze niet is ingesteld. AKS gebruikt de CriticalAddonsOnly taint om klantpods weg te houden van de systeempool. Deze configuratie zorgt voor een duidelijke scheiding tussen AKS-onderdelen en pods van klanten en voorkomt verwijdering van pods van klanten die de CriticalAddonsOnly taint niet tolereren.
Zorg ervoor dat clustercontainers gereedheids- of actiefheidstests geconfigureerd hebben.	Niet van toepassing.
Kubernetes-clusters moeten gebruikmaken van het CSI-stuurprogramma StorageClass (Container Storage Interface)	Niet van toepassing.
Kubernetes-clusterservices moeten gebruikmaken van unieke selectors	Niet van toepassing.
Containerinstallatiekopieën van Kubernetes-clusters mogen niet de meest recente installatiekopieën van de installatiekopieën bevatten	Niet van toepassing.

Als u een idee of aanvraag voor implementatiebeveiligingen wilt indienen, opent u een probleem in de GitHub-opslagplaats van AKS en voegt u dit toe [Deployment Safeguards request] aan het begin van de titel.

Mutator voor resourceaanvragen

Wanneer Implementatiebeveiligingen is ingesteld op het Enforce niveau, stelt de mutator voor resourceaanvragen automatisch CPU- en geheugenaanvragen en -limieten in voor containers waarvoor deze niet zijn gedefinieerd of waarden hebben onder de minimale drempelwaarden.

Standaardwaarden

Wanneer er geen resources zijn opgegeven, stelt de mutator de volgende standaardwaarden in:

Hulpbron	Aanvraag	Limit
CPU (Centrale Verwerkings Eenheid)	500m	500m
Memory	2048Mi (2Gi)	2048Mi (2Gi)

Minimale afdwinging

Wanneer resources worden opgegeven, maar ze onder drempelwaarden vallen, dwingt de mutator de volgende minimumwaarden af:

Hulpbron	Minimumwaarde
CPU (Centrale Verwerkings Eenheid)	100 m
Memory	100Mi

Informatie over resource-eenheden

CPU-eenheden:

• m = millicores (1m = 1/1.000e van een CPU-kern)
• 1000m = 1 volledige CPU-kern
• 500m = 0,5 CPU-kernen (halve kern)
• 100m = 0,1 CPU-kernen (10% van een kern)

Geheugeneenheden:

• Mi = Mebibytes (binair: 1 Mi = 1.024 × 1.024 bytes)
• Gi = Gibibytes (binair: 1 Gi = 1,024 Mi)
• 2048Mi = 2Gi
• 100Mi ≈ 105 MB

CPU mutatieregels

De mutator past de volgende logica toe voor CPU-resources:

Scenario	Handeling
Zowel cpu-aanvraag als limiet ontbreken	Beide instellen op 500m (standaard)
CPU-aanvraag bestaat, maar is kleiner dan 100m	Aanvraag instellen op 100m (minimaal)
DE CPU-limiet bestaat, maar is kleiner dan 100m	Limiet instellen op 100m (minimum)
Er bestaat alleen een CPU-aanvraag	Aanvraag gelijk aan limiet instellen
Alleen de CPU-limiet bestaat	Aanvraag gelijk aan limiet instellen

Geheugenmutatieregels

De mutator past de volgende logica toe voor geheugenbronnen:

Scenario	Handeling
Zowel geheugenaanvraag als limiet ontbreken	Beide instellen op 2048Mi (standaard)
Geheugenaanvraag bestaat, maar is kleiner dan 100Mi	Aanvraag instellen op 100Mi (minimaal)
Geheugenlimiet bestaat, maar is kleiner dan 100Mi	Limiet instellen op 100Mi (minimum)
Alleen de geheugenaanvraag bestaat	Laat as-is staan (geen limiet toegevoegd)
Alleen de geheugenlimiet bestaat	Laat as-is staan (geen aanvraag toegevoegd)

Kubernetes-kwaliteit-van-dienstverlening (QoS)-klasse reparatie

Nadat CPU- en geheugenmutaties zijn toegepast, geldt dat als de aanvraagwaarde de limiet voor hetzelfde resourcetype overschrijdt, de mutator de aanvraagwaarde aanpast om overeen te komen met de limiet. Met deze oplossing worden geldige QoS-klasseconfiguraties (Kubernetes Quality of Service) onderhouden.

Gevallen die zijn gemuteerd

De mutator voor resourceaanvragen past wijzigingen toe in de volgende scenario's:

• Lege hulpmiddelen: Containers zonder CPU- of geheugenvragen of -limieten krijgen standaardwaarden (500m CPU, 2048Mi geheugen).
• Onder minimale drempelwaarden: CPU-aanvragen of -limieten hieronder 100m worden verhoogd tot 100m. Geheugenaanvragen of -limieten hieronder 100Mi worden verhoogd tot 100Mi.
• Ongeldige QoS-scenario's: wanneer aanvragen limieten overschrijden, worden aanvragen verlaagd tot overeenkomende limieten.
• Gedeeltelijke resourcespecificaties: Containers met alleen aanvragen of alleen limieten (maar niet beide) worden gedwongen minimumwaarden te gebruiken waar gespecificeerd.
• Meerdere containers: alle containers in een pod worden op de juiste wijze verwerkt en gemuteerd.
• Ingeschakelde naamruimten: Alleen werkbelastingen in naamruimten met ingeschakelde beveiliging worden gemuteerd.

Gevallen die niet zijn gemuteerd

De mutator voor resourceaanvragen past geen wijzigingen toe in de volgende scenario's:

• Uitgesloten naamruimten: workloads in naamruimten waarbij de beveiliging wordt uitgesloten, blijven ongewijzigd.
• Reeds conforme middelen: Containers die al aanvragen en limieten hebben boven minimale drempelwaarden blijven ongewijzigd.
• Geldige QoS-configuraties: wanneer aanvragen kleiner zijn dan of gelijk zijn aan limieten en beide waarden boven de minimumwaarden liggen, treden er geen wijzigingen op.

Anti-affiniteit en topologie-spreiding-mutator

Wanneer Implementatiebeveiliging is ingesteld op het Enforce niveau, voegt de antiaffiniteits- en topologieverspreidingsmutator automatisch pod-anti-affiniteitsregels en topologieverspreidingsbeperkingen toe om de workloaddistributie over de nodes te verbeteren.

Wanneer de mutator wordt uitgevoerd

De mutator wordt alleen uitgevoerd wanneer aan alle volgende voorwaarden wordt voldaan:

• Op de workload zijn er nog geen beperkingen voor zowel pod anti-affiniteit als topologiespreiding.
• De naamruimte is niet uitgesloten van implementatiebeveiligingen.
• Implementatiebeveiligingen zijn in Enforce de modus.
• De workload heeft niet het kubernetes.azure.com/managedby=aks label.

Wat de mutator toevoegt

Labelidentificatie: De mutator identificeert pods met behulp van de volgende labelprioriteit:

• app label (eerste prioriteit)
• app.kubernetes.io/name label (tweede prioriteit)
• Hiermee maakt u een default-antiaffinity-applabel=<workload-name> label (terugval)

Pod-anti-affiniteit: voegt een pod-antiaffiniteitsregel toe met gewicht 100 die de voorkeur geeft aan het plannen van pods met overeenkomende labels op verschillende knopen. Gebruikt topologiesleutel kubernetes.io/hostname.

Beperkingen voor topologiespreiding: Hiermee voegt u een beperking toe met de volgende instellingen:

Configuratie	Waarde
MaxSkew	1 (maakt maximaal verschil van 1 pod per knooppunt mogelijk)
Indien niet uitvoerbaar	ScheduleAnyway (best-effort, blokkeert planning niet)
Topologiesleutel	kubernetes.io/hostname

Gevallen die zijn gemuteerd

Met de antiaffiniteits- en topologiespreidingsmutator worden wijzigingen in de volgende scenario's toegepast:

• Workloads met app label: maakt gebruik van de app labelwaarde voor anti-affiniteits- en topologiespread-selectors.
• Workloads met app.kubernetes.io/name label: als er geen app label bestaat, wordt dit label gebruikt voor selectors.
• Workloads zonder app-labels: hiermee maakt u een standaardlabel met behulp van de naam van de workload en voegt u antiaffiniteits- en topologiespreidingsregels toe.
• Schone werkbelastingen: workloads zonder bestaande affiniteits- of topologiespreidingsbeperkingen ontvangen beide configuraties.
• Gedeeltelijke affiniteit: workloads met bestaande knooppuntaffiniteit (maar geen pod-antiaffiniteit) ontvangen antiaffiniteits- en topologiespreidingsregels voor pods.
• Ingeschakelde naamruimten: Mutaties vinden alleen plaats in naamruimten waarbij de beveiliging is ingeschakeld.

Gevallen die niet zijn gemuteerd

De mutator voor antiaffiniteit en topologiespreiding past geen wijzigingen toe in de volgende scenario's:

• Bestaande beperkingen voor topologiespreiding: workloads met eventuele beperkingen voor topologiespreiding worden volledig overgeslagen.
• Bestaande pod-antiaffiniteit: workloads met bestaande vereiste of voorkeursregels voor pod-antiaffiniteit worden volledig overgeslagen.
• Uitgesloten naamruimten: workloads in naamruimten waarbij de beveiliging wordt uitgesloten, blijven ongewijzigd.
• Workloads zonder identificeerbare namen of labels: Randgevallen waarin geen applicatienaam kan worden bepaald, worden probleemloos overgeslagen.

Foutberichten over de implementatiebeveiliging

In deze sectie worden de foutberichten beschreven die kunnen optreden wanneer implementatiebeveiligingen niet-compatibele configuraties detecteren, samen met aanbevolen oplossingen.

Algemene beveiligingsfoutberichten

De volgende tabel bevat foutberichten voor algemene beleidsregels voor implementatiebeveiliging:

Policy	Foutmelding	Repareren
Probes afdwingen	Container <container_name> in your Pod <pod_name> has no livenessProbe. Required probes: readinessProbe, livenessProbe	Voeg liveness- en gereedheidstests toe aan elke container.
Geen 'nieuwste' afbeelding	Please specify an explicit, versioned image tag such as '1.0' for container %v. Using explicit version tags is a best practice to ensure reproducibility, prevent unintended updates, and facilitate easier debugging and rollbacks. Avoid using the 'latest' tag because it can change over time without notice.	Gebruik een expliciete afbeeldingstag anders dan latest of leeg. Is bijvoorbeeld nginx niet toegestaan, maar nginx:v1.0.0 wel toegestaan.
CSI-stuurprogramma afdwingen	Storage class <class_name> use intree provisioner kubernetes.io/azure-file is not allowed of Storage class <class_name> use intree provisioner kubernetes.io/azure-disk is not allowed	Gebruik disk.csi.azure.com of file.csi.azure.com in plaats daarvan. Zie CSI-stuurprogramma's op AKS voor meer informatie.
Resourceaanvragen	container <container_name> has no resource requests	Voeg CPU- en geheugenaanvragen toe aan uw container.
AntiAffinity-regels	Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing	Definieer podAntiAffinity of topologySpreadConstraints op de workload.
Beperkte labels	Label kubernetes.azure.com is reserved for AKS use only	Verwijder het label uit uw workload.
Bewerkingen van beperkte knooppunten	Tainting or labeling individual nodes is not recommended. Please use Azure CLI to taint/label node pools instead	Gebruik de Azure CLI om knooppuntgroepen te tainten of labelen in plaats van afzonderlijke knooppunten.
Beperkte Taints	Taint with key CriticalAddonsOnly is reserved for the system pool only	Tast de gebruikersknooppuntgroep niet aan met CriticalAddonsOnly.

Foutberichten over podbeveiligingsstandaarden

Notitie

Basislijnbeveiligingsstandaarden voor pods zijn nu standaard ingeschakeld in AKS Automatic. De basislijnbeveiligingsstandaarden voor pods in AKS Automatisch kunnen niet worden uitgeschakeld.

Implementatiebeveiligingen bieden ook ondersteuning voor het inschakelen van basislijn-, beperkte- en bevoegde beveiligingsstandaarden voor pods. Zorg ervoor dat elk manifest voldoet aan de Baseline- of Restricted Pod Security-vereisten om ervoor te zorgen dat uw workloads met succes worden geïmplementeerd. Azure Kubernetes Service maakt standaard gebruik van Privileged Pod Security Standards.

Policy	Foutmelding	Repareren
AppArmor	AppArmor annotation values must be undefined/nil, runtime/default, or localhost/* of AppArmor profile type must be one of: undefined/nil, RuntimeDefault, or Localhost	Verwijder een specificatie van AppArmor. Kubernetes past standaard AppArmor-instellingen toe. Op ondersteunde hosts wordt het RuntimeDefault AppArmor-profiel standaard toegepast.
Hostnaamruimten	Host network namespaces are disallowed: spec.hostNetwork is set to trueof Host PID namespaces are disallowed: spec.hostPID is set to trueHost IPC namespaces are disallowed: spec.hostIPC is set to true	Stel deze waarden in op false, of verwijder de specificatie van de velden.
Geprivilegieerde containers	Privileged [ephemeral\|init\|N/A] containers are disallowed: spec.containers[*].securityContext.privileged is set to true	Stel het juiste securityContext.privileged veld in op falseof verwijder het veld.
Capabilities	Bericht begint met Disallowed capabilities detected	Verwijder de mogelijkheid die wordt weergegeven uit het manifest van de container.
HostPath-volumes	HostPath volumes are forbidden under restricted security policy unless containers mounting them are from allowed images	Verwijder het HostPath-volume en de volume-mount.
Hostpoorten	HostPorts are forbidden under baseline security policy	Verwijder de hostpoortspecificatie uit de problematische container.
SELinux	SELinux type must be one of: undefined/empty, container_t, container_init_t, container_kvm_t, or container_engine_t	Stel het veld van securityContext.seLinuxOptions.type de container in op een van de toegestane waarden.
/proc-koppelingstype	ProcMount must be undefined/nil or 'Default' in spec.containers[*].securityContext.procMount	Stel spec.containers[*].securityContext.procMount in op Default of laat deze ongedefinieerd.
Seccomp	Seccomp profile must not be explicitly set to Unconfined. Allowed values are: undefined/nil, RuntimeDefault, or Localhost	Stel securityContext.seccompProfile.type in voor de pod of de containers op een van de toegestane waarden.
Sysctls	Disallowed sysctl detected. Only baseline Kubernetes pod security standard sysctls are permitted	Verwijder de niet-toegestane sysctls. Zie de Kubernetes-podbeveiligingsstandaardspecificatie voor de specifieke lijst.
Volumetypen (uitsluitend PSS beperkt)	Only the following volume types are allowed under restricted policy: configMap, csi, downwardAPI, emptyDir, ephemeral, persistentVolumeClaim, projected, secret	Verwijder volumes die geen van de toegestane typen zijn.
Escalatie van bevoegdheden (PSS Alleen Beperkt)	Privilege escalation must be set to false under restricted policy	Stel spec.containers[*].securityContext.allowPrivilegeEscalation in op false voor elke container, initContainer en kortstondige container.
Wordt uitgevoerd als niet-root (alleen beperkt tot PSS)	Containers must not run as root user in spec.containers[*].securityContext.runAsNonRoot	Stel spec.containers[*].securityContext.runAsNonRoot in op true voor elke container, initContainer en ephemeralContainer.
Uitvoeren als niet-rootgebruiker (alleen PSS beperkt)	Containers must not run as root user: spec.securityContext.runAsUser is set to 0	Stel securityContext.runAsUser in op een niet-nulwaarde of laat deze ongedefinieerd voor het podniveau en elke container, initContainer en ephemeralContainer.
Seccomp (alleen pss beperkt)	Seccomp profile must be "RuntimeDefault" or "Localhost" under restricted policy	Stel securityContext.seccompProfile.type in voor de pod of de containers op een van de toegestane waarden. Dit verschilt van de basislijn omdat het beperkte beleid geen niet-gedefinieerde waarde toestaat.
Mogelijkheden (alleen PSS Beperkt)	All containers must drop ALL capabilities under restricted policy of Only NET_BIND_SERVICE may be added to capabilities under restricted policy	Alle containers moeten ALL bevoegdheden verwijderen en mogen alleen NET_BIND_SERVICE toevoegen.

Implementatiebeveiligingen inschakelen

Notitie

Als u het niveau Implementatiebeveiligingen Enforce gebruikt, betekent dit dat u zich aanmeldt voor implementaties die worden geblokkeerd en gemuteerd. Overweeg hoe dit beleid kan werken met uw AKS-cluster voordat u dit inschakelt Enforce.

Implementatiebeveiligingen inschakelen op een bestaand cluster

Schakel implementatiebeveiligingen in op een bestaand cluster waarvoor de Azure Policy-invoegtoepassing is ingeschakeld met behulp van de az aks safeguard create opdracht met de --level vlag. Als u waarschuwingen voor niet-naleving wilt ontvangen, stelt u de --level optie in op Warn. Als u alle niet-compatibele implementaties wilt weigeren of dempen, stelt u deze in op Enforce.

az aks safeguards create --resource-group <resource-group-name> --name <cluster-name> --level Enforce 

U kunt implementatiebeveiligingen ook inschakelen met behulp van de --cluster vlag en het opgeven van de clusterresource-id.

az aks safeguards create --cluster <ID> --level Enforce

Als u het niveau Implementatiebeveiligingen van een bestaand cluster wilt bijwerken, voert u de volgende opdracht uit met de nieuwe waarde voor --level.

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn 

Naamruimten uitsluiten

U kunt ook bepaalde naamruimten uitsluiten van implementatiebeveiligingen. Wanneer u een naamruimte uitsluit, wordt de activiteit in die naamruimte niet beïnvloed door waarschuwingen of afdwinging van implementatiebeveiligingen.

Als u bijvoorbeeld de naamruimten wilt uitsluiten en ns1een door spatie gescheiden lijst met naamruimten ns2 met de --excluded-ns vlag wilt gebruiken, zoals wordt weergegeven in het volgende voorbeeld:

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --excluded-ns ns1 ns2 

Beveiligingsstandaarden voor pods inschakelen

Notitie

Azure Kubernetes Service (AKS) maakt standaard gebruik van Privileged Pod Security Standards. Als u wilt terugkeren naar de standaardconfiguratie, stelt u de --pss-level vlag in op Privileged.

Als u Pod Security Standards in Deployment Safeguards wilt inschakelen, gebruikt u de --pss-level vlag om een van de volgende niveaus te selecteren: Baseline, Restrictedof Privileged.

az aks safeguards update --resource-group <resource-group-name> --name <cluster-name> --level Warn --pss-level <Baseline|Restricted|Privileged>

Uw implementatiebeveiligingsversie bijwerken

Implementatiebeveiligingen voldoen aan het AKS-versiebeheerschema voor invoegtoepassingen. Elke nieuwe versie van een Implementatiebeveiliging wordt uitgebracht als een nieuwe secundaire versie in AKS. Deze updates worden gecommuniceerd via de releaseopmerkingen van AKS GitHub en worden weergegeven in de tabel Implementatiebeveiligingsbeleid in onze documentatie.

Raadpleeg de volgende documentatie voor meer informatie over AKS-versiebeheer en -invoegtoepassingen: aks-component-versions en aks-versioning-for-addons.

Naleving tussen clusters controleren

Nadat u uw Kubernetes-manifest hebt geïmplementeerd, ziet u waarschuwingen of een mogelijk denial-bericht in uw CLI of terminal als het cluster niet compatibel is met implementatiebeveiligingen, zoals wordt weergegeven in de volgende voorbeelden:

waarschuwen

$ kubectl apply -f deployment.yaml
Warning: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing
deployment.apps/simple-web created

afdwingen

Met implementatiebeveiligingsmutaties muteert het Enforce niveau uw Kubernetes-resources indien van toepassing. Uw resources van Kubernetes moeten echter nog steeds alle beveiligingsmaatregelen doorstaan om succesvol te worden uitgerold. Als een beveiligingsbeleid mislukt, wordt uw resource geweigerd en wordt deze niet geïmplementeerd.

$ kubectl apply -f deployment.yaml 
Error from server (Forbidden): error when creating "deployment.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [azurepolicy-k8sazurev1antiaffinityrules-ceffa082711831ebffd1] Deployment with 2 replicas should have either podAntiAffinity or topologySpreadConstraints set to avoid disruptions due to nodes crashing

Als uw Kubernetes-resources voldoen aan de toepasselijke mutatiebeveiligingen en aan alle andere beveiligingsvereisten voldoen, worden ze geïmplementeerd, zoals wordt weergegeven in het volgende voorbeeld:

$ kubectl apply -f deployment.yaml
deployment.apps/simple-web created

Naleving controleren in clusters met behulp van het Azure Policy-dashboard

Als u wilt controleren of implementatiebeveiligingen zijn toegepast en om de naleving van uw cluster te controleren, gaat u naar de azure-portalpagina voor uw cluster en selecteert u Beleid en gaat u vervolgens naar Azure Policy.

Selecteer in de lijst met beleidsregels en initiatieven het initiatief dat is gekoppeld aan implementatiebeveiligingen. U ziet een dashboard met de nalevingsstatus in uw AKS-cluster.

Notitie

Als u de naleving in uw AKS-cluster goed wilt beoordelen, moet het Azure Policy-initiatief zijn afgestemd op de resourcegroep van uw cluster.

Implementatiebeveiligingen uitschakelen

Gebruik de delete opdracht om implementatiebeveiligingen op uw cluster uit te schakelen.

az aks safeguards delete --resource-group <resource-group-name> --name <cluster-name>

Veelgestelde vragen

Kan ik mijn eigen mutaties creëren?

Nee Als u een idee hebt voor een beveiliging, opent u een probleem in de GitHub-opslagplaats van AKS en voegt u dit toe [Deployment Safeguards request] aan het begin van de titel.

Kan ik kiezen welke mutaties ik wil in Handhaving?

Nee Implementatiebeveiliging is alles of niets. Zodra u Waarschuwen of Afdwingen inschakelt, zijn alle beveiligingsmaatregelen actief.

Waarom is mijn implementatieresource toegelaten, ook al heeft deze geen aanbevolen procedures gevolgd?

Implementatiebeveiligingen dwingen best practice-standaarden af via Azure Policy-controles en hebben beleidsregels die worden gevalideerd op basis van Kubernetes-resources. Azure Policy breidt Gatekeeper uit om clusteronderdelen te evalueren en af te dwingen. Gatekeeper-handhaving werkt momenteel ook in een fail-open model. Aangezien er geen garantie is dat Gatekeeper op onze netwerkaanroep reageert, zorgen we ervoor dat in dat geval de validatie wordt overgeslagen, zodat de weigering uw implementaties niet blokkeert.

Zie workloadvalidatie in Gatekeeper voor meer informatie.

Volgende stappen

• Meer informatie over aanbevolen procedures voor het uitvoeren van een AKS-cluster.