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

  • Makale

Önemli

Pod güvenlik ilkesi özelliği 1 Ağustos 2023'te kullanım dışı bırakıldı ve AKS 1.25 ve üzeri sürümlerden kaldırıldı.

Azure desteği içinde kalmak için pod güvenlik erişim denetleyicisine veya Azure ilkesine geçmenizi öneririz. Pod Güvenlik Kabulü, tek küme uygulamaları için yerleşik bir ilke çözümüdür. Kurumsal düzeyde ilke arıyorsanız Azure ilkesi daha iyi bir seçimdir.

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

Önemli

AKS önizleme özellikleri self servis ve kabul temelinde kullanılabilir. Önizlemeler "olduğu gibi" ve "kullanılabilir" olarak sağlanır ve hizmet düzeyi sözleşmelerinin ve sınırlı garantinin dışında tutulur. AKS önizlemeleri, müşteri desteği tarafından kısmen en iyi çaba temelinde ele alınmaktadır. Bu nedenle, bu özellikler üretim kullanımı için tasarlanmamıştır. Daha fazla bilgi için aşağıdaki destek makalelerine bakın:

  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

Senaryo Pod güvenlik ilkesi Azure İlkesi
Yükleme Pod güvenlik ilkesi özelliğini etkinleştirme Azure İlkesi Eklentisini Etkinleştirme
İlkeleri dağıtma Pod güvenlik ilkesi kaynağını dağıtma Abonelik veya kaynak grubu kapsamına Azure ilkeleri atayın. Azure İlkesi Eklentisi, Kubernetes kaynak uygulamaları için gereklidir.
Varsayılan ilkeler AKS'de pod güvenlik ilkesi etkinleştirildiğinde, varsayılan Privileged ve Unrestricted ilkeleri uygulanır. Azure İlkesi Eklentisi etkinleştirilerek varsayılan ilke uygulanmaz. Azure İlkesi'da ilkeleri açıkça etkinleştirmeniz gerekir.
İlkeleri kim oluşturabilir ve atayabilir? Küme yöneticisi pod güvenlik ilkesi kaynağı oluşturur Kullanıcıların AKS kümesi kaynak grubunda en düşük 'sahip' veya 'Kaynak İlkesi Katkıda Bulunanı' izinleri olmalıdır. - API aracılığıyla, kullanıcılar AKS kümesi kaynak kapsamında ilke atayabilir. Kullanıcının AKS kümesi kaynağında en az 'sahip' veya 'Kaynak İlkesi Katkıda Bulunanı' izinleri olmalıdır. - Azure portalında ilkeler Yönetim grubu/abonelik/kaynak grubu düzeyinde atanabilir.
İlkeleri yetkilendirme Kullanıcılar ve Hizmet Hesapları, pod güvenlik ilkelerini kullanmak için açık izinler gerektirir. İlkeleri yetkilendirmek için ek atama gerekmez. Azure'da ilkeler atandıktan sonra tüm küme kullanıcıları bu ilkeleri kullanabilir.
İlke uygulanabilirliği Yönetici kullanıcı pod güvenlik ilkelerinin uygulanmasını atlar. Tüm kullanıcılar (yönetici ve yönetici olmayan) aynı ilkeleri görür. Kullanıcılara dayalı özel bir kasa yoktur. İlke uygulaması ad alanı düzeyinde dışlanabilir.
İlke Kapsamı Pod güvenlik ilkeleri ad alanı içinde değil Azure İlkesi tarafından kullanılan kısıtlama şablonları ad alanı olarak kullanılmaz.
Reddet/Denetle/Mutasyon eylemi Pod güvenlik ilkeleri yalnızca reddetme eylemlerini destekler. Mutasyon oluşturma isteklerinde varsayılan değerlerle yapılabilir. Doğrulama, güncelleştirme istekleri sırasında yapılabilir. Azure İlkesi hem denetim hem de reddetme eylemlerini destekler. Mutasyon henüz desteklenmiyor.
Pod güvenlik ilkesi uyumluluğu Pod güvenlik ilkesini etkinleştirmeden önce var olan podların uyumluluğuyla ilgili görünürlük yoktur. Pod güvenlik ilkeleri etkinleştirildikten sonra oluşturulan uyumlu olmayan podlar reddedilir. Azure ilkelerini uygulamadan önce var olan uyumlu olmayan podlar ilke ihlallerinde görünür. İlkeler reddetme etkisiyle ayarlanırsa Azure ilkeleri etkinleştirildikten sonra oluşturulan uyumlu olmayan podlar reddedilir.
Kümede ilkeleri görüntüleme kubectl get psp kubectl get constrainttemplate - Tüm ilkeler döndürülür.
Pod güvenlik ilkesi standardı - Privileged Özellik etkinleştirilirken varsayılan olarak ayrıcalıklı bir pod güvenlik ilkesi kaynağı oluşturulur. Ayrıcalıklı mod herhangi bir kısıtlama anlamına gelir; sonuç olarak Azure İlkesi ataması olmamasıyla eşdeğerdir.
Pod güvenlik ilkesi standardı - Temel/varsayılan Kullanıcı bir pod güvenlik ilkesi temel kaynağı yükler. Azure İlkesi, temel pod güvenlik ilkesine eşlenen yerleşik bir temel girişim sağlar.
Pod güvenlik ilkesi standardı - Kısıtlı Kullanıcı pod güvenlik ilkesi kısıtlanmış bir kaynak yükler. Azure İlkesi, kısıtlı pod güvenlik ilkesine eşlenen yerleşik bir kısıtlı girişim sağlar.

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

Dekont

Gerçek dünya kullanımı için, kendi özel ilkelerinizi tanımlamadan pod güvenlik ilkesini etkinleştirmeyin. Bu makalede, varsayılan ilkelerin pod dağıtımlarını nasıl sınırladiğini görmek için ilk adım olarak pod güvenlik ilkesini etkinleştireceğiz.

  • 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:privilegedClusterRole öğ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

Dekont

Bu makalenin ilk adımında, AKS kümesinde pod güvenlik ilkesi özelliği etkinleştirildi. Önerilen uygulama, pod güvenlik ilkesi özelliğini yalnızca kendi ilkelerinizi tanımladıktan sonra etkinleştirmekti. Bu, pod güvenlik ilkesi özelliğini etkinleştirebileceğiniz aşamadır. Bir veya daha fazla özel ilke tanımlanmıştır ve kullanıcı hesapları bu ilkelerle ilişkilendirilmiştir. Artık pod güvenlik ilkesi özelliğini güvenli bir şekilde etkinleştirebilir ve varsayılan ilkelerin neden olduğu sorunları en aza indirebilirsiniz.

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.