Amankan kluster Anda menggunakan kebijakan keamanan pod di Azure Kubernetes Service (AKS) (pratinjau)

Artikel
08/01/2023

Penting

Fitur kebijakan keamanan pod tidak digunakan lagi pada 1 Agustus 2023 dan dihapus dari AKS versi 1.25 dan yang lebih tinggi.

Sebaiknya Anda bermigrasi ke pengontrol penerimaan keamanan pod atau kebijakan Azure untuk tetap berada dalam dukungan Azure. Penerimaan Keamanan Pod adalah solusi kebijakan bawaan untuk implementasi kluster tunggal. Jika Anda mencari kebijakan tingkat perusahaan, kebijakan Azure adalah pilihan yang lebih baik.

Sebelum Anda mulai

Artikel ini mengasumsikan Anda memiliki kluster AKS yang sudah ada. Jika Anda memerlukan kluster AKS, buat kluster menggunakan Azure CLI, Azure PowerShell, atau portal Azure.
Anda memerlukan Azure CLI versi 2.0.61 atau yang lebih baru terpasang dan terkonfigurasi. Jalankan az --version untuk menemukan versinya. Jika Anda perlu menginstal atau meningkatkan, lihat Menginstal Azure CLI.

Memasang ekstensi `aks-preview` Azure CLI

Penting

Fitur pratinjau AKS tersedia berdasarkan layanan mandiri. Pratinjau disediakan "apa adanya" dan "sebagaimana tersedia," dan mereka dikecualikan dari perjanjian tingkat layanan dan garansi terbatas. Pratinjau AKS sebagian dicakup oleh dukungan pelanggan berdasarkan upaya terbaik. Dengan demikian, fitur-fitur ini tidak dimaksudkan untuk penggunaan produksi. Untuk informasi lebih lanjut, lihat artikel dukungan berikut ini:

Instal ekstensi aks-preview menggunakan az extension add perintah .
```
az extension add --name aks-preview
```
Perbarui ke versi terbaru ekstensi menggunakan az extension update perintah .
```
az extension update --name aks-preview
```

Daftarkan `PodSecurityPolicyPreview` bendera fitur

Daftarkan PodSecurityPolicyPreview bendera fitur menggunakan az feature register perintah .
```
az feature register --namespace "Microsoft.ContainerService" --name "PodSecurityPolicyPreview"
```
Dibutuhkan beberapa menit agar status menampilkan Terdaftar.

Verifikasi status pendaftaran menggunakan az feature show perintah .

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

Saat status mencerminkan Terdaftar, refresh pendaftaran penyedia sumber daya Microsoft.ContainerService menggunakan az provider register perintah .
```
az provider register --namespace Microsoft.ContainerService
```

Gambaran umum kebijakan keamanan pod

Kluster Kubernetes menggunakan pengontrol penerimaan untuk mencegat permintaan ke server API saat sumber daya akan dibuat. Pengontrol penerimaan kemudian dapat memvalidasi permintaan sumber daya terhadap seperangkat aturan, atau memutasi sumber daya untuk mengubah parameter penyebaran.

PodSecurityPolicy adalah pengontrol penerimaan yang memvalidasi spesifikasi pod memenuhi persyaratan yang Anda tentukan. Persyaratan ini dapat membatasi penggunaan kontainer istimewa, akses ke jenis penyimpanan tertentu, atau pengguna atau grup yang dapat dijalankan oleh kontainer. Ketika kamu mencoba untuk menyebarkan resource dengan spesifikasi pod tidak memenuhi persyaratan yang diuraikan dalam kebijakan keamanan pod, maka permintaan ditolak. Kemampuan untuk mengontrol pod apa saja yang dapat dijadwalkan di kluster AKS mencegah beberapa kemungkinan kerentanan keamanan atau eskalasi hak istimewa.

Ketika Anda mengaktifkan kebijakan keamanan pod dalam kluster AKS, beberapa kebijakan default diterapkan. Kebijakan ini memberikan pengalaman di luar kotak untuk menentukan pod apa yang dapat dijadwalkan. Namun, Anda mungkin mengalami masalah saat menyebarkan pod hingga menentukan kebijakan Anda sendiri. Pendekatan yang disarankan adalah untuk:

Buat kluster AKS.
Tentukan kebijakan keamanan pod Anda sendiri.
Aktifkan fitur kebijakan keamanan pod.

Perubahan perilaku antara kebijakan keamanan pod dan Azure Policy

Skenario	Kebijakan keamanan pod	Kebijakan Azure
Penginstalan	Mengaktifkan fitur kebijakan keamanan pod	Aktifkan Add-on Azure Policy
Menyebarkan kebijakan	Menyebarkan sumber daya kebijakan keamanan pod	Tetapkan kebijakan Azure ke cakupan langganan atau grup sumber daya. Add-on Azure Policy diperlukan untuk aplikasi sumber daya Kubernetes.
Kebijakan default	Ketika kebijakan keamanan pod diaktifkan dalam AKS, maka kebijakan Hak istimewa dan Tidak Terbatas default diterapkan.	Tidak ada kebijakan default yang diterapkan dengan mengaktifkan Add-on Azure Policy. Anda harus secara eksplisit mengaktifkan kebijakan dalam Azure Policy.
Siapa yang bisa membuat dan menetapkan kebijakan	Admin kluster membuat sumber daya kebijakan keamanan pod	Pengguna harus memiliki peran minimum 'pemilik' atau izin 'Kontributor Kebijakan Sumber Daya' pada grup sumber daya kluster AKS. - Melalui API, pengguna dapat menetapkan kebijakan di lingkup sumber daya kluster AKS. Pengguna harus memiliki minimum izin 'pemilik' atau 'Kontributor Kebijakan Sumber Daya' pada sumber daya kluster AKS. - Di portal Microsoft Azure, kebijakan dapat ditetapkan di Grup manajemen/langganan/grup sumber daya tingkat.
Mengautorisasi kebijakan	Pengguna dan Akun Layanan memerlukan izin eksplisit untuk menggunakan kebijakan keamanan pod.	Tidak ada tugas tambahan yang diperlukan untuk mengautorisasi kebijakan. Setelah kebijakan ditetapkan di Azure, semua pengguna kluster dapat menggunakan kebijakan ini.
Penerapan kebijakan	Pengguna admin melewati pemberlakuan kebijakan keamanan pod.	Semua pengguna (admin & non-admin) melihat kebijakan yang sama. Tidak ada casing khusus berdasarkan pengguna. Aplikasi kebijakan dapat dikecualikan di tingkat namespace.
Cakupan kebijakan	Kebijakan keamanan pod tidak dinamai	Templat batasan yang digunakan oleh Azure Policy tidak memiliki namespace.
Tindakan Tolak/Audit/Mutasi	Kebijakan keamanan pod hanya mendukung tindakan. Mutasi dapat dilakukan dengan nilai default pada permintaan buat. Validasi dapat dilakukan pada saat permintaan pembaruan.	Azure Policy mendukung tindakan audit & menolak. Mutasi belum didukung.
Kepatuhan kebijakan keamanan pod	Tidak ada visibilitas terhadap kepatuhan pod yang ada sebelum mengaktifkan kebijakan keamanan pod. Pod yang tidak patuh yang dibuat setelah mengaktifkan kebijakan keamanan pod ditolak.	Pod yang tidak patuh yang ada sebelum menerapkan kebijakan Azure akan muncul dalam pelanggaran kebijakan. Pod yang tidak patuh dibuat setelah mengaktifkan kebijakan Azure ditolak jika kebijakan ditetapkan dengan efek tolak.
Cara melihat kebijakan pada kluster	`kubectl get psp`	`kubectl get constrainttemplate` - Semua kebijakan dikembalikan.
Standar kebijakan keamanan pod - Hak Istimewa	Sumber daya kebijakan keamanan pod dengan hak istimewa dibuat secara default saat mengaktifkan fitur tersebut.	Mode istimewa tidak menyiratkan batasan, akibatnya setara dengan tidak memiliki penetapan Azure Policy apa pun.
Standar kebijakan keamanan pod - Garis besar/default	Pengguna menginstal sumber daya garis besar kebijakan keamanan pod.	Azure Policy menyediakan inisiatif garis besar bawaan yang memetakan ke garis besar kebijakan keamanan pod.
Standar kebijakan keamanan pod - Dibatasi	Pengguna menginstal sumber daya terbatas kebijakan keamanan pod.	Azure Policy menyediakan inisiatif terbatas bawaan yang memetakan ke kebijakan keamanan pod terbatas.

Aktifkan kebijakan keamanan pod pada kluster AKS

Catatan

Untuk penggunaan dunia nyata, jangan aktifkan kebijakan keamanan pod hingga Anda menentukan kebijakan kustom Anda sendiri. Dalam artikel ini, kami mengaktifkan kebijakan keamanan pod sebagai langkah pertama untuk melihat bagaimana kebijakan default membatasi penyebaran pod.

Aktifkan kebijakan keamanan pod menggunakan az aks update perintah .

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

Kebijakan AKS default

Ketika kamu mengaktifkan kebijakan keamanan pod, AKS membuat satu kebijakan default bernama privileged. Jangan mengedit atau menghapus kebijakan default. Sebagai gantinya, buat kebijakan Anda sendiri yang menentukan pengaturan yang ingin Anda kontrol. Pertama-tama, mari kita lihat apa kebijakan default ini bagaimana pengaruhnya terhadap penyebaran pod.

Lihat kebijakan yang tersedia menggunakan kubectl get psp perintah .

kubectl get psp

Output Anda akan terlihat mirip dengan contoh output berikut:

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

Kebijakan keamanan pod privileged diterapkan ke semua pengguna yang diautentikasi dalam kluster AKS. Penugasan ini dikendalikan oleh ClusterRoles dan ClusterRoleBindings.

Cari default:privileged: binding di namespace layanan kube-system menggunakan kubectl get rolebindings perintah .

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

Contoh output ringkas berikut menunjukkan psp:privilegedClusterRole ditetapkan ke sistem apa pun:pengguna yang diautentikasi. Kemampuan ini memberikan tingkat hak istimewa dasar tanpa kebijakan Anda sendiri yang didefinisikan.

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

Penting untuk memahami bagaimana kebijakan default ini berinteraksi dengan permintaan pengguna untuk menjadwalkan pod sebelum kamu mulai membuat kebijakan keamanan pod sendiri. Di beberapa bagian berikutnya, kami menjadwalkan beberapa pod untuk melihat kebijakan default yang beraksi.

Membuat pengguna uji di kluster AKS

Saat Anda menggunakan az aks get-credentials perintah , kredensial admin untuk kluster AKS ditambahkan ke konfigurasi Anda kubectl secara default. Pengguna admin melewati pemberlakuan kebijakan keamanan pod. Jika Anda menggunakan integrasi Microsoft Entra untuk kluster AKS, Anda dapat masuk dengan kredensial pengguna non-admin untuk melihat penerapan kebijakan yang sedang berjalan.

Buat contoh namespace bernama psp-aks untuk sumber daya pengujian menggunakan kubectl create namespace perintah .
```
kubectl create namespace psp-aks
```
Buat akun layanan bernama nonadmin-user menggunakan kubectl create serviceaccount perintah .
```
kubectl create serviceaccount --namespace psp-aks nonadmin-user
```

Buat RoleBinding untuk pengguna nonadmin untuk melakukan tindakan dasar di namespace menggunakan kubectl create rolebinding perintah .

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

Membuat perintah alias untuk admin dan pengguna non-admin

Saat menggunakan kubectl, Anda dapat menyoroti perbedaan antara pengguna admin reguler dan pengguna non-admin dengan membuat dua alias baris perintah:

Alias kubectl-admin untuk pengguna admin reguler, yang dilingkupkan ke namespace layanan psp-aks .
Alias kubectl-nonadminuser untuk pengguna nonadmin yang dibuat pada langkah sebelumnya, yang dicakup ke namespace layanan psp-aks.

Buat dua alias menggunakan perintah berikut.

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

Uji pembuatan pod hak istimewa

