A fürtök védelme az Azure Kubernetes Service (AKS) pod biztonsági házirendjeinek használatával (előnézet)

Mielőtt elkezdené

• Ez a cikk feltételezi, hogy van egy meglévő AKS-fürtje. Ha AKS-fürtre van szüksége, hozzon létre egyet az Azure CLI, az Azure PowerShell vagy az Azure Portal használatával.
• Telepítenie és konfigurálnia kell az Azure CLI 2.0.61-es vagy újabb verzióját. A verzió azonosításához futtassa a következőt: az --version. Ha telepítenie vagy frissítenie kell, tekintse meg az Azure CLI telepítését.

Az aks-preview Azure CLI-bővítmény telepítése

1. Telepítse az aks-preview bővítményt a az extension add paranccsal.

   az extension add --name aks-preview
   

2. Frissítsen a bővítmény legújabb verziójára a az extension update paranccsal.

   az extension update --name aks-preview
   

A funkciójelző regisztrálása PodSecurityPolicyPreview

1. Regisztrálja a PodSecurityPolicyPreview funkciójelzőt a az feature register paranccsal.

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

   Néhány percig tart, amíg az állapot megjelenik a Regisztrált állapotban.

2. Ellenőrizze a regisztrációs állapotot a az feature show paranccsal.

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

3. Ha az állapot a Regisztrált állapotot tükrözi, frissítse a Microsoft.ContainerService erőforrás-szolgáltató regisztrációját a az provider register paranccsal.

   az provider register --namespace Microsoft.ContainerService
   

Podbiztonsági szabályzatok áttekintése

A Kubernetes-fürtök beléptető vezérlőkkel elfogják az API-kiszolgálóra irányuló kéréseket, amikor létrejön egy erőforrás. A beléptető vezérlő ezután érvényesítheti az erőforrás-kérést egy szabálykészleten, vagy az erőforrást mutációval módosíthatja az üzembehelyezési paramétereket.

PodSecurityPolicy egy olyan beléptető vezérlő, amely ellenőrzi, hogy a pod specifikációja megfelel-e a megadott követelményeknek. Ezek a követelmények korlátozhatják a kiemelt tárolók használatát, bizonyos típusú tárolókhoz való hozzáférést, illetve azt a felhasználót vagy csoportot, amelyként a tároló futhat. Ha olyan erőforrást próbál üzembe helyezni, amelynél a pod specifikációi nem felelnek meg a pod biztonsági szabályzatában ismertetett követelményeknek, a rendszer megtagadja a kérést. Az AKS-fürtben ütemezhető podok szabályozásának képessége megakadályozza a biztonsági rések vagy jogosultságok eszkalálását.

Ha engedélyezi a podbiztonsági szabályzatot egy AKS-fürtben, a rendszer néhány alapértelmezett házirendet alkalmaz. Ezek a szabályzatok beépített felületet biztosítanak annak meghatározásához, hogy mely podok ütemezhetők. Előfordulhat azonban, hogy problémákba ütközik a podok üzembe helyezésekor, amíg meg nem határozza a saját szabályzatait. A javasolt megközelítés a következő:

1. AKS-fürt létrehozása.
2. Saját podbiztonsági szabályzatok definiálása.
3. Engedélyezze a pod biztonsági szabályzat funkcióját.

A pod biztonsági szabályzata és az Azure Policy közötti viselkedésváltozások

Podbiztonsági szabályzat engedélyezése AKS-fürtön

• Engedélyezze a pod biztonsági szabályzatát a az aks update paranccsal.

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

Alapértelmezett AKS-szabályzatok

A pod biztonsági szabályzatának engedélyezésekor az AKS létrehoz egy jogosultsággal ellátott alapértelmezett házirendet. Ne szerkessze vagy távolítsa el az alapértelmezett szabályzatot. Ehelyett hozzon létre saját szabályzatokat, amelyek meghatározzák a szabályozni kívánt beállításokat. Először nézzük meg, hogy ezek az alapértelmezett szabályzatok milyen hatással vannak a podok üzembe helyezésére.

1. Tekintse meg az elérhető szabályzatokat a kubectl get psp paranccsal.

   kubectl get psp
   

   A kimenet a következő példakimenethez hasonlóan fog kinézni:

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

   A rendszer a kiemelt pod biztonsági szabályzatát alkalmazza az AKS-fürt bármely hitelesített felhasználója esetében. Ezt a hozzárendelést ClusterRoles az and ClusterRoleBindings.

