Edit This Page

Pod Security Policy

Pod Security Policies (kebijakan keamanan Pod) memungkinkan otorisasi secara detil dari pembuatan dan pembaruan Pod.

• Apa itu Pod Security Policy?
• Mengaktifkan Pod Security Policy
• Mengizinkan Kebijakan
• Urutan Kebijakan
• Contoh
• Referensi Kebijakan

Apa itu Pod Security Policy?

Pod Security Policy adalah sebuah sumber daya pada tingkat klaster yang mengatur aspek-aspek spesifikasi Pod yang sensitif terhadap keamanan. Objek-objek PodSecurityPolicy mendefinisikan sebuah kumpulan kondisi yang harus dijalankan oleh Pod untuk dapat diterima oleh sistem, dan juga sebagai nilai-nilai bawaan untuk kolom-kolom yang bersangkutan. Mereka memungkinkan administrator untuk mengatur hal-hal berikut:

Mengaktifkan Pod Security Policy

Pengaturan Pod Security Policy diimplementasi sebagai sebuah opsi (tapi direkomendasikan untuk digunakan) dari admission controller. PodSecurityPolicy dilaksanakan dengan mengaktifkan admission controller-nya, tetapi melakukan hal ini tanpa mengizinkan kebijakan apapun akan menghalangi Pod apapun untuk dibuat di dalam klaster.

Sejak API dari Pod Security Policy (policy/v1beta1/podsecuritypolicy) diaktifkan secara independen dari admission controller, untuk klaster-klaster yang sudah ada direkomendasikan untuk menambahkan dan mengizinkan kebijakan yang bersangkutan sebelum mengaktifkan admission controller tersebut.

Mengizinkan Kebijakan

Saat sebuah sumber daya PodSecurityPolicy dibuat, ia tidak melakukan apa-apa. Untuk menggunakannya, Service Account dari pengguna yang memintanya atau target Pod-nya harus diizinkan terlebih dahulu untuk menggunakan kebijakan tersebut, dengan membolehkan kata kerja use terhadap kebijakan tersebut.

Kebanyakan Pod Kubernetes tidak dibuat secara langsung oleh pengguna. Sebagai gantinya, mereka biasanya dibuat secara tidak langsung sebagai bagian dari sebuah Deployment, ReplicaSet, atau pengontrol yang sudah ditemplat lainnya melalui Controller Manager. Memberikan akses untuk pengontrol terhadap kebijakan tersebut akan mengizinkan akses untuk semua Pod yang dibuat oleh pengontrol tersebut, sehingga metode yang lebih baik untuk mengizinkan kebijakan adalah dengan memberikan akses pada Service Account milik Pod (lihat contohnya).

Melalui RBAC

RBAC adalah mode otorisasi standar Kubernetes, dan dapat digunakan dengan mudah untuk mengotorisasi penggunaan kebijakan-kebijakan.

Pertama-tama, sebuah Role atau ClusterRole perlu memberikan akses pada kata kerja use terhadap kebijakan-kebijakan yang diinginkan. rules yang digunakan untuk memberikan akses tersebut terlihat seperti berikut:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <role name>
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - <list of policies to authorize>

Kemudian, Role atau ClusterRole tersebut diikat ke pengguna-pengguna yang diberikan otoritas.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <binding name>
roleRef:
  kind: ClusterRole
  name: <role name>
  apiGroup: rbac.authorization.k8s.io
subjects:
# Mengotorisasi ServiceAccount spesifik
- kind: ServiceAccount
  name: <authorized service account name>
  namespace: <authorized pod namespace>
# Mengotorisasi User spesifik (tidak direkomendasikan)
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: <authorized user name>

Jika sebuah RoleBinding (bukan ClusterRoleBinding) digunakan, maka ia hanya akan memberi akses penggunaan untuk Pod-Pod yang dijalankan pada Namespace yang sama dengan RoleBinding tersebut. Hal ini dapat dipasangkan dengan grup sistem untuk memberi akses pada semua Pod yang berjalan di Namespace tersebut:

# Mengotorisasi semua ServiceAccount di dalam sebuah Namespace
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
# Atau secara ekuivalen, semua pengguna yang telah terotentikasi pada sebuah Namespace
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:authenticated

Untuk lebih banyak contoh pengikatan RBAC, lihat Contoh Role Binding. Untuk contoh lengkap untuk mengotorisasi sebuah PodSecurityPolicy, lihat di bawah.

Mengatasi Masalah

• Controller Manager harus dijalankan terhadap port API yang telah diamankan, dan tidak boleh memiliki izin superuser, atau semua permintaan akan melewati modul-modul otentikasi dan otorisasi, semua objek PodSecurityPolicy tidak akan diizinkan, dan semua pengguna dapat membuat Container-container yang privileged. Untuk lebih detil tentang mengkonfigurasi otorisasi Controller Manager, lihat Controller Roles.

Urutan Kebijakan

Sebagai tambahan terhadap membatasi pembuatan dan pembaruan Pod, Pod Security Policy dapat digunakan juga untuk menyediakan nilai-nilai bawaan untuk banyak kolom yang dikontrol olehnya. Saat banyak kebijakan tersedia, pengatur Pod Security Policy memilih kebijakan-kebijakan berdasarkan kriteria berikut:

1. PodSecurityPolicy yang mengizinkan Pod apa adanya, tanpa mengganti nilai-nilai bawaan atau memutasi Pod tersebut, akan lebih dipilih. Urutan PodSecurityPolicy yang tidak mengubah Pod ini tidak dipermasalahkan.
2. Jika Pod-nya harus diberi nilai bawaan atau dimutasi, maka PodSecurityPolicy pertama (diurutkan berdasarkan namanya) untuk mengizinkan Pod tersebut akan dipilih.

Catatan: Saat operasi pembaruan (saat ini mutasi terhadap spesifikasi Pod tidak diizinkan) hanya PodSecurityPolicy yang tidak mengubah Pod yang akan digunakan untuk melakukan validasi terhadap Pod tersebut.

Contoh

_Contoh ini mengasumsikan kamu telah memiliki klaster yang berjalan dengan admission controller PodSecurityPolicy diaktifkan, dan kamu mempunyai akses admin._

Persiapan

Mempersiapkan sebuah Namespace dan ServiceAccount untuk digunakan pada contoh ini. Kita akan menggunakan ServiceAccount ini untuk meniru sebuah pengguna bukan admin.

kubectl create namespace psp-example
kubectl create serviceaccount -n psp-example fake-user
kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user

Untuk memperjelas kita bertindak sebagai pengguna yang mana dan mempersingkat ketikan, kita akan membuat 2 alias:

alias kubectl-admin='kubectl -n psp-example'
alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'

Membuat sebuah kebijakan dan sebuah Pod

Beri definisi objek contoh PodSecurityPolicy dalam sebuah berkas. Ini adalah kebijakan yang mencegah pembuatan Pod-Pod yang privileged.

policy/example-psp.yaml
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: example spec: privileged: false # Jangan izinkan Pod-Pod yang _privileged_! # Sisanya isi kolom-kolom yang dibutuhkan seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAny volumes: - '*'

Dan buatlah PodSecurityPolicy tersebut dengan kubectl:

kubectl-admin create -f example-psp.yaml

Sekarang, sebagai pengguna bukan admin, cobalah membuat Pod sederhana:

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name:      pause
spec:
  containers:
    - name:  pause
      image: k8s.gcr.io/pause
EOF
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []

Apa yang terjadi? Walaupun PodSecurityPolicy tersebut telah dibuat, ServiceAccount dari Pod tersebut maupun fake-user tidak memikiki izin untuk menggunakan kebijakan tersebut:

kubectl-user auth can-i use podsecuritypolicy/example
no

Membuat RoleBinding untuk memberikan fake-user akses terhadap kata kerja use pada kebijakan contoh kita:

Catatan: Ini bukan cara yang direkomendasikan! Lihat bagian selanjutnya untuk cara yang lebih baik.

kubectl-admin create role psp:unprivileged \
    --verb=use \
    --resource=podsecuritypolicy \
    --resource-name=example
role "psp:unprivileged" created

kubectl-admin create rolebinding fake-user:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created

kubectl-user auth can-i use podsecuritypolicy/example
yes

Sekarang, ulangi membuat Pod tersebut

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name:      pause
spec:
  containers:
    - name:  pause
      image: k8s.gcr.io/pause
EOF
pod "pause" created

Bekerja seperti yang diharapkan! Tapi percobaan apapun untuk membuat Pod yang privileged seharusnya masih ditolak:

kubectl-user create -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
  name:      privileged
spec:
  containers:
    - name:  pause
      image: k8s.gcr.io/pause
      securityContext:
        privileged: true
EOF
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

Hapus Pod tersebut sebelum melanjutkan:

kubectl-user delete pod pause

Menjalankan Pod lainnya

Mari coba lagi, dengan cara yang sedikit berbeda:

kubectl-user run pause --image=k8s.gcr.io/pause
deployment "pause" created

kubectl-user get pods
No resources found.

kubectl-user get events | head -n 2
LASTSEEN   FIRSTSEEN   COUNT     NAME              KIND         SUBOBJECT                TYPE      REASON                  SOURCE                                  MESSAGE
1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request

Apa yang terjadi? Kita telah mengikat Role psp:unprivileged untuk fake-user kita, kenapa kita mendapatkan kesalahan Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request? Jawabannya berada pada sumbernya - replicaset-controller. Fake-user berhasil membuat Deployment tersebut (yang berhasil membuat sebuah ReplicaSet), tetapi saat ReplicaSet tersebut akan membuat Pod, ia tidak terotorisasi untuk menggunakan PodSecurityPolicy contoh tersebut.

Untuk memperbaikinya, ikatlah Role psp:unprivileged pada ServiceAccount Pod tersebut. Pada kasus ini (karena kita tidak menspesifikasikannya) ServiceAccount-nya adalah default:

kubectl-admin create rolebinding default:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:default
rolebinding "default:psp:unprivileged" created

Sekarang, jika kamu memberi waktu ReplicaSet-nya untuk mencoba kembali, pengatur ReplicaSet tersebut seharusnya akan berhasil membuat Pod tersebut.

kubectl-user get pods --watch
NAME                    READY     STATUS    RESTARTS   AGE
pause-7774d79b5-qrgcb   0/1       Pending   0         1s
pause-7774d79b5-qrgcb   0/1       Pending   0         1s
pause-7774d79b5-qrgcb   0/1       ContainerCreating   0         1s
pause-7774d79b5-qrgcb   1/1       Running   0         2s

Membersihkan

Hapus Namespace tersebut untuk membersihkan sebagian besar sumber daya yang digunakan dalam contoh ini:

kubectl-admin delete ns psp-example
namespace "psp-example" deleted

Perlu diperhatikan bahwa sumber daya PodSecurityPolicy tidak diberi Namespace, dan harus dibersihkan secara terpisah:

kubectl-admin delete psp example
podsecuritypolicy "example" deleted

Contoh-contoh Kebijakan

Berikut adalah kebijakan dengan batasan paling sedikit yang dapat kamu buat, ekuivalen dengan tidak menggunakan admission controller Pod Security Policy:

policy/privileged-psp.yaml

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: privileged annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' spec: privileged: true allowPrivilegeEscalation: true allowedCapabilities: - '*' volumes: - '*' hostNetwork: true hostPorts: - min: 0 max: 65535 hostIPC: true hostPID: true runAsUser: rule: 'RunAsAny' seLinux: rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' fsGroup: rule: 'RunAsAny'