Mari kita uji apa yang terjadi ketika Anda menjadwalkan pod dengan konteks privileged: truekeamanan . Konteks keamanan ini meningkatkan hak istimewa pod. Kebijakan keamanan AKS hak istimewa default harus menolak permintaan ini.

Buat file bernama nginx-privileged.yaml dan tempelkan konten manifes YAML berikut.

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

Buat pod menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.
```
kubectl-nonadminuser apply -f nginx-privileged.yaml
```
Contoh output berikut menunjukkan pod gagal dijadwalkan:
```
Error from server (Forbidden): error when creating "nginx-privileged.yaml": pods "nginx-privileged" is forbidden: unable to validate against any pod security policy: []
```
Karena pod tidak mencapai tahap penjadwalan, tidak ada sumber daya yang akan dihapus sebelum Anda melanjutkan.

Menguji pembuatan pod yang tidak diistimewakan

Pada contoh sebelumnya, spesifikasi pod meminta eskalasi dengan hak istimewa. Permintaan ini ditolak oleh kebijakan keamanan pod hak istimewa default, sehingga pod gagal dijadwalkan. Mari kita coba menjalankan pod NGINX yang sama tanpa permintaan eskalasi hak istimewa.

Buat file bernama nginx-unprivileged.yaml dan tempelkan konten manifes YAML berikut.

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

Buat pod menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.
```
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
```
Contoh output berikut menunjukkan pod gagal dijadwalkan:
```
Error from server (Forbidden): error when creating "nginx-unprivileged.yaml": pods "nginx-unprivileged" is forbidden: unable to validate against any pod security policy: []
```
Karena pod tidak mencapai tahap penjadwalan, tidak ada sumber daya yang akan dihapus sebelum Anda melanjutkan.

Uji pembuatan pod dengan konteks pengguna tertentu

Dalam contoh sebelumnya, gambar kontainer secara otomatis mencoba menggunakan root untuk mengikat NGINX ke port 80. Permintaan ini ditolak oleh kebijakan keamanan pod hak istimewa default, sehingga pod gagal memulai. Mari kita coba menjalankan pod NGINX yang sama dengan konteks pengguna tertentu, seperti runAsUser: 2000.

Buat file bernama nginx-unprivileged-nonroot.yaml dan tempelkan dalam manifes YAML berikut.

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

Buat pod menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.

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

Contoh output berikut menunjukkan pod gagal dijadwalkan:

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

Karena pod tidak mencapai tahap penjadwalan, tidak ada sumber daya yang akan dihapus sebelum Anda melanjutkan.

Buat kebijakan keamanan pod kustom

Setelah melihat perilaku kebijakan keamanan pod default, mari kita beri jalan bagi nonadmin-user untuk berhasil menjadwalkan pod.

Kami akan membuat kebijakan untuk menolak pod yang meminta akses istimewa. Opsi lain, seperti runAsUser atau volume yang diizinkan, tidak secara eksplisit dibatasi. Jenis kebijakan ini menolak permintaan untuk akses istimewa, tetapi memungkinkan kluster untuk menjalankan pod yang diminta.

Buat file bernama psp-deny-privileged.yaml dan tempelkan dalam manifes YAML berikut.

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:
 - '*'

Buat kebijakan menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.
```
kubectl apply -f psp-deny-privileged.yaml
```

Lihat kebijakan yang tersedia menggunakan kubectl get psp perintah .

kubectl get psp

Dalam contoh output berikut, bandingkan kebijakan psp-deny-privileged dengan kebijakan hak istimewa default yang diberlakukan dalam contoh sebelumnya untuk membuat pod. Hanya penggunaan eskalasi PRIV yang ditolak oleh kebijakan Anda. Tidak ada batasan pada pengguna atau grup untuk kebijakan 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            *

Izinkan akun pengguna untuk menggunakan kebijakan keamanan pod kustom

