Dela via

Säkra ditt kluster med poddsäkerhetspolicyer i Azure Kubernetes Service (AKS) (förhandsversion)

  • Artikel

Viktigt!

Funktionen för poddsäkerhetsprinciper blev inaktuell den 1 augusti 2023 och togs bort från AKS version 1.25 och senare.

Vi rekommenderar att du migrerar till poddsäkerhetsantagningskontrollanten eller Azure-principen för att hålla dig inom Azure Support. Pod Security Admission är en inbyggd principlösning för implementeringar av enskilda kluster. Om du letar efter en princip i företagsklass är Azure-principen ett bättre val.

Innan du börjar

  • Den här artikeln förutsätter att du har ett befintligt AKS-kluster. Om du behöver ett AKS-kluster skapar du ett med Hjälp av Azure CLI, Azure PowerShell eller Azure Portal.
  • Du behöver Azure CLI version 2.0.61 eller senare installerad och konfigurerad. Kör az --version för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa installera Azure CLI.

Installera Azure CLI-tillägget aks-preview

Viktigt!

AKS-förhandsversionsfunktioner är tillgängliga via självbetjäning och anmäl dig. Förhandsversioner tillhandahålls "som är" och "som tillgängliga", och de undantas från serviceavtalen och den begränsade garantin. AKS-förhandsversioner omfattas delvis av kundsupport på bästa sätt. Därför är dessa funktioner inte avsedda för produktionsanvändning. Mer information finns i följande supportartiklar:

  1. Installera aks-preview-tillägget med kommandot az extension add .

    az extension add --name aks-preview

  2. Uppdatera till den senaste versionen av tillägget med kommandot az extension update .

    az extension update --name aks-preview

Registrera funktionsflaggan PodSecurityPolicyPreview

  1. Registrera funktionsflaggan PodSecurityPolicyPreview az feature register med kommandot .

    az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

    Det tar några minuter för statusen att visa Registrerad.

  2. Kontrollera registreringsstatusen az feature show med kommandot .

    az feature show --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"

  3. När statusen visar Registrerad uppdaterar du registreringen av resursprovidern Microsoft.ContainerService med hjälp av az provider register kommandot .

    az provider register --namespace Microsoft.ContainerService

Översikt över poddsäkerhetsprinciper

Kubernetes-kluster använder antagningskontrollanter för att avlyssna begäranden till API-servern när en resurs ska skapas. Antagningskontrollanten kan sedan verifiera resursbegäran mot en uppsättning regler eller mutera resursen för att ändra distributionsparametrarna.

PodSecurityPolicy är en antagningskontrollant som verifierar att en poddspecifikation uppfyller dina definierade krav. Dessa krav kan begränsa användningen av privilegierade containrar, åtkomst till vissa typer av lagring eller användaren eller gruppen som containern kan köra som. När du försöker distribuera en resurs där poddspecifikationerna inte uppfyller kraven som beskrivs i poddsäkerhetsprincipen nekas begäran. Den här möjligheten att styra vilka poddar som kan schemaläggas i AKS-klustret förhindrar vissa möjliga säkerhetsrisker eller behörighetseskaleringar.

När du aktiverar poddsäkerhetsprinciper i ett AKS-kluster tillämpas vissa standardprinciper. Dessa principer ger en out-of-the-box-upplevelse för att definiera vilka poddar som kan schemaläggas. Du kan dock stöta på problem med att distribuera dina poddar tills du definierar dina egna principer. Den rekommenderade metoden är att:

  1. Skapa ett AKS-kluster.
  2. Definiera dina egna säkerhetsprinciper för poddar.
  3. Aktivera funktionen för poddsäkerhetsprinciper.

Beteendeändringar mellan poddsäkerhetsprincip och Azure Policy