Berikut adalah sebuah contoh kebijakan yang restriktif yang mengharuskan pengguna-pengguna untuk berjalan sebagai pengguna yang unprivileged, memblokir kemungkinan eskalasi menjadi root, dan mengharuskan penggunaan beberapa mekanisme keamanan.

policy/restricted-psp.yaml

apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Dibutuhkan untuk menghindari eskalasi ke _root_. allowPrivilegeEscalation: false # Hal ini berlebihan dengan _non-root_ + melarang eskalasi _privilege_, # tetapi kita dapat menyediakannya untuk _defense in depth_ requiredDropCapabilities: - ALL # Izinkan tipe-tipe volume inti. volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' # Berasumsi bahwa persistentVolumes yang disetel oleh admin klaster aman untuk digunakan. - 'persistentVolumeClaim' hostNetwork: false hostIPC: false hostPID: false runAsUser: # Mengharuskan container untuk berjalan tanpa hak sebagai _root_. rule: 'MustRunAsNonRoot' seLinux: # Kebijakan ini mengasumsikan bahwa node-node menggunakan AppArmor daripada SELinux. rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: # Larang menambahkan grup _root_. - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: # Larang menambahkan grup _root_. - min: 1 max: 65535 readOnlyRootFilesystem: false

Referensi Kebijakan

Privileged

Privileged - menentukan bila Container manapun di dalam sebuah Pod dapat mengaktifkan mode privileged. Secara bawaan, sebuah Container tidak diizinkan untuk mengakses perangkat apapun pada host-nya, tapi sebuah Container yang “privileged” akan diberikan akses untuk semua perangkat pada host-nya. Hal ini mengizinkan hampir semua akses yang sama dengan proses yang berjalan pada host kepada Container tersebut. Hal ini berfungsi untuk Container-container yang ingin menggunakan kemampuan Linux seperti memanipulasi network stack atau mengakses perangkat-perangkat. determines if any container in a pod can enable privileged mode.

Namespace Host

HostPID - Mengatur jika Container-container pada Pod dapat berbagi namespace process ID pada host. Catatlah bahwa saat dipasangkan dengan ptrace, hal ini dapat digunakan untuk eskalasi privilege di luar kontainer (ptrace secara bawaan tidak diizinkan).

HostIPC - Mengatur jika container-container pada Pod dapat berbagi namespace IPC pada host.

HostNetwork - Mengatur jika Pod dapat menggunakan namespace jaringan pada host. Melakukan hal ini akan memberikan Pod akses pada perangkat loopback, service yang sedang listening pada localhost, dan dapat digunakan untuk mengintai aktivitas jaringan pada Pod-Pod lain pada Node yang sama.

HostPorts - Memberikan daftar putih dari berbagai port yang diizinkan pada namespace jaringan pada host. Hal ini didefinisikan sebagai sebuah daftar HostPortRange, dengan min(inklusif) dan max(inklusif). Nilai bawaannya adalah tidak ada host port yang diizinkan.

AllowedHostPaths - Lihat Volume dan file systems.

Volume dan file system

Volume - Menyediakan sebuah daftar putih dari tipe-tipe Volume yang diizinkan. Nilai-nilai yang diizinkan sesuai dengan sumber Volume yang didefinisikan saat membuat sebuah Volume. Untuk daftar lengkap tipe-tipe Volume, lihat tipe-tipe Volume. Sebagai tambahan, * dapat digunakan untuk mengizinkan semua tipe Volume.

Kumpulan Volume-volume minimal yang direkomendasikan untuk PodSecurityPolicy baru adalah sebagai berikut:

• configMap
• downwardAPI
• emptyDir
• persistentVolumeClaim
• secret
• projected

Peringatan: PodSecurityPolicy tidak membatasi tipe-tipe objek PersistentVolume yang dapat direferensikan oleh PersistentVolumeClaim. Hanya pengguna-pengguna yang dipercaya yang boleh diberikan izin untuk membuat objek-objek PersistentVolume.

FSGroup - Mengatur grup tambahan yang dipasang ke beberapa volume.

• MustRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Menggunakan semua nilai minimum dari range yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semua range.
• MayRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Mengizinkan FSGroups dibiarkan kosong tanpa memberikan nilai bawaan. Memvalidasikan terhadap semua range jika nilai FSGroups disetel.
• RunAsAny - Tidak ada nilai bawaan yang diberikan. Mengizinkan ID fsGroup apapun untuk digunakan.

AllowedHostPaths - Memperinci sebuah daftar putih dari host path yang diizinkan untuk digunakan oleh volume-volume hostPath. Sebuah daftar kosong berarti tidak ada pembatasan pada host path yang digunakan. Hal ini didefinisikan sebagai sebuah daftar objek-objek dengan sebuah kolom pathPrefix, yang mengizinkan volume-volume hostPath untuk menambatkan sebuah path yang dimulai dengan sebuah prefiks yang diizinkan, dan sebuah kolom readOnly yang menunjukkan bahwa ia harus ditambatkan sebagai read-only. Misalnya:

allowedHostPaths:
  # Hal ini mengizinkan "/foo", "/foo/", "/foo/bar" dll., tetapi
  # melarang "/fool", "/etc/foo" dll.
  # "/foo/../" tidak sah.
  - pathPrefix: "/foo"
    readOnly: true # Izinkan hanya tambatan _read-only_

Peringatan:

Ada banyak cara bagi sebuah Container dengan akses yang tidak dibatasi terhadap host filesystem-nya untuk dapat melakukan eskalasi privilege, termasuk membaca data dari Container-container lain, dan menyalahgunakan kredensial dari service-service sistem, misalnya Kubelet.

Direktori volume hostPath yang dapat ditulis mengizinkan container-container untuk menulis ke filesystem melalui cara-cara yang membiarkan mereka melintasi host filesystem di luar pathPrefix yang bersangkutan. readOnly: true, tersedia pada Kubernetes 1.11 ke atas, harus digunakan pada semua allowedHostPaths untuk secara efektif membatasi akses terhadap pathPrefix yang diperinci.

ReadOnlyRootFilesystem - Mengharuskan container-container berjalan dengan sebuah root filesystem yang bersifat read-only (yaitu, tanpa lapisan yang dapat ditulis)

Driver-driver Flexvolume

Hal ini memperinci sebuah daftar putih dari driver-driver Flexvolume yang diizinkan untuk digunakan oleh Flexvolume. Sebuah daftar kosong atau nil berarti tidak ada batasan terhadap driver-driver tersebut. Pastikan kolom volumes berisi tipe volumenya; Jika tidak, tidak ada driver Flexvolume yang diizinkan.

Misalnya:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: allow-flex-volumes
spec:
  # ... kolom kolom lainnya
  volumes:
    - flexVolume
  allowedFlexVolumes:
    - driver: example/lvm
    - driver: example/cifs

Pengguna dan Grup

RunAsUser - Mengatur ID pengguna mana yang digunakan untuk menjalankan container-container.

• MustRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Menggunakan semua nilai minimum dari range yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semua range.
• MustRunAsNonRoot - Mengharuskan Pod diajukan dengan nilai runAsUser yang bukan nol, atau memiliki petunjuk USER didefinisikan (dengan UID numerik) di dalam image. Pod-Pod yang belum memperinci runAsNonRoot atau runAsUser akan dimutasikan untuk menyetel runAsNonRoot=true sehingga membutuhkan petunjuk USER dengan nilai numerik bukan nol di dalam Container. Tidak ada nilai bawaan yang diberikan. Menyetel allowPrivilegeEscalation=false sangat disarankan dengan strategi ini.
• RunAsAny - Tidak ada nilai bawaan yang diberikan. Mengizinkan runAsUser apapun untuk digunakan.

