Aanbevolen procedures voor podbeveiliging in Azure Kubernetes Service (AKS)
Wanneer u toepassingen ontwikkelt en uitvoert in Azure Kubernetes Service (AKS), is de beveiliging van uw pods een belangrijke overweging. Uw toepassingen moeten zijn ontworpen voor het principe van minimaal aantal vereiste bevoegdheden. Het beveiligen van persoonlijke gegevens is voor klanten erg erg. U wilt geen referenties zoals database-verbindingsreeks s, sleutels of geheimen en certificaten die beschikbaar zijn voor de buitenwereld, waar een aanvaller kan profiteren van deze geheimen voor schadelijke doeleinden. Voeg ze niet toe aan uw code of sluit ze in uw containerinstallatiekopieën in. Deze aanpak zou een risico vormen voor blootstelling en de mogelijkheid om deze referenties te roteren beperken, omdat de containerinstallatiekopieën opnieuw moeten worden opgebouwd.
Dit artikel met aanbevolen procedures is gericht op het beveiligen van pods in AKS. U leert het volgende:
- Podbeveiligingscontext gebruiken om de toegang tot processen en services of escalatie van bevoegdheden te beperken
- Verifiëren met andere Azure-resources met behulp van Microsoft Entra Workload-ID
- Referenties aanvragen en ophalen uit een digitale kluis, zoals Azure Key Vault
U kunt ook de aanbevolen procedures voor clusterbeveiliging en voor containerinstallatiekopieën beheren lezen.
Toegang tot resources voor pods beveiligen
Aanbevolen procedures : als u wilt uitvoeren als een andere gebruiker of groep en de toegang tot de onderliggende knooppuntprocessen en -services wilt beperken, definieert u instellingen voor de beveiligingscontext voor pods. Wijs het minste aantal vereiste bevoegdheden toe.
Om uw toepassingen correct uit te voeren, moeten pods worden uitgevoerd als een gedefinieerde gebruiker of groep en niet als root. Met het securityContext voor een pod of container kunt u instellingen definiëren, zoals runAsUser of fsGroup , om de juiste machtigingen te gebruiken. Wijs alleen de vereiste gebruikers- of groepsmachtigingen toe en gebruik de beveiligingscontext niet als een middel om extra machtigingen aan te nemen. De runAsUser, escalatie van bevoegdheden en andere instellingen voor Linux-mogelijkheden zijn alleen beschikbaar op Linux-knooppunten en -pods.
Wanneer u als een niet-hoofdgebruiker uitvoert, kunnen containers niet worden verbonden met de bevoegde poorten onder 1024. In dit scenario kan Kubernetes Services worden gebruikt om het feit dat een app wordt uitgevoerd op een bepaalde poort te vermommen.
Een beveiligingscontext voor pods kan ook aanvullende mogelijkheden of machtigingen definiëren voor toegang tot processen en services. De volgende algemene beveiligingscontextdefinities kunnen worden ingesteld:
- allowPrivilegeEscalation definieert of de pod hoofdbevoegdheden kan aannemen. Ontwerp uw toepassingen zodat deze instelling altijd is ingesteld op false.
- Met Linux-mogelijkheden heeft de pod toegang tot onderliggende knooppuntprocessen. Zorg ervoor dat u deze mogelijkheden toewijst. Wijs het minste aantal benodigde bevoegdheden toe. Zie Linux-mogelijkheden voor meer informatie.
- SELinux-labels is een Linux-kernelbeveiligingsmodule waarmee u toegangsbeleid kunt definiëren voor services, processen en bestandssysteemtoegang. Wijs opnieuw het minste aantal benodigde bevoegdheden toe. Zie SELinux-opties in Kubernetes voor meer informatie
In het volgende voorbeeld van het YAML-manifest voor pods worden beveiligingscontextinstellingen ingesteld om te definiëren:
- Pod wordt uitgevoerd als gebruikers-id 1000 en onderdeel van groeps-id 2000
- Kan geen bevoegdheden escaleren om te gebruiken
root - Hiermee kunnen Linux-mogelijkheden toegang krijgen tot netwerkinterfaces en de realtime klok van de host (hardware)
apiVersion: v1
kind: Pod
metadata:
name: security-context-demo
spec:
securityContext:
fsGroup: 2000
containers:
- name: security-context-demo
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
securityContext:
runAsUser: 1000
allowPrivilegeEscalation: false
capabilities:
add: ["NET_ADMIN", "SYS_TIME"]
Werk samen met uw clusteroperator om te bepalen welke beveiligingscontextinstellingen u nodig hebt. Probeer uw toepassingen te ontwerpen om extra machtigingen te minimaliseren en toegang te krijgen tot de pod. Er zijn extra beveiligingsfuncties om de toegang te beperken met behulp van AppArmor en seccomp (beveiligde computing) die kunnen worden geïmplementeerd door clusteroperators. Zie Beveiligde containertoegang tot resources voor meer informatie.
Referentieblootstelling beperken
Richtlijnen voor aanbevolen procedures : definieer geen referenties in uw toepassingscode. Gebruik beheerde identiteiten voor Azure-resources om uw pod toegang te geven tot andere resources. Een digitale kluis, zoals Azure Key Vault, moet ook worden gebruikt om digitale sleutels en referenties op te slaan en op te halen. Door pods beheerde identiteiten zijn alleen bedoeld voor gebruik met Linux-pods en containerinstallatiekopieën.
Om het risico te beperken dat referenties worden weergegeven in uw toepassingscode, vermijdt u het gebruik van vaste of gedeelde referenties. Referenties of sleutels mogen niet rechtstreeks in uw code worden opgenomen. Als deze referenties beschikbaar zijn, moet de toepassing worden bijgewerkt en opnieuw worden geïmplementeerd. Een betere benadering is om pods hun eigen identiteit en manier te geven om zichzelf te verifiëren, of om automatisch referenties op te halen uit een digitale kluis.
Een Microsoft Entra Workload-ID gebruiken
Een workloadidentiteit is een identiteit die wordt gebruikt door een toepassing die wordt uitgevoerd op een pod die zichzelf kan verifiëren bij andere Azure-services die deze ondersteunen, zoals Storage of SQL. Het kan worden geïntegreerd met de mogelijkheden die systeemeigen zijn voor Kubernetes om te federeren met externe id-providers. In dit beveiligingsmodel fungeert het AKS-cluster als tokenverlener. Microsoft Entra ID maakt gebruik van OpenID Verbinding maken om sleutels voor openbare ondertekening te detecteren en de echtheid van het serviceaccounttoken te verifiëren voordat het wordt uitgewisseld voor een Microsoft Entra-token. Uw workload kan een serviceaccounttoken uitwisselen dat is geprojecteerd naar het volume voor een Microsoft Entra-token met behulp van de Azure Identity-clientbibliotheek met behulp van de Azure SDK of de Microsoft Authentication Library (MSAL).
Azure Key Vault gebruiken met het stuurprogramma Secrets Store CSI
Met behulp van de Microsoft Entra Workload-ID maakt verificatie mogelijk voor ondersteunende Azure-services. Voor uw eigen services of toepassingen zonder beheerde identiteiten voor Azure-resources kunt u zich nog steeds verifiëren met behulp van referenties of sleutels. Een digitale kluis kan worden gebruikt om deze geheime inhoud op te slaan.
Wanneer toepassingen een referentie nodig hebben, communiceren ze met de digitale kluis, halen ze de meest recente geheime inhoud op en maken ze verbinding met de vereiste service. Azure Key Vault kan deze digitale kluis zijn. De vereenvoudigde werkstroom voor het ophalen van een referentie uit Azure Key Vault met behulp van door pod beheerde identiteiten wordt weergegeven in het volgende diagram:
Met Key Vault slaat u geheimen op en roteert u deze regelmatig, zoals referenties, opslagaccountsleutels of certificaten. U kunt Azure Key Vault integreren met een AKS-cluster met behulp van de Azure Key Vault-provider voor het CSI-stuurprogramma Secrets Store. Met het stuurprogramma Secrets Store CSI kan het AKS-cluster systeemeigen geheime inhoud ophalen uit Key Vault en deze veilig verstrekken aan de aanvragende pod. Werk samen met de clusteroperator om het stuurprogramma Secrets Store CSI te implementeren op AKS-werkknooppunten. U kunt een Microsoft Entra Workload-ID gebruiken om toegang tot Key Vault aan te vragen en de geheime inhoud op te halen die nodig is via het stuurprogramma Secrets Store CSI.
Volgende stappen
Dit artikel is gericht op het beveiligen van uw pods. Raadpleeg de volgende artikelen om een aantal van deze gebieden te implementeren: