Azure Kubernetes Service'teki pod güvenliği ilkelerini kullanarak kümenizin güvenliğini sağlayın (AKS) (ön izleme)

Başlamadan önce

• Bu makalede, mevcut bir AKS kümeniz olduğu varsayılır. AKS kümesine ihtiyacınız varsa Azure CLI, Azure PowerShell veya Azure portalını kullanarak bir küme oluşturun.
• Azure CLI sürüm 2.0.61 veya üzerinin yüklü ve yapılandırılmış olması gerekir. Sürümü bulmak için az --version komutunu çalıştırın. Yüklemeniz veya yükseltmeniz gerekiyorsa bkz . Azure CLI'yi yükleme.

Azure CLI uzantısını aks-preview yükleme

1. komutunu kullanarak aks-preview uzantısını az extension add yükleyin.

   az extension add --name aks-preview
   

2. komutunu kullanarak uzantının en son sürümüne güncelleştirin az extension update .

   az extension update --name aks-preview
   

Özellik bayrağını PodSecurityPolicyPreview kaydetme

1. PodSecurityPolicyPreview komutunu kullanarak özellik bayrağını az feature register kaydedin.

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

   Durumun Kayıtlı olarak gösterilmesi birkaç dakika sürer.

2. komutunu kullanarak az feature show kayıt durumunu doğrulayın.

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

3. Durum Kayıtlı olarak yansıtıldığında, komutunu kullanarak Microsoft.ContainerService kaynak sağlayıcısının kaydını yenileyinaz provider register.

   az provider register --namespace Microsoft.ContainerService
   

Pod güvenlik ilkelerine genel bakış

Kubernetes kümeleri, kaynak oluşturulacakken API sunucusuna yönelik istekleri kesmek için erişim denetleyicilerini kullanır. Erişim denetleyicisi daha sonra kaynak isteğini bir dizi kurala göre doğrulayabilir veya dağıtım parametrelerini değiştirmek için kaynağın sesini kapatabilir .

PodSecurityPolicy , pod belirtimini tanımlı gereksinimlerinizi karşıladığını doğrulayan bir erişim denetleyicisidir. Bu gereksinimler ayrıcalıklı kapsayıcıların kullanımını, belirli depolama türlerine erişimi sınırlandırabilir veya kapsayıcının farklı çalıştırabileceği kullanıcı veya grup olabilir. Pod belirtimlerinin pod güvenlik ilkesinde belirtilen gereksinimleri karşılamadığı bir kaynak dağıtmaya çalıştığınızda istek reddedilir. AKS kümesinde hangi podların zamanlanabilir olduğunu denetleyebilme özelliği bazı olası güvenlik açıklarını veya ayrıcalık yükseltmelerini önler.

AKS kümesinde pod güvenlik ilkesini etkinleştirdiğinizde bazı varsayılan ilkeler uygulanır. Bu ilkeler, hangi podların zamanlanabilir olduğunu tanımlamak için kullanıma açık bir deneyim sağlar. Ancak, kendi ilkelerinizi tanımlayana kadar podlarınızı dağıtırken sorunlarla karşılaşabilirsiniz. Önerilen yaklaşım:

1. AKS kümesi oluşturma.
2. Kendi pod güvenlik ilkelerinizi tanımlayın.
3. Pod güvenlik ilkesi özelliğini etkinleştirin.

Pod güvenlik ilkesi ile Azure İlkesi arasındaki davranış değişiklikleri

AKS kümesinde pod güvenlik ilkesini etkinleştirme

• komutunu kullanarak az aks update pod güvenlik ilkesini etkinleştirin.

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

Varsayılan AKS ilkeleri

Pod güvenlik ilkesini etkinleştirdiğinizde AKS privileged adlı bir varsayılan ilke oluşturur. Varsayılan ilkeyi düzenlemeyin veya kaldırmayın. Bunun yerine, denetlemek istediğiniz ayarları tanımlayan kendi ilkelerinizi oluşturun. İlk olarak bu varsayılan ilkelerin pod dağıtımlarını nasıl etkilediklerine bakalım.

1. komutunu kullanarak kubectl get psp kullanılabilir ilkeleri görüntüleyin.

   kubectl get psp
   

   Çıkışınız aşağıdaki örnek çıkışa benzer olacaktır:

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

   Ayrıcalıklı pod güvenlik ilkesi AKS kümesindeki kimliği doğrulanmış tüm kullanıcılara uygulanır. Bu atama ve ClusterRoleBindingstarafından ClusterRoles denetlendi.

2. komutunu kullanarak kube-system ad alanında default:privileged: bağlamasını kubectl get rolebindings arayın.

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

   Aşağıdaki daraltılmış örnek çıktı, psp:privileged ClusterRole öğesinin tüm sistem:kimliği doğrulanmış kullanıcılara atandığı gösterir. Bu özellik, kendi ilkeleriniz tanımlanmadan temel bir ayrıcalık düzeyi sağlar.

   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
   

Kendi pod güvenlik ilkelerinizi oluşturmaya başlamadan önce bu varsayılan ilkelerin podları zamanlamak için kullanıcı istekleriyle nasıl etkileşim kuracağını anlamanız önemlidir. Sonraki birkaç bölümde, varsayılan ilkelerin nasıl çalıştığını görmek için bazı podlar zamanlıyoruz.

AKS kümesinde test kullanıcısı oluşturma

komutunu kullandığınızda az aks get-credentials , AKS kümesinin yönetici kimlik bilgileri varsayılan olarak yapılandırmanıza kubectl eklenir. Yönetici kullanıcı pod güvenlik ilkelerinin uygulanmasını atlar. AKS kümeleriniz için Microsoft Entra tümleştirmesi kullanıyorsanız, ilkelerin uygulanıp uygulanmadığını görmek için yönetici olmayan bir kullanıcının kimlik bilgileriyle oturum açabilirsiniz.

1. komutunu kullanarak kubectl create namespace test kaynakları için psp-aks adlı örnek bir ad alanı oluşturun.

   kubectl create namespace psp-aks
   

2. komutunu kullanarak kubectl create serviceaccount nonadmin-user adlı bir hizmet hesabı oluşturun.

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

3. komutunu kullanarak kubectl create rolebinding ad alanında temel eylemleri gerçekleştirmek üzere yönetici olmayan kullanıcı için bir RoleBinding oluşturun.

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

Yönetici ve yönetici olmayan kullanıcılar için diğer ad komutları oluşturma

kullanırken kubectl, iki komut satırı diğer adı oluşturarak normal yönetici kullanıcı ile yönetici olmayan kullanıcı arasındaki farkları vurgulayabilirsiniz:

1. Kapsamı psp-aks ad alanı olan normal yönetici kullanıcısının kubectl-admin diğer adı.
2. Psp-aks ad alanı kapsamına sahip olan önceki adımda oluşturulan yönetici olmayan kullanıcı için kubectl-nonadminuser diğer adı.

• Aşağıdaki komutları kullanarak iki diğer adı oluşturun.

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

Ayrıcalıklı pod oluşturmayı test edin

Şimdi güvenlik bağlamı privileged: trueile bir pod zamanladığınızda ne olacağını test edelim. Bu güvenlik bağlamı pod'un ayrıcalıklarını yükseltir. Varsayılan ayrıcalık AKS güvenlik ilkesi bu isteği reddetmelidir.

1. adlı nginx-privileged.yaml bir dosya oluşturun ve aşağıdaki YAML bildiriminin içeriğine yapıştırın.

   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. komutunu kullanarak pod oluşturun kubectl apply ve YAML bildiriminizin adını belirtin.

   kubectl-nonadminuser apply -f nginx-privileged.yaml
   

   Aşağıdaki örnek çıktıda pod zamanlanamadı:

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

   Pod zamanlama aşamasına ulaşmadığından, devam etmeden önce silinecek kaynak yoktur.

Ayrıcalıksız pod oluşturmayı test edin

Önceki örnekte pod belirtimi ayrıcalıklı yükseltme istedi. Bu istek varsayılan ayrıcalık pod güvenlik ilkesi tarafından reddedilir, bu nedenle pod zamanlanamaz. Ayrıcalık yükseltme isteği olmadan aynı NGINX podunu çalıştırmayı deneyelim.

1. adlı nginx-unprivileged.yaml bir dosya oluşturun ve aşağıdaki YAML bildiriminin içeriğine yapıştırın.

   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. komutunu kullanarak pod oluşturun kubectl apply ve YAML bildiriminizin adını belirtin.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

   Aşağıdaki örnek çıktıda pod zamanlanamadı:

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

   Pod zamanlama aşamasına ulaşmadığından, devam etmeden önce silinecek kaynak yoktur.

Belirli bir kullanıcı bağlamıyla pod oluşturmayı test edin

Önceki örnekte, kapsayıcı görüntüsü NGINX'i 80 numaralı bağlantı noktasına bağlamak için otomatik olarak kök kullanmayı denedi. Bu istek varsayılan ayrıcalık pod güvenlik ilkesi tarafından reddedildi, bu nedenle pod başlatılamıyor. Aynı NGINX podunu gibi runAsUser: 2000belirli bir kullanıcı bağlamıyla çalıştırmayı deneyelim.

1. adlı nginx-unprivileged-nonroot.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimine yapıştırın.

   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. komutunu kullanarak pod oluşturun kubectl apply ve YAML bildiriminizin adını belirtin.

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

   Aşağıdaki örnek çıktıda pod zamanlanamadı:

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

   Pod zamanlama aşamasına ulaşmadığından, devam etmeden önce silinecek kaynak yoktur.

Özel pod güvenlik ilkesi oluşturma

Varsayılan pod güvenlik ilkelerinin davranışını gördüğünüze göre, kullanıcı olmayan kullanıcının podları başarıyla zamanlaması için bir yol sağlayalım.