Scenario Säkerhetsprincip för poddar Azure Policy
Installation Aktivera funktion för poddsäkerhetsprinciper Aktivera Azure Policy-tillägg
Distribuera principer Distribuera resurs för poddsäkerhetsprinciper Tilldela Azure-principer till prenumerationen eller resursgruppens omfång. Azure Policy-tillägget krävs för Kubernetes-resursprogram.
Standardprinciper När poddsäkerhetsprincipen är aktiverad i AKS tillämpas standardprinciperna Privileged och Unrestricted. Inga standardprinciper tillämpas genom att aktivera Azure Policy-tillägget. Du måste uttryckligen aktivera principer i Azure Policy.
Vem kan skapa och tilldela principer Klusteradministratör skapar en resurs för poddsäkerhetsprinciper Användare måste ha en minsta roll som "ägare" eller "Resursprincipdeltagare" för AKS-klusterresursgruppen. – Via API:et kan användare tilldela principer i AKS-klusterresursomfånget. Användaren bör ha minst behörigheten "ägare" eller "Resursprincipdeltagare" för AKS-klusterresursen. – I Azure Portal kan principer tilldelas på nivån Hanteringsgrupp/prenumeration/resursgrupp.
Auktorisera principer Användare och tjänstkonton kräver explicita behörigheter för att använda poddsäkerhetsprinciper. Ingen ytterligare tilldelning krävs för att auktorisera principer. När principer har tilldelats i Azure kan alla klusteranvändare använda dessa principer.
Princip tillämplighet Administratörsanvändaren kringgår tillämpningen av poddsäkerhetsprinciper. Alla användare (administratör och icke-administratör) ser samma principer. Det finns inget särskilt hölje baserat på användare. Principprogram kan undantas på namnområdesnivå.
Policyomfång Poddsäkerhetsprinciper namnges inte Villkorsmallar som används av Azure Policy är inte namnrymder.
Neka/granska/mutationsåtgärd Poddsäkerhetsprinciper stöder endast neka-åtgärder. Mutation kan göras med standardvärden för att skapa begäranden. Verifiering kan göras under uppdateringsbegäranden. Azure Policy stöder båda gransknings- och neka-åtgärderna. Mutation stöds ännu inte.
Efterlevnad av poddsäkerhetsprinciper Det finns ingen insyn i efterlevnaden av poddar som fanns innan du aktiverar poddsäkerhetsprincipen. Icke-kompatibla poddar som skapats efter aktivering av poddsäkerhetsprinciper nekas. Icke-kompatibla poddar som fanns innan Azure-principer tillämpades skulle visas i principöverträdelser. Icke-kompatibla poddar som skapats efter aktivering av Azure-principer nekas om principer anges med en neka-effekt.
Visa principer i klustret kubectl get psp kubectl get constrainttemplate - Alla principer returneras.
Standard för poddsäkerhetsprincip – Privilegierad En privilegierad säkerhetsprincipresurs för poddar skapas som standard när funktionen aktiveras. Privilegierat läge innebär ingen begränsning, vilket innebär att det motsvarar att inte ha någon Azure Policy-tilldelning.
Standard för poddsäkerhetsprincip – baslinje/standard Användaren installerar en baslinjeresurs för poddsäkerhetsprinciper. Azure Policy tillhandahåller ett inbyggt baslinjeinitiativ som mappar till säkerhetsprincipen för baslinjepodden.
Standard för poddsäkerhetsprincip – Begränsad Användaren installerar en resurs med begränsad poddsäkerhetsprincip. Azure Policy tillhandahåller ett inbyggt initiativ för begränsad åtkomst som mappar till den begränsade poddsäkerhetsprincipen.

Aktivera poddsäkerhetsprincip i ett AKS-kluster

Kommentar

För verklig användning aktiverar du inte poddsäkerhetsprincipen förrän du har definierat dina egna anpassade principer. I den här artikeln aktiverar vi poddsäkerhetsprincip som det första steget för att se hur standardprinciperna begränsar podddistributioner.

  • Aktivera poddsäkerhetsprincipen med kommandot az aks update .

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --enable-pod-security-policy

Standardprinciper för AKS

