Best practices voor podbeveiliging in Azure Kubernetes Service (AKS)

Bij het ontwikkelen en uitvoeren van toepassingen in Azure Kubernetes Service (AKS) is de beveiliging van uw pods een belangrijke overweging. Uw toepassingen moeten worden ontworpen voor het principe van het minste aantal vereiste bevoegdheden. Het beveiligen van persoonlijke gegevens is een top-of-mind voor klanten. U wilt niet dat referenties, zoals databaseverbindingsreeksen, sleutels of geheimen en certificaten, worden blootgesteld aan de buitenwereld waar een aanvaller kan profiteren van deze geheimen voor schadelijke doeleinden. Voeg ze niet toe aan uw code of sluit ze niet in uw containerafbeeldingen in. Deze aanpak zou een risico vormen voor blootstelling en de mogelijkheid om deze referenties te roteren beperken omdat de containerafbeeldingen opnieuw moeten worden opgebouwd.

Dit artikel met best practices is gericht op het beveiligen van pods in AKS. In deze zelfstudie leert u procedures om het volgende te doen:

U kunt ook de best practices voor clusterbeveiliging en voor het beheer van containerafbeeldingen lezen.

Toegang tot resources voor pods beveiligen

Richtlijnen voor best practice: 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 podbeveiligingscontext. Wijs het minste aantal vereiste bevoegdheden toe.

Pods moeten worden uitgevoerd als een gedefinieerde gebruiker of groep en niet als root om uw toepassingen correct uit te voeren. Met de voor een pod of container kunt u instellingen zoals securityContext runAsUser of fsGroup definiëren om de juiste machtigingen te nemen. Wijs alleen de vereiste gebruikers- of groepsmachtigingen toe en gebruik de beveiligingscontext niet als een manier om extra machtigingen aan te nemen. De instellingen voor runAsUser, escalatie van bevoegdheden en andere mogelijkheden voor Linux zijn alleen beschikbaar op Linux-knooppunten en -pods.

Wanneer u als een niet-hoofdgebruiker wordt uitgevoerd, kunnen containers geen binding maken met de bevoegde poorten onder 1024. In dit scenario kan Kubernetes Services worden gebruikt om ervoor te zorgen dat een app op een bepaalde poort wordt uitgevoerd.

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 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 toegang tot bestandssystemen. Wijs opnieuw het minste aantal benodigde bevoegdheden toe. Zie SELinux-opties in Kubernetes voor meer informatie

In het volgende voorbeeld worden in het YAML-manifest van pods beveiligingscontextinstellingen ingesteld om het volgende te definiëren:

• Pod wordt uitgevoerd als gebruikers-id 1000 en als onderdeel van groeps-id 2000
• Kan de bevoegdheden voor gebruik niet escaleren root
• Biedt Linux-mogelijkheden om toegang te krijgen tot netwerkinterfaces en de realtime klok (hardware) van de host

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 de 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 die vereist is. Er zijn aanvullende beveiligingsfuncties om de toegang te beperken met behulp van AppArmor en seccomp (secure computing) die kunnen worden geïmplementeerd door clusteroperators. Zie Beveiligde containertoegang tot resources voor meer informatie.

Referentieblootstelling beperken

Richtlijnen voor best practice: 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 voor het opslaan en ophalen van digitale sleutels en referenties. Door pods beheerde identiteiten zijn alleen bedoeld voor gebruik met Linux-pods en containerafbeeldingen.

Om het risico te beperken dat referenties in uw toepassingscode worden blootgesteld, vermijdt u het gebruik van vaste of gedeelde referenties. Referenties of sleutels mogen niet rechtstreeks in uw code worden opgenomen. Als deze referenties worden blootgesteld, 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.

Upstream-projecten van Azure Container Compute gebruiken

Aan de volgende gekoppelde AKS open source projecten kunt u automatisch pods verifiëren of referenties en sleutels aanvragen bij een digitale kluis. Deze projecten worden onderhouden door het Upstream-team van Azure Container Compute en maken deel uit van een bredere lijst met projecten die beschikbaar zijn voor gebruik.

• Azure Active Directory Pod-identiteit
• Azure Key Vault Provider for Secrets Store CSI-stuurprogramma

Door pods beheerde identiteiten gebruiken

Met een beheerde identiteit voor Azure-resources kan een pod zichzelf verifiëren bij Azure-services die dit ondersteunen, zoals Storage of SQL. Aan de pod wordt een Azure-identiteit toegewezen waarmee ze zich kunnen verifiëren bij Azure Active Directory ontvangen van een digitaal token. Dit digitale token kan worden gepresenteerd aan andere Azure-services die controleren of de pod is gemachtigd om toegang te krijgen tot de service en de vereiste acties uit te voeren. Deze aanpak betekent bijvoorbeeld dat er geen geheimen vereist zijn voor databaseverbindingsreeksen. De vereenvoudigde werkstroom voor een door pod beheerde identiteit wordt weergegeven in het volgende diagram:

Met een beheerde identiteit hoeft uw toepassingscode geen referenties op te nemen voor toegang tot een service, zoals Azure Storage. Omdat elke pod wordt geverifieerd met een eigen identiteit, kunt u de toegang controleren en controleren. Als uw toepassing verbinding maakt met andere Azure-services, gebruikt u beheerde identiteiten om het hergebruik van referenties en het risico op blootstelling te beperken.

Zie Configure an AKS cluster to use pod managed identities and with your applications (Een AKS-cluster configureren voor het gebruik van door pods beheerde identiteiten en met uw toepassingen) voor meer informatie over podidentiteiten

Gebruik Azure Key Vault secrets store CSI-stuurprogramma

Met behulp van het pod-identiteitsproject kunt u verificatie uitvoeren tegen 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 vervolgens 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 door pods beheerde identiteiten wordt weergegeven in het volgende diagram:

Met Key Vault kunt u geheimen zoals referenties, opslagaccountsleutels of certificaten regelmatig opslaan en roteren. U kunt deze Azure Key Vault integreren met een AKS-cluster met behulp van de Azure Key Vault-provider voor het stuurprogramma Secrets Store CSI. Met het stuurprogramma Secrets Store CSI kan het AKS-cluster systeemeigen geheime inhoud ophalen uit Key Vault en veilig alleen aan de aanvragende pod leveren. Werk samen met uw clusteroperator om het stuurprogramma Secrets Store CSI te implementeren op AKS-werkknooppunten. U kunt een door pod beheerde identiteit gebruiken om toegang aan te vragen tot Key Vault 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. Zie de volgende artikelen voor het implementeren van een aantal van deze gebieden:

• Beheerde identiteiten gebruiken voor Azure-resources met AKS
• Azure Key Vault integreren met AKS