Pada langkah sebelumnya, kamu membuat kebijakan keamanan pod untuk menolak pod yang meminta akses istimewa. Untuk mengizinkan kebijakan tersebut digunakan, Anda membuat Peran atau ClusterRole. Kemudian, Anda mengaitkan salah satu peran ini menggunakan RoleBinding atau ClusterRoleBinding. Untuk contoh ini, kami akan membuat ClusterRole yang memungkinkan Anda menggunakankebijakan psp-deny-privileged yang dibuat pada langkah sebelumnya.

Buat file bernama psp-deny-privileged-clusterrole.yaml dan tempelkan dalam manifes YAML berikut.

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

Buat ClusterRole menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.
```
kubectl apply -f psp-deny-privileged-clusterrole.yaml
```

Buat file bernama psp-deny-privileged-clusterrolebinding.yaml dan tempelkan dalam manifes YAML berikut.

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

Buat ClusterRoleBinding menggunakan kubectl apply perintah dan tentukan nama manifes YAML Anda.
```
kubectl apply -f psp-deny-privileged-clusterrolebinding.yaml
```

Catatan

Pada langkah pertama artikel ini, fitur kebijakan keamanan pod diaktifkan pada kluster AKS. Praktik yang disarankan hanya mengaktifkan fitur kebijakan keamanan pod setelah kamu mendefinisikan kebijakanmu sendiri. Ini adalah tahap di mana kamu akan mengaktifkan fitur kebijakan keamanan pod. Satu atau beberapa kebijakan kustom telah ditentukan, dan akun pengguna telah dikaitkan dengan kebijakan tersebut. Anda sekarang dapat mengaktifkan fitur kebijakan keamanan pod dengan aman dan meminimalkan masalah yang disebabkan oleh kebijakan default.

Uji lagi pembuatan pod yang tidak diistimewakan

Dengan kebijakan keamanan pod kustom yang diterapkan dan pengikatan bagi akun pengguna untuk menggunakan kebijakan tersebut, mari kita coba buat pod yang tidak berkesempatan lagi.

Contoh ini menunjukkan bagaimana kamu dapat membuat kebijakan keamanan pod kustom untuk menentukan akses ke kluster AKS untuk pengguna atau grup yang berbeda. Kebijakan AKS default memberikan kontrol yang ketat pada pod apa yang dapat dijalankan, sehingga buat kebijakan kustom Anda sendiri untuk kemudian menentukan batasan yang Anda butuhkan dengan benar.

nginx-privileged.yaml Gunakan manifes untuk membuat pod menggunakan kubectl apply perintah .
```
kubectl-nonadminuser apply -f nginx-unprivileged.yaml
```

Periksa status pod menggunakan kubectl get pods perintah .

kubectl-nonadminuser get pods

Contoh output berikut menunjukkan pod berhasil dijadwalkan dan Berjalan:

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

Hapus pod yang tidak memiliki hak istimewa NGINX menggunakan kubectl delete perintah dan tentukan nama manifes YAML Anda.
```
kubectl-nonadminuser delete -f nginx-unprivileged.yaml
```

Membersihkan sumber daya

Nonaktifkan kebijakan keamanan pod menggunakan az aks update perintah .

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

Hapus ClusterRole dan ClusterRoleBinding menggunakan kubectl delete perintah .
```
kubectl delete -f psp-deny-privileged-clusterrole.yaml
```

Hapus ClusterRoleBinding menggunakan kubectl delete perintah .

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

Hapus kebijakan keamanan menggunakan kubectl delete perintah dan tentukan nama manifes YAML Anda.
```
kubectl delete -f psp-deny-privileged.yaml
```
Hapus namespace layanan psp-aks menggunakan kubectl delete perintah .
```
kubectl delete namespace psp-aks
```

Langkah berikutnya

Artikel ini menunjukkan cara membuat kebijakan keamanan pod untuk mencegah penggunaan akses istimewa. Kebijakan dapat memberlakukan banyak fitur, seperti jenis volume atau pengguna RunAs. Untuk informasi selengkapnya tentang opsi yang tersedia, lihat dokumen referensi kebijakan keamanan pod Kubernetes.

Untuk informasi selengkapnya tentang membatasi lalu lintas jaringan pod, lihat Mengamankan lalu lintas antar pod menggunakan kebijakan jaringan di AKS.