När du aktiverar poddsäkerhetsprincip skapar AKS en standardprincip med namnet privileged. Redigera eller ta inte bort standardprincipen. Skapa i stället dina egna principer som definierar de inställningar som du vill styra. Låt oss först titta på vad dessa standardprinciper är hur de påverkar podddistributioner.

  1. Visa tillgängliga principer med kommandot kubectl get psp .

    kubectl get psp

    Dina utdata ser ut ungefär som i följande exempelutdata:

    NAME         PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *     configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

    Säkerhetsprincipen för privilegierade poddar tillämpas på alla autentiserade användare i AKS-klustret. Den här tilldelningen styrs av ClusterRoles och ClusterRoleBindings.

  2. Sök efter standard:privileged: bindning i kube-system-namnområdet med kommandot kubectl get rolebindings .

    kubectl get rolebindings default:privileged -n kube-system -o yaml

    Följande komprimerade exempelutdata visar att psp:privileged ClusterRole har tilldelats alla system:autentiserade användare. Den här möjligheten ger en grundläggande behörighetsnivå utan att dina egna principer definieras.

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  [...]
  name: default:privileged
  [...]
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp:privileged
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

Det är viktigt att förstå hur dessa standardprinciper interagerar med användarbegäranden för att schemalägga poddar innan du börjar skapa egna säkerhetsprinciper för poddar. I de kommande avsnitten schemalägger vi några poddar för att se standardprinciperna i praktiken.

Skapa en testanvändare i ett AKS-kluster

När du använder az aks get-credentials kommandot läggs administratörsautentiseringsuppgifterna för AKS-klustret till i konfigurationen kubectl som standard. Administratörsanvändaren kringgår tillämpningen av poddsäkerhetsprinciper. Om du använder Microsoft Entra-integrering för dina AKS-kluster kan du logga in med autentiseringsuppgifterna för en icke-administratörsanvändare för att se hur principer tillämpas.

  1. Skapa ett exempelnamnområde med namnet psp-aks för testresurser med kommandot kubectl create namespace .

    kubectl create namespace psp-aks

  2. Skapa ett tjänstkonto med namnet nonadmin-user med kommandot kubectl create serviceaccount .

    kubectl create serviceaccount --namespace psp-aks nonadmin-user

  3. Skapa ett RoleBinding för icke-admin-användaren för att utföra grundläggande åtgärder i namnområdet med kommandot kubectl create rolebinding .

    kubectl create rolebinding \
    --namespace psp-aks \
    psp-aks-editor \
    --clusterrole=edit \
    --serviceaccount=psp-aks:nonadmin-user

Skapa aliaskommandon för administratörs- och icke-administratörsanvändare

När du använder kubectlkan du markera skillnaderna mellan den vanliga administratörsanvändaren och användaren som inte är administratör genom att skapa två kommandoradsalias:

  1. Kubectl-admin-aliaset för den vanliga administratörsanvändaren, som är begränsad till psp-aks-namnområdet.
  2. Aliaset kubectl-nonadminuser för den icke-användare som skapades i föregående steg, som är begränsat till psp-aks-namnområdet .

  • Skapa de två aliasen med hjälp av följande kommandon.

    alias kubectl-admin='kubectl --namespace psp-aks'
alias kubectl-nonadminuser='kubectl --as=system:serviceaccount:psp-aks:nonadmin-user --namespace psp-aks'

Testa skapandet av en privilegierad podd

Nu ska vi testa vad som händer när du schemalägger en podd med säkerhetskontexten privileged: trueför . Den här säkerhetskontexten eskalerar poddens behörigheter. AkS-säkerhetsprincipen för standardprivilegier bör neka den här begäran.

  1. Skapa en fil med namnet nginx-privileged.yaml och klistra in innehållet i följande YAML-manifest.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-privileged
spec:
  containers:
    - name: nginx-privileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        privileged: true

  2. Skapa podden med kubectl apply kommandot och ange namnet på YAML-manifestet.

    kubectl-nonadminuser apply -f nginx-privileged.yaml

    Följande exempelutdata visar att podden inte kunde schemaläggas:

    Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []

    Eftersom podden inte når schemaläggningssteget finns det inga resurser att ta bort innan du går vidare.

