Pod Security Policy
Kubernetes v1.24 [beta]
Pod Security Policies (kebijakan keamanan Pod) memungkinkan otorisasi secara detil dari pembuatan dan pembaruan Pod.
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:
Aspek yang diatur | Nama Kolom |
---|---|
Menjalankan Container-container yang privileged | privileged |
Penggunaan namespace-namespace milik host | hostPID , hostIPC |
Penggunaan jaringan dan port milik host | hostNetwork , hostPorts |
Penggunaan jenis-jenis Volume | volumes |
Penggunaan filesystem milik host | allowedHostPaths |
Daftar putih untuk driver-driver Flexvolume | allowedFlexVolumes |
Mengalokasi FSGroup yang memiliki Volume milik Pod | fsGroup |
Mengharuskan penggunaan read-only root filesystem | readOnlyRootFilesystem |
User dan Grop ID dari Container | runAsUser , runAsGroup , supplementalGroups |
Membatasi eskalasi ke kemampuan root | allowPrivilegeEscalation , defaultAllowPrivilegeEscalation |
Kemampuan-kemampuan Linux | defaultAddCapabilities , requiredDropCapabilities , allowedCapabilities |
Konteks SELinux dari Container ainer | seLinux |
Jenis tambatan Proc yang diizinkan untuk Container | allowedProcMountTypes |
Profil AppArmor yang digunakan oleh Container | annotations |
Profil seccomp yang digubakan oleh Container | annotations |
Profil sysctl yang digunakan oleh Container | forbiddenSysctls ,allowedUnsafeSysctls |
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:
- 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.
- Jika Pod-nya harus diberi nilai bawaan atau dimutasi, maka PodSecurityPolicy pertama (diurutkan berdasarkan namanya) untuk mengizinkan Pod tersebut akan dipilih.
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.
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:
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:
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.
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
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 darirange
yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semuarange
. - MayRunAs - Membutuhkan setidaknya satu
range
untuk dapat ditentukan. MengizinkanFSGroups
dibiarkan kosong tanpa memberikan nilai bawaan. Memvalidasikan terhadap semuarange
jika nilaiFSGroups
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_
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 darirange
yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semuarange
. - MustRunAsNonRoot - Mengharuskan Pod diajukan dengan nilai
runAsUser
yang bukan nol, atau memiliki petunjukUSER
didefinisikan (dengan UID numerik) di dalam image. Pod-Pod yang belum memperincirunAsNonRoot
ataurunAsUser
akan dimutasikan untuk menyetelrunAsNonRoot=true
sehingga membutuhkan petunjukUSER
dengan nilai numerik bukan nol di dalam Container. Tidak ada nilai bawaan yang diberikan. MenyetelallowPrivilegeEscalation=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 darirange
yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semuarange
. - MayRunAs - Tidak memerlukan
RunAsGroup
untuk diperinci. Tetapi, saatRunAsGroup
diperinci, mereka harus berada padarange
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 darirange
yang pertama sebagai nilai bawaannya. Memvalidasikan terhadap semuarange
. - MayRunAs - Membutuhkan setidaknya satu
range
untuk dapat ditentukan. MengizinkansupplementalGroups
dibiarkan kosong tanpa memberikan nilai bawaan. Memvalidasikan terhadap semuarange
jika nilaisupplementalGroup
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
. MenggunakanseLinuxOptions
sebagai nilai bawaannya. Memvalidasi terhadapseLinuxOptions
. - 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. Gunakanruntime/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 dalamforbiddenSysctls
.
Lihat dokumentasi Sysctl.