2. Keresse meg az alapértelmezett:privileged: kötést a kube-system névtérben a kubectl get rolebindings paranccsal.

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

   Az alábbi tömörített példakimenet azt mutatja, hogy a psp:privileged ClusterRole bármely rendszer:hitelesített felhasználóhoz van rendelve. Ez a képesség alapvető jogosultsági szintet biztosít a saját szabályzatok definiálása nélkül.

   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
   

Fontos tisztában lenni azzal, hogy ezek az alapértelmezett szabályzatok hogyan működnek együtt a podok ütemezésére irányuló felhasználói kérésekkel, mielőtt saját podbiztonsági szabályzatokat hoz létre. A következő néhány szakaszban ütemezünk néhány podot az alapértelmezett szabályzatok működés közbeni megtekintéséhez.

Tesztfelhasználó létrehozása AKS-fürtben

A parancs használatakor a az aks get-credentials rendszer alapértelmezés szerint hozzáadja az AKS-fürt rendszergazdai hitelesítő adatait a kubectl konfigurációhoz. A rendszergazdai felhasználó végrehajtja a pod biztonsági szabályzatainak érvényesítését. Ha Microsoft Entra-integrációt használ az AKS-fürtökhöz, bejelentkezhet egy nem rendszergazdai felhasználó hitelesítő adataival a szabályzatok működés közbeni érvényesítésének megtekintéséhez.

1. Hozzon létre egy psp-aks nevű mintanévteret az erőforrások teszteléséhez a kubectl create namespace parancs használatával.

   kubectl create namespace psp-aks
   

2. Hozzon létre egy nem felhasználó nevű szolgáltatásfiókot a kubectl create serviceaccount parancs használatával.

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

3. Hozzon létre egy RoleBinding-műveletet a nem a felhasználó számára, hogy alapvető műveleteket hajthasson végre a névtérben a kubectl create rolebinding paranccsal.

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

Aliasparancsok létrehozása rendszergazdai és nem rendszergazdai felhasználók számára

A használat során kubectlkét parancssori alias létrehozásával kiemelheti a normál rendszergazdai és a nem rendszergazdai felhasználó közötti különbségeket:

1. A normál rendszergazdai felhasználó kubectl-admin aliasa, amely a psp-aks névtérre terjed ki.
2. Az előző lépésben létrehozott nem felhasználó kubectl-nonadminuser aliasa, amely a psp-aks névtérre terjed ki.

• Hozza létre a két aliast az alábbi parancsokkal.

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

Emelt szintű pod létrehozásának tesztelése

Teszteljük, mi történik, ha egy podot a biztonsági környezettel privileged: trueütemez. Ez a biztonsági környezet eszkalálja a pod jogosultságait. Az alapértelmezett jogosultsági AKS biztonsági szabályzatnak meg kell tagadnia ezt a kérést.

1. Hozzon létre egy elnevezett nginx-privileged.yaml fájlt, és illessze be a következő YAML-jegyzék tartalmát.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

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

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Nem emelt szintű pod létrehozásának tesztelése

Az előző példában a pod specifikációja emelt szintű eszkalációt kért. Ezt a kérést az alapértelmezett jogosultsági pod biztonsági szabályzata elutasítja, ezért a pod nem lesz ütemezve. Próbálja meg futtatni ugyanazt az NGINX-podot a jogosultságeszkalációs kérés nélkül.

1. Hozzon létre egy fájlt, nginx-unprivileged.yaml és illessze be a következő YAML-jegyzék tartalmát.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

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

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Pod létrehozásának tesztelése adott felhasználói környezettel

Az előző példában a tárolórendszerkép automatikusan a gyökér használatával próbálta meg az NGINX-et a 80-s porthoz kötni. Ezt a kérést az alapértelmezett jogosultsági pod biztonsági szabályzata elutasította, ezért a pod nem indul el. Próbáljuk meg futtatni ugyanazt az NGINX-podot egy adott felhasználói környezettel, például runAsUser: 2000.

1. Hozzon létre egy fájlt, nginx-unprivileged-nonroot.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a podot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

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

   Az alábbi példakimenet azt mutatja, hogy a podot nem sikerült ütemezni:

   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: []
   

   Mivel a pod nem éri el az ütemezési szakaszt, a továbblépés előtt nincs törölni kívánt erőforrás.

Egyéni podbiztonsági szabályzat létrehozása

Most, hogy megismerte az alapértelmezett podbiztonsági szabályzatok viselkedését, biztosítsunk módot a nem felhasználó számára a podok sikeres ütemezésére.