Testa skapandet av en oprivilegierad podd

I föregående exempel begärde poddspecifikationen privilegierad eskalering. Den här begäran nekas av standardprincipen för säkerhetsprincipen för privilegierade poddar, så podden kan inte schemaläggas. Nu ska vi prova att köra samma NGINX-podd utan begäran om behörighetseskalering.

  1. Skapa en fil med namnet nginx-unprivileged.yaml och klistra in innehållet i följande YAML-manifest.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine

  2. Skapa podden med kubectl apply kommandot och ange namnet på YAML-manifestet.

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

    Följande exempelutdata visar att podden inte kunde schemaläggas:

    Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []

    Eftersom podden inte når schemaläggningssteget finns det inga resurser att ta bort innan du går vidare.

Testa skapandet av en podd med en specifik användarkontext

I föregående exempel försökte containeravbildningen automatiskt använda roten för att binda NGINX till port 80. Den här begäran nekades av standardprincipen för säkerhet för privilegierade poddar, så podden startar inte. Nu ska vi prova att köra samma NGINX-podd med en specifik användarkontext, till exempel runAsUser: 2000.

  1. Skapa en fil med namnet nginx-unprivileged-nonroot.yaml och klistra in följande YAML-manifest.

    apiVersion: v1
kind: Pod
metadata:
  name: nginx-unprivileged-nonroot
spec:
  containers:
    - name: nginx-unprivileged
      image: mcr.microsoft.com/oss/nginx/nginx:1.14.2-alpine
      securityContext:
        runAsUser: 2000

  2. Skapa podden med kubectl apply kommandot och ange namnet på YAML-manifestet.

    kubectl-nonadminuser apply -f nginx-unprivileged-nonroot.yaml

    Följande exempelutdata visar att podden inte kunde schemaläggas:

    Error from server (Forbidden): error when creating "nginx-unprivileged-nonroot.yaml": pods "nginx-unprivileged-nonroot" is forbidden: unable to validate against any pod security policy: []

    Eftersom podden inte når schemaläggningssteget finns det inga resurser att ta bort innan du går vidare.

Skapa en anpassad säkerhetsprincip för poddar

Nu när du har sett beteendet för standardprinciperna för poddar ska vi tillhandahålla ett sätt för icke-användare att schemalägga poddar.

Vi skapar en princip för att avvisa poddar som begär privilegierad åtkomst. Andra alternativ, till exempel runAsUser eller tillåtna volymer, är inte uttryckligen begränsade. Den här typen av princip nekar en begäran om privilegierad åtkomst, men tillåter att klustret kör de begärda poddarna.

  1. Skapa en fil med namnet psp-deny-privileged.yaml och klistra in följande YAML-manifest.

    apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp-deny-privileged
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  runAsUser:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
 - '*'

  2. Skapa principen med kommandot kubectl apply och ange namnet på ditt YAML-manifest.

    kubectl apply -f psp-deny-privileged.yaml

  3. Visa tillgängliga principer med kommandot kubectl get psp .

    kubectl get psp

    I följande exempelutdata jämför du principen psp-deny-privileged med standardprincipen för privilegier som tillämpades i föregående exempel för att skapa en podd. Endast användningen av PRIV-eskalering nekas av din princip. Det finns inga begränsningar för användaren eller gruppen för principen psp-deny-privileged .

    NAME                  PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES
privileged            true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *
psp-deny-privileged   false          RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *

Tillåt användarkonto att använda den anpassade poddsäkerhetsprincipen

I föregående steg skapade du en säkerhetsprincip för poddar för att avvisa poddar som begär privilegierad åtkomst. Om du vill tillåta att principen används skapar du en roll eller en ClusterRole. Sedan associerar du en av dessa roller med hjälp av ett RoleBinding eller ClusterRoleBinding. I det här exemplet skapar vi en ClusterRole som gör att du kan använda principen psp-deny-privileged som skapades i föregående steg.

  1. Skapa en fil med namnet psp-deny-privileged-clusterrole.yaml och klistra in följande YAML-manifest.

    kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: psp-deny-privileged-clusterrole