Ayrıcalıklı erişim isteyen podları reddetmek için bir ilke oluşturacağız. runAsUser veya izin verilen birimler gibi diğer seçenekler açıkça kısıtlanmamıştır. Bu tür bir ilke ayrıcalıklı erişim isteğini reddeder, ancak kümenin istenen podları çalıştırmasına izin verir.

1. adlı psp-deny-privileged.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimine yapıştırın.

   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. komutunu kullanarak ilkeyi kubectl apply oluşturun ve YAML bildiriminizin adını belirtin.

   kubectl apply -f psp-deny-privileged.yaml
   

3. komutunu kullanarak kubectl get psp kullanılabilir ilkeleri görüntüleyin.

   kubectl get psp
   

   Aşağıdaki örnek çıktıda psp-deny-privileged ilkesini bir pod oluşturmak için önceki örneklerde zorunlu kılınan varsayılan ayrıcalık ilkesiyle karşılaştırın. Yalnızca PRIV yükseltme kullanımı ilkeniz tarafından reddedilir. Psp-deny-privileged ilkesi için kullanıcı veya grup üzerinde herhangi bir kısıtlama yoktur.

   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            *          
   

Kullanıcı hesabının özel pod güvenlik ilkesini kullanmasına izin ver

Önceki adımda, ayrıcalıklı erişim isteyen podları reddetmek için bir pod güvenlik ilkesi oluşturdunuz. İlkenin kullanılmasına izin vermek için bir Rol veya ClusterRole oluşturursunuz. Ardından, rolebinding veya ClusterRoleBinding kullanarak bu rollerden birini ilişkilendirirsiniz. Bu örnekte, önceki adımda oluşturulan psp-deny-privileged ilkesini kullanmanıza olanak tanıyan bir ClusterRole oluşturacağız.

1. adlı psp-deny-privileged-clusterrole.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimine yapıştırın.

   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. komutunu kullanarak ClusterRole'u kubectl apply oluşturun ve YAML bildiriminizin adını belirtin.

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

3. adlı psp-deny-privileged-clusterrolebinding.yaml bir dosya oluşturun ve aşağıdaki YAML bildirimine yapıştırın.

   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. komutunu kullanarak ClusterRoleBinding'i kubectl apply oluşturun ve YAML bildiriminizin adını belirtin.

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

Ayrıcalıksız pod oluşturmayı yeniden test edin

Özel pod güvenlik ilkeniz uygulandığında ve kullanıcı hesabının ilkeyi kullanması için bir bağlamayla, ayrıcalıksız bir pod oluşturmayı yeniden deneyelim.

Bu örnekte, farklı kullanıcılar veya gruplar için AKS kümesine erişimi tanımlamak üzere özel pod güvenlik ilkelerini nasıl oluşturabileceğiniz gösterilmektedir. Varsayılan AKS ilkeleri, podların çalıştırabilecekleri konusunda sıkı denetimler sağlar, bu nedenle ihtiyacınız olan kısıtlamaları doğru şekilde tanımlamak için kendi özel ilkelerinizi oluşturun.

1. nginx-privileged.yaml komutunu kullanarak pod oluşturmak için bildirimini kubectl apply kullanın.

   kubectl-nonadminuser apply -f nginx-unprivileged.yaml
   

2. komutunu kullanarak kubectl get pods podun durumunu denetleyin.

   kubectl-nonadminuser get pods
   

   Aşağıdaki örnek çıktı podunun başarıyla zamanlandığını ve Çalışıyor olduğunu gösterir:

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

3. komutunu kullanarak NGINX ayrıcalıksız podunu kubectl delete silin ve YAML bildiriminizin adını belirtin.

   kubectl-nonadminuser delete -f nginx-unprivileged.yaml
   

Kaynakları temizleme

1. komutunu kullanarak az aks update pod güvenlik ilkesini devre dışı bırakın.

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

2. komutunu kullanarak ClusterRole ve ClusterRoleBinding'i kubectl delete silin.

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

3. komutunu kullanarak ClusterRoleBinding'i kubectl delete silin.

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

4. komutunu kullanarak kubectl delete güvenlik ilkesini silin ve YAML bildiriminizin adını belirtin.

   kubectl delete -f psp-deny-privileged.yaml
   

5. komutunu kullanarak psp-aks ad alanını kubectl delete silin.

   kubectl delete namespace psp-aks
   

Sonraki adımlar

Bu makalede, ayrıcalıklı erişimin kullanılmasını önlemek için pod güvenlik ilkesinin nasıl oluşturulacağı gösterilmiştir. İlkeler birim türü veya RunAs kullanıcısı gibi birçok özelliği zorunlu kılabilir. Kullanılabilir seçenekler hakkında daha fazla bilgi için bkz . Kubernetes pod güvenlik ilkesi başvuru belgeleri.

Pod ağ trafiğini sınırlama hakkında daha fazla bilgi için bkz . AKS'de ağ ilkelerini kullanarak podlar arasındaki trafiğin güvenliğini sağlama.