RunAsGroup - Mengatur ID grup primer mana yang digunakan untuk menjalankan Container-container.

• MustRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Menggunakan semua nilai minimum dari range yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semua range.
• MayRunAs - Tidak memerlukan RunAsGroup untuk diperinci. Tetapi, saat RunAsGroup diperinci, mereka harus berada pada range yang didefinisikan.
• RunAsAny - Tidak ada nilai bawaan yang diberikan. Mengizinkan runAsGroup apapun untuk digunakan.

SupplementalGroups - Mengatur ID grup mana saja yang ditambah ke Container-container.

• MustRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Menggunakan semua nilai minimum dari range yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semua range.
• MayRunAs - Membutuhkan setidaknya satu range untuk dapat ditentukan. Mengizinkan supplementalGroups dibiarkan kosong tanpa memberikan nilai bawaan. Memvalidasikan terhadap semua range jika nilai supplementalGroup disetel.
• RunAsAny - Tidak ada nilai bawaan yang diberikan. Mengizinkan ID supplementalGroups apapun untuk digunakan.

Eskalasi Privilege

Opsi ini mengatur opsi Container allowPrivilegeEscalation. Nilai bool ini secara langsung mengatur apakah flag no_new_privs disetel pada proses Container tersebut. Flag ini akan mencegah program setuid mengganti ID pengguna efektif, dan mencegah berkas-berkas untuk memungkinkan kemampuan tambahan (misalnya, ini akan mencagah penggunaan peralatan ping). Perilaku ini dibutuhkan untuk memaksakan MustRunAsNonRoot.

AllowPrivilegeEscalation - Membatasi apakah seorang pengguna diizinkan untuk menyetel konteks keamanan dari sebuah Container menjadi allowPrivilegeEscalation=true. Hal ini memiliki nilai bawaan untuk diizinkan, agar tidak merusak program setuid. Menyetel ini menjadi false memastikan bahwa tidak ada proses child dari sebuah Container dapat memperoleh lebih banyak privilege dari parent-nya.

DefaultAllowPrivilegeEscalation - Menyetel nilai bawaan untuk opsi allowPrivilegeEscalation. Perilaku bawaan tanpa hal ini adalah untuk mengizinkan eskalasi privilege agar tidak merusak program setuid. Jika perilaku ini tidak diinginkan, kolom ini dapat digunakan untuk menyetel nilai bawaan allowPrivilegeEscalation agar melarang eskalasi, sementara masih mengizinkan Pod-Pod untuk meminta allowPrivilegeEscalation secara eksplisit.

Kemampuan-kemampuan

Kemampuan-kemampuan Linux menyediakan perincian yang detail dari privilege-privilege yang biasa dikaitkan dengan superuser. Beberapa dari kemampuan-kemampuan ini dapat digunakan untuk mengeskalasi privilege-privilege atau untuk container breakout, dan dapat dibatasi oleh PodSecurityPolicy. Untuk lebih lanjut tentang kemampuan-kemampuan Linux, lihat capabilities(7).

Kolom-kolom berikut mengambil daftar kemampuan-kemampuan, diperincikan sebagai nama kemampuannya dalam ALL_CAPS tanpa awalan CAP_.

AllowedCapabilities - Menyediakan sebuah daftar putih dari kemampuan-kemampuan yang dapat ditambahkan pada sebuah Container. Kumpulan kemampuan bawaan secara implisit diizinkan. Kumpulan kosong berarti tidak ada kemampuan tambahan yang dapat ditambahkan selain bawaannya. * dapat digunakan untuk mengizinkan semua kemampuan.

RequiredDropCapabilities - Kemampuan-kemampuan yang harus dihapus dari Container-container. Kemampuan-kemampuan ini dihapus dari kumpulan bawaan, dan tidak boleh ditambahkan. Kemampuan-kemampuan yang terdaftar di RequiredDropCapabilities tidak boleh termasuk di dalam AllowedCapabilities atau DefaultAddCapabilities.