rules:
- apiGroups:
  - extensions
   resources:
  - podsecuritypolicies
   resourceNames:
  - psp-deny-privileged
   verbs:
  - use

  2. Skapa ClusterRole med kommandot kubectl apply och ange namnet på DITT YAML-manifest.

    kubectl apply -f psp-deny-privileged-clusterrole.yaml

  3. Skapa en fil med namnet psp-deny-privileged-clusterrolebinding.yaml och klistra in följande YAML-manifest.

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: psp-deny-privileged-clusterrolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: psp-deny-privileged-clusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts

  4. Skapa ClusterRoleBinding med kommandot kubectl apply och ange namnet på YAML-manifestet.

    kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml

Kommentar

I det första steget i den här artikeln aktiverades funktionen för poddsäkerhetsprinciper i AKS-klustret. Den rekommenderade metoden var att endast aktivera funktionen för poddsäkerhetsprinciper när du har definierat dina egna principer. Det här är den fas där du aktiverar funktionen för poddsäkerhetsprinciper. En eller flera anpassade principer har definierats och användarkonton har associerats med dessa principer. Nu kan du på ett säkert sätt aktivera funktionen för poddsäkerhetsprinciper och minimera problem som orsakas av standardprinciperna.

Testa skapandet av en oprivilegierad podd igen

Med din anpassade poddsäkerhetsprincip tillämpad och en bindning för användarkontot att använda principen ska vi försöka skapa en oprivilegierad podd igen.

Det här exemplet visar hur du kan skapa anpassade säkerhetsprinciper för poddar för att definiera åtkomst till AKS-klustret för olika användare eller grupper. AkS-standardprinciperna ger strikta kontroller för vilka poddar som kan köras, så skapa egna anpassade principer för att sedan korrekt definiera de begränsningar du behöver.

  1. Använd manifestet nginx-privileged.yaml för att skapa podden med kommandot kubectl apply .

    kubectl-nonadminuser apply -f nginx-unprivileged.yaml

  2. Kontrollera statusen för podden med kommandot kubectl get pods .

    kubectl-nonadminuser get pods

    Följande exempelutdata visar att podden har schemalagts och körs:

    NAME                 READY   STATUS    RESTARTS   AGE
nginx-unprivileged   1/1     Running   0          7m14s

  3. Ta bort den Oprivilegierade NGINX-podden med kommandot kubectl delete och ange namnet på YAML-manifestet.

    kubectl-nonadminuser delete -f nginx-unprivileged.yaml

Rensa resurser

  1. Inaktivera poddsäkerhetsprincip med az aks update kommandot .

    az aks update \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --disable-pod-security-policy

  2. Ta bort ClusterRole och ClusterRoleBinding med kommandot kubectl delete .

    kubectl delete -f psp-deny-privileged-clusterrole.yaml

  3. Ta bort ClusterRoleBinding med kommandot kubectl delete .

    kubectl delete -f psp-deny-privileged-clusterrolebinding.yaml

  4. Ta bort säkerhetsprincipen med kommandot kubectl delete och ange namnet på DITT YAML-manifest.

    kubectl delete -f psp-deny-privileged.yaml

  5. Ta bort psp-aks-namnområdet med kommandot kubectl delete .

    kubectl delete namespace psp-aks

Nästa steg

Den här artikeln visar hur du skapar en säkerhetsprincip för poddar för att förhindra användning av privilegierad åtkomst. Principer kan framtvinga många funktioner, till exempel typ av volym eller RunAs-användare. Mer information om tillgängliga alternativ finns i referensdokumenten för Kubernetes-poddens säkerhetsprincip.

Mer information om hur du begränsar poddnätverkstrafiken finns i Skydda trafik mellan poddar med hjälp av nätverksprinciper i AKS.