Létrehozunk egy szabályzatot, amely elutasítja a kiemelt hozzáférést kérő podokat. Más beállítások, például a runAsUser vagy az engedélyezett kötetek nincsenek explicit módon korlátozva. Az ilyen típusú szabályzat tagadja a kiemelt hozzáférésre vonatkozó kérést, de lehetővé teszi a fürt számára a kért podok futtatását.

1. Hozzon létre egy fájlt, psp-deny-privileged.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a szabályzatot a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

   kubectl apply -f psp-deny-privileged.yaml
   

3. Tekintse meg az elérhető szabályzatokat a kubectl get psp paranccsal.

   kubectl get psp
   

   A következő példakimenetben hasonlítsa össze a psp-deny-privileged házirendet az előző példákban kényszerített alapértelmezett jogosultsági szabályzattal pod létrehozásához. A házirend csak a PRIV eszkaláció használatát tagadja meg. A psp-deny-privileged szabályzathoz nincs korlátozás a felhasználóra vagy csoportra vonatkozóan.

   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            *          
   

Az egyéni pod biztonsági szabályzatának használatának engedélyezése a felhasználói fiók számára

Az előző lépésben létrehozott egy podbiztonsági szabályzatot, amely elutasítja a kiemelt hozzáférést kérő podokat. A szabályzat használatának engedélyezéséhez létre kell hoznia egy szerepkört vagy egy ClusterRole-t. Ezután hozzárendelhet egy szerepkört egy RoleBinding vagy ClusterRoleBinding használatával. Ebben a példában létrehozunk egy ClusterRole-t, amely lehetővé teszi az előző lépésben létrehozott psp-deny-privileged szabályzat használatát.

1. Hozzon létre egy fájlt, psp-deny-privileged-clusterrole.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a ClusterRole-t a kubectl apply paranccsal, és adja meg a YAML-jegyzék nevét.

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

3. Hozzon létre egy fájlt, psp-deny-privileged-clusterrolebinding.yaml és illessze be a következő YAML-jegyzékbe.

   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. Hozza létre a ClusterRoleBinding parancsot, kubectl apply és adja meg a YAML-jegyzék nevét.

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

Nem emelt szintű pod létrehozásának ismételt tesztelése

Az egyéni pod biztonsági szabályzatának alkalmazásával és a felhasználói fiókhoz tartozó kötéssel hozzon létre újra egy nem emelt szintű podot.

Ez a példa bemutatja, hogyan hozhat létre egyéni podbiztonsági szabályzatokat az AKS-fürthöz való hozzáférés meghatározásához különböző felhasználók vagy csoportok számára. Az alapértelmezett AKS-szabályzatok szigorú vezérlőket biztosítanak a podok futtatásához, ezért hozzon létre saját egyéni szabályzatokat a szükséges korlátozások helyes meghatározásához.

1. A jegyzék használatával nginx-privileged.yaml hozza létre a podot a kubectl apply paranccsal.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. Ellenőrizze a pod állapotát a kubectl get pods paranccsal.

   kubectl-nonadminuser get pods
   

   Az alábbi példakimenet azt mutatja, hogy a podot sikeresen ütemezték, és fut:

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

3. Törölje az NGINX nem emelt szintű podot a kubectl delete parancs használatával, és adja meg a YAML-jegyzék nevét.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Az erőforrások eltávolítása

1. Tiltsa le a pod biztonsági szabályzatát a az aks update paranccsal.

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

2. Törölje a ClusterRole és a ClusterRoleBinding parancsot.kubectl delete

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

3. Törölje a ClusterRoleBinding parancsot.kubectl delete

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

4. Törölje a biztonsági szabályzatot parancs használatával kubectl delete , és adja meg a YAML-jegyzék nevét.

   kubectl delete -f psp-deny-privileged.yaml
   

5. Törölje a psp-aks névteret a kubectl delete paranccsal.

   kubectl delete namespace psp-aks
   

Következő lépések

Ez a cikk bemutatta, hogyan hozhat létre podbiztonsági szabályzatot a kiemelt hozzáférés használatának megakadályozása érdekében. A szabályzatok számos funkciót kényszeríthetnek ki, például a kötet típusát vagy a futtató felhasználót. A rendelkezésre álló lehetőségekről további információt a Kubernetes pod biztonsági házirendjének dokumentációja tartalmaz.

A podok hálózati forgalmának korlátozásával kapcsolatos további információkért tekintse meg a podok közötti adatforgalom biztonságossá tételét az AKS-ben található hálózati házirendek használatával.