DefaultAddCapabilities - Kemampuan-kemampuan yang ditambahkan pada Container-container secara bawaan, sebagai tambahan untuk bawaan runtime. Lihat dokumentasi Docker untuk daftar kemampuan bawaan saat menggunakan runtime Docker.

SELinux

• MustRunAs - Mengharuskan penyetelan seLinuxOptions. Menggunakan seLinuxOptions sebagai nilai bawaannya. Memvalidasi terhadap seLinuxOptions.
• RunAsAny - Tidak ada nilai bawaan yang disediakan. Mengizinkan nilai seLinuxOptions apapun untuk diberikan.

AllowedProcMountTypes

allowedProcMountTypes adalah sebuah daftar putih dari ProcMountType yang diizinkan. Nilai kosong atau nil menunjukkan bahwa hanya DefaultProcMountType yang boleh digunakan.

DefaultProcMount menggunakan nilai bawaan container runtime untuk readonly dan masked paths untuk /proc. Kebanyakan runtime Container melakukan mask terhadap beberapa path di dalam /proc untuk menghindari security exposure dari perangkat-perangkat atau informasi khusus yang tidak disengaja. Hal ini ditandai dengan nilai string Default.

Satu-satunya ProcMountType lainnya adalah UnmaskedProcMount, yang melangkahi perilaku masking bawaan dari runtime Container dan memastikan bahwa /proc yang baru dibuat tetap utuh tanpa perubahan. Hal ini ditandai dengan nilai string Unmasked.

AppArmor

Diatur melalui anotasi pada PodSecurityPolicy. Lihat dokumentasi AppArmor.

Seccomp

Penggunaan profil-profil seccomp di dalam Pod-Pod dapat diatur melalui anotasi pada PodSecurityPolicy. Seccomp adalah fitur Alpha di Kubernetes.

seccomp.security.alpha.kubernetes.io/defaultProfileName - Anotasi yang menunjukkan profil seccomp bawaan untuk diterapkan kepada container-container. Nilai-nilai yang mungkin adalah:

• unconfined - Seccomp tidak diterapkan pada proses-proses di container (ini adalah bawaan di Kubernetes), jika tidak ada alternatif yang diberikan.
• runtime/default - Profil runtime container bawaan digunakan.
• docker/default - Profil bawaan seccomp Docker digunakan. Sudah kedaluwarsa sejak Kubernetes 1.11. Gunakan runtime/default sebagai gantinya.
• localhost/<path> - Menentukan sebuah profil sebagai sebuah berkas pada Node yang berlokasi pada <seccomp_root>/<path>, di mana <seccomp_root> didefinisikan melalui flag --seccomp-profile-root pada Kubelet.

seccomp.security.alpha.kubernetes.io/allowedProfileNames - Anotasi yang menunjukkan nilai-nilai mana yang diizinkan untuk anotasi seccomp pada Pod. Ditentukan sebagai sebuah daftar nilai yang diizinkan yang dibatasi dengan tanda koma. Nilai-nilai yang dimungkinkan adalah yang terdaftar di atas, ditambah dengan * untuk mengizinkan semua profil. Ketiadaan anotasi ini berarti nilai bawaannya tidak dapat diubah.

Sysctl

Secara bawaan, semua sysctl yang aman diizinkan.

• forbiddenSysctls - mengecualikan sysctl-sysctl tertentu. Kamu dapat melarang kombinasi dari sysctl-sysctl yang aman maupun tidak aman pada daftar ini. Untuk melarang menyetel sysctl apapun, gunakan nilai *.
• allowedUnsafeSysctls - mengizinkan sysctl-sysctl tertentu yang telah dilarang oleh daftar bawaan, selama nilainya tidak terdaftar di dalam forbiddenSysctls.

Lihat dokumentasi Sysctl.

Masukan

Apakah halaman ini berguna?

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.