Policies

• 1: LimitRange
• 2: Resource Quota
• 3: Pod Security Policy

1 - LimitRange

Secara bawaan, Container berjalan dengan sumber daya komputasi tanpa batas pada klaster Kubernetes. Dengan ResourceQuota (kuota sumber daya), administrator klaster dapat membatasi konsumsi dan pembuatan sumber daya berbasis Namespace. Di dalam Namespace, Pod atau Container dapat mengkonsumsi CPU dan memori sesuai dengan yang ditentukan oleh ResourceQuota pada Namespace tersebut. Ada kekhawatiran bahwa satu Pod atau Container dapat memonopoli semua sumber daya yang tersedia. LimitRange (Batas Rentang) adalah kebijakan untuk membatasi alokasi sumber daya (bagi Pod atau Container) pada Namespace.

LimitRange memberikan batasan (limit) yang dapat:

• Menerapkan penggunaan sumber daya komputasi minimum dan maksimum untuk setiap Pod atau Container dalam Namespace.
• Menerapkan permintaan (request) tempat penyimpanan minimum dan maksimum untuk setiap PersistentVolumeClaim dalam Namespace.
• Menerapkan rasio antara permintaan dan batas untuk sumber daya dalam Namespace.
• Menetapkan permintaan/batas bawaan untuk menghitung sumber daya dalam Namespace dan memasukkannya secara otomatis ke Container pada runtime.

Mengaktifkan LimitRange

Dukungan LimitRange diaktifkan secara bawaan untuk banyak distribusi Kubernetes. Hal ini diaktifkan ketika tanda --enable-admission-plugins= pada apiserver memiliki admission controller LimitRanger sebagai salah satu argumennya.

LimitRange diberlakukan pada Namespace tertentu ketika ada sebuah objek LimitRange pada Namespace tersebut.

Nama dari objek LimitRange harus merupakan sebuah nama subdomain DNS.

Gambaran Umum LimitRange

• Administrator membuat sebuah LimitRange dalam sebuah Namespace.
• Pengguna membuat sumber daya seperti Pod, Container, dan PersistentVolumeClaim pada namespace.
• Admission controller LimitRanger memberlakukan bawaan dan batas untuk semua Pod dan Container yang tidak menetapkan persyaratan sumber daya komputasi dan melacak penggunaannya untuk memastikan agar tidak melebihi minimum, maksimum dan rasio sumber daya yang ditentukan dalam LimitRange yang ada pada Namespace.
• Apabila permintaan membuat atau memperbarui sumber daya (Pod, Container, PersistentVolumeClaim) yang melanggar batasan LimitRange, maka permintaan ke server API akan gagal dengan kode status HTTP 403 FORBIDDEN dan sebuah pesan yang menjelaskan batasan yang telah dilanggar.
• Apabila LimitRange diaktifkan pada Namespace untuk menghitung sumber daya seperti cpu dan memory, pengguna harus menentukan permintaan atau batasan untuk nilai-nilai itu. Jika tidak, sistem dapat menolak pembuatan Pod.
• Pelanggaran terhadap LimitRange hanya terjadi pada tahap penerimaan Pod, bukan pada saat Pod sedang berjalan.

Contoh dari kebijakan yang dapat dibuat dengan menggunakan LimitRange yaitu:

• Dalam klaster dua Node dengan kapasitas 8 GiB RAM dan 16 core, batasan Pod dalam Namespace meminta 100m untuk CPU dengan batas maksimum 500m untuk CPU dan minta 200Mi untuk Memori dengan batas maksimum 600Mi untuk Memori.
• Tetapkan batas bawaan dan permintaan pada 150m untuk CPU dan permintaan standar memori pada 300Mi untuk Container yang dimulai tanpa cpu dan permintaan memori dalam spesifikasi mereka.

Dalam kasus di mana batas total Namespace kurang dari jumlah batas Pod/Container, mungkin akan ada perebutan untuk sumber daya. Dalam hal ini, maka Container atau Pod tidak akan dibuat.

Baik perebutan maupun perubahan pada LimitRange tidak akan mempengaruhi sumber daya yang sudah dibuat.

Selanjutnya

Silahkan merujuk pada Dokumen perancangan LimitRanger untuk informasi lebih lanjut.

Untuk contoh tentang penggunaan batas, lihatlah:

• Bagaimana cara mengonfigurasi batasan CPU minimum dan maksimum untuk setiap Namespace.
• Bagaimana cara mengonfigurasi batasan memori minimum dan maksimum untuk setiap Namespace.
• Bagaimana cara mengonfigurasi permintaan dan batas bawaan CPU untuk setiap Namespace.
• Bagaimana cara mengonfigurasi permintaan dan batas bawaan memori untuk setiap Namespace.
• Bagaimana cara mengonfigurasi konsumsi tempat penyimpanan minimum dan maksimum untuk setiap Namespace.
• Contoh terperinci tentang mengonfigurasi kuota untuk setiap Namespace.

2 - Resource Quota

Saat beberapa pengguna atau tim berbagi sebuah klaster dengan jumlah Node yang tetap, ada satu hal yang perlu diperhatikan yaitu suatu tim dapat menggunakan sumber daya lebih dari jatah yang mereka perlukan.

Resource Quota (kuota sumber daya) adalah sebuah alat yang dapat digunakan oleh administrator untuk mengatasi hal ini.

Sebuah Resource Quota, didefinisikan oleh objek API ResourceQuota, menyediakan batasan-batasan yang membatasi konsumsi gabungan sumber daya komputasi untuk tiap Namespace. Resource Quota dapat membatasi jumlah objek yang dapat dibuat dalam sebuah Namespace berdasarkan tipenya, maupun jumlah seluruh sumber daya komputasi yang dapat dipakai oleh sumber daya API (misalnya Pod) di Namespace tersebut.

Resource Quota bekerja sebagai berikut:

• Tim-tim berbeda bekerja pada Namespace yang berbeda pula. Sekarang hal ini belum diwajibkan, tetapi dukungan untuk mewajibkannya melalui ACL sedang direncanakan.
• Administrator membuat sebuah ResourceQuota untuk setiap Namespace.
• Para pengguna membuat sumber daya (Pod, Service, dll.) di dalam Namespace tersebut, kemudian sistem kuota memantau penggunaan untuk memastikan bahwa penggunaannya tidak melebihi batas sumber daya yang ditentukan di ResourceQuota.
• Jika pembuatan atau pembaruan sebuah sumber daya melanggar sebuah batasan kuota, maka permintaan tersebut akan gagal dengan kode status 403 FORBIDDEN dengan sebuah pesan yang menjelaskan batasan yang akan dilanggar.
• Jika kuota diaktifkan di sebuah Namespace untuk sumber daya komputasi seperti cpu dan memory, pengguna-pengguna harus menentukan requests atau limits untuk sumber daya tersebut; atau sistem kuota akan menolak pembuatan Pod tersebut. Petunjuk: Gunakan Admission Controller LimitRanger untuk memaksa nilai-nilai bawaan untuk Pod-Pod yang tidak menentukan kebutuhan sumber daya komputasi. Lihat petunjuknya untuk contoh bagaimana cara menghindari masalah ini.

Contoh-contoh kebijakan yang dapat dibuat menggunakan Namespace dan kuota adalah:

• Dalam sebuah klaster dengan kapasitas RAM 32 GiB, dan CPU 16 core, misalkan tim A menggunakan 20GiB dan 10 core, dan tim B menggunakan 10GiB dan 4 core, dan menyimpan 2GiB dan 2 core untuk cadangan penggunaan di masa depan.
• Batasi Namespace "testing" dengan batas 1 core dan RAM 1GiB. Biarkan Namespace "production" menggunakan berapapun jumlah yang diinginkan.

Pada kasus di mana total kapasitas klaster lebih sedikit dari jumlah seluruh kuota di seluruh Namespace, dapat terjadi perebutan sumber daya komputasi. Masalah ini akan ditangani dengan cara siapa-cepat-dia-dapat.

Perebutan sumber daya komputasi maupun perubahan kuota tidak akan memengaruhi sumber daya yang sudah dibuat sebelumnya.

Mengaktifkan Resource Quota

Dukungan untuk Resource Quota diaktifkan secara bawaan pada banyak distribusi Kubernetes. Resource Quota diaktifkan saat flag --enable-admission-plugins= pada apiserver memiliki ResourceQuota sebagai salah satu nilainya.

Sebuah Resource Quota akan dipaksakan pada sebuah Namespace tertentu saat ada sebuah objek ResourceQuota di dalam Namespace tersebut.

Resource Quota Komputasi

Kamu dapat membatasi jumlah total sumber daya komputasi yang dapat diminta di dalam sebuah Namespace.

Berikut jenis-jenis sumber daya yang didukung:

Resource Quota untuk sumber daya yang diperluas

Sebagai tambahan untuk sumber daya yang disebutkan di atas, pada rilis 1.10, dukungan kuota untuk sumber daya yang diperluas ditambahkan.

Karena overcommit tidak diperbolehkan untuk sumber daya yang diperluas, tidak masuk akal untuk menentukan keduanya; requests dan limits untuk sumber daya yang diperluas yang sama pada sebuah kuota. Jadi, untuk sumber daya yang diperluas, hanya kuota dengan prefiks requests. saja yang diperbolehkan untuk sekarang.

Mari kita ambil contoh sumber daya GPU. Jika nama sumber dayanya adalah nvidia.com/gpu, dan kamu ingin membatasi jumlah total GPU yang diminta pada sebuah Namespace menjadi 4, kamu dapat menentukan sebuah kuota sebagai berikut:

• requests.nvidia.com/gpu: 4

Lihat Melihat dan Menyetel Kuota untuk informasi lebih lanjut.

Resource Quota untuk penyimpanan

Kamu dapat membatasi jumlah total sumber daya penyimpanan yang dapat diminta pada sebuah Namespace.

Sebagai tambahan, kamu dapat membatasi penggunaan sumber daya penyimpanan berdasarkan storage class sumber daya penyimpanan tersebut.

Sebagai contoh, jika sebuah operator ingin membatasi penyimpanan dengan Storage Class gold yang berbeda dengan Storage Class bronze, maka operator tersebut dapat menentukan kuota sebagai berikut:

• gold.storageclass.storage.k8s.io/requests.storage: 500Gi
• bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

Pada rilis 1.8, dukungan kuota untuk penyimpanan lokal sementara (local ephemeral storage) ditambahkan sebagai sebuah fitur alpha:

Kuota Kuantitas Objek

Rilis 1.9 menambahkan dukungan untuk membatasi semua jenis sumber daya standar yang berada pada sebuah Namespace dengan sintaksis sebagai berikut:

• count/<sumber-daya>.<grup>

Berikut contoh-contoh sumber daya yang dapat ditentukan pengguna pada kuota kuantitas objek:

• count/persistentvolumeclaims
• count/services
• count/secrets
• count/configmaps
• count/replicationcontrollers
• count/deployments.apps
• count/replicasets.apps
• count/statefulsets.apps
• count/jobs.batch
• count/cronjobs.batch
• count/deployments.extensions

Rilis 1.15 menambahkan dukungan untuk sumber daya custom menggunakan sintaksis yang sama. Contohnya, untuk membuat kuota pada sumber daya custom widgets pada grup API example.com, gunakan count/widgets.example.com.

Saat menggunakan Resource Quota count/*, sebuah objek akan menggunakan kuotanya jika ia berada pada penyimpanan Apiserver. Tipe-tipe kuota ini berguna untuk menjaga dari kehabisan sumber daya penyimpanan. Misalnya, kamu mungkin ingin membatasi kuantitas objek Secret pada sebuah Apiserver karena ukuran mereka yang besar. Terlalu banyak Secret pada sebuah klaster bahkan dapat membuat Server dan Controller tidak dapat dijalankan! Kamu dapat membatasi jumlah Job untuk menjaga dari CronJob yang salah dikonfigurasi sehingga membuat terlalu banyak Job pada sebuah Namespace yang mengakibatkan denial of service.

Sebelum rilis 1.9, kita tidak dapat melakukan pembatasan kuantitas objek generik pada kumpulan sumber daya yang terbatas. Sebagai tambahan, kita dapat membatasi lebih lanjut sumber daya tertentu dengan kuota berdasarkan jenis mereka.

Berikut jenis-jenis yang telah didukung:

Sebagai contoh, pods membatasi kuantitas dan memaksa kuantitas maksimum pods yang berada pada kondisi non-terminal yang dibuat pada sebuah Namespace. Kamu mungkin ingin menyetel kuota pods pada sebuah Namespace untuk menghindari kasus di mana pengguna membuat banyak Pod kecil dan menghabiskan persediaan alamat IP Pod pada klaster.

Lingkup Kuota

Setiap kuota dapat memiliki kumpulan lingkup yang dikaitkan. Sebuah kuota hanya akan mengukur penggunaan sebuah sumber daya jika sumber daya tersebut cocok dengan irisan dari lingkup-lingkup yang ditentukan.

Saat sebuah lingkup ditambahkan kepada kuota, lingkup itu akan membatasi kuantitas sumber daya yang didukung menjadi yang berkaitan dengan lingkup tersebut. Sumber daya yang ditentukan pada kuota di luar kumpulan yang diizinkan akan menghasilkan kesalahan validasi.

Lingkup BestEffort membatasi sebuah kuota untuk memantau sumber daya berikut: pods

Lingkup Terminating, NotTerminating, dan NotBestEffort membatasi sebuah kuota untuk memantau sumber daya berikut:

• cpu
• limits.cpu
• limits.memory
• memory
• pods
• requests.cpu
• requests.memory

Resource Quota Per PriorityClass

Pod-Pod dapat dibuat dengan sebuah Priority (prioritas) tertentu. Kamu dapat mengontrol konsumsi sumber daya sistem sebuah Pod berdasarkan Priority Pod tersebut, menggunakan kolom scopeSelector pada spesifikasi kuota tersebut.

Sebuah kuota dicocokkan dan digunakan hanya jika scopeSelector pada spesifikasi kuota tersebut memilih Pod tersebut.

Contoh ini membuat sebuah objek kuota dan mencocokkannya dengan Pod-Pod pada Priority tertentu. Contoh tersebut bekerja sebagai berikut:

• Pod-Pod di dalam klaster memiliki satu dari tiga Priority Class, "low", "medium", "high".
• Satu objek kuota dibuat untuk setiap Priority.

Simpan YAML berikut ke sebuah berkas bernama quota.yml.

apiVersion: v1
kind: List
items:
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-high
  spec:
    hard:
      cpu: "1000"
      memory: 200Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["high"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-medium
  spec:
    hard:
      cpu: "10"
      memory: 20Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["medium"]
- apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: pods-low
  spec:
    hard:
      cpu: "5"
      memory: 10Gi
      pods: "10"
    scopeSelector:
      matchExpressions:
      - operator : In
        scopeName: PriorityClass
        values: ["low"]

Terapkan YAML tersebut dengan kubectl create.

kubectl create -f ./quota.yml

resourcequota/pods-high created
resourcequota/pods-medium created
resourcequota/pods-low created

Pastikan bahwa kuota Used adalah 0 dengan kubectl describe quota.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     1k
memory      0     200Gi
pods        0     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

Buat sebuah Pod dengan Priority "high". Simpan YAML berikut ke sebuah berkas bernama high-priority-pod.yml.

apiVersion: v1
kind: Pod
metadata:
  name: high-priority
spec:
  containers:
  - name: high-priority
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", "while true; do echo hello; sleep 10;done"]
    resources:
      requests:
        memory: "10Gi"
        cpu: "500m"
      limits:
        memory: "10Gi"
        cpu: "500m"
  priorityClassName: high

Terapkan dengan kubectl create.

kubectl create -f ./high-priority-pod.yml

Pastikan bahwa status "Used" untuk kuota dengan Priority "high", pods-high, telah berubah dan dua kuota lainnya tidak berubah.

kubectl describe quota

Name:       pods-high
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         500m  1k
memory      10Gi  200Gi
pods        1     10


Name:       pods-low
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     5
memory      0     10Gi
pods        0     10


Name:       pods-medium
Namespace:  default
Resource    Used  Hard
--------    ----  ----
cpu         0     10
memory      0     20Gi
pods        0     10

scopeSelector mendukung nilai-nilai berikut pada kolom operator:

• In
• NotIn
• Exist
• DoesNotExist

Request vs Limit

Saat mengalokasikan sumber daya komputasi, setiap Container dapat menentukan sebuah nilai request (permintaan) dan limit untuk CPU atau memori. Kuota tersebut dapat dikonfigurasi untuk membatasi nilai salah satunya.

Jika kuota tersebut memiliki sebuah nilai yang ditentukan untuk requests.cpu atau requests.memory, maka kuota tersebut mengharuskan setiap Container yang akan dibuat untuk menentukan request eksplisit untuk sumber daya tersebut. Jika kuota tersebut memiliki sebuah nilai yang ditentukan untuk limits.cpu atau limits.memory, maka kuota tersebut mengharuskan setiap Container yang akan dibuat untuk menentukan limit eksplisit untuk sumber daya tersebut.

Melihat dan Menyetel kuota

Kubectl mendukung membuat, membarui, dan melihat kuota:

kubectl create namespace myspace

cat <<EOF > compute-resources.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.nvidia.com/gpu: 4
EOF

kubectl create -f ./compute-resources.yaml --namespace=myspace

cat <<EOF > object-counts.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: object-counts
spec:
  hard:
    configmaps: "10"
    persistentvolumeclaims: "4"
    pods: "4"
    replicationcontrollers: "20"
    secrets: "10"
    services: "10"
    services.loadbalancers: "2"
EOF

kubectl create -f ./object-counts.yaml --namespace=myspace

kubectl get quota --namespace=myspace

NAME                    AGE
compute-resources       30s
object-counts           32s

kubectl describe quota compute-resources --namespace=myspace

Name:                    compute-resources
Namespace:               myspace
Resource                 Used  Hard
--------                 ----  ----
limits.cpu               0     2
limits.memory            0     2Gi
requests.cpu             0     1
requests.memory          0     1Gi
requests.nvidia.com/gpu  0     4

kubectl describe quota object-counts --namespace=myspace

Name:                   object-counts
Namespace:              myspace
Resource                Used    Hard
--------                ----    ----
configmaps              0       10
persistentvolumeclaims  0       4
pods                    0       4
replicationcontrollers  0       20
secrets                 1       10
services                0       10
services.loadbalancers  0       2

Kubectl juga mendukung kuota kuantitas objek untuk semua sumber daya standar yang berada pada Namespace menggunakan sintaksis count/<resource>.<group>:

kubectl create namespace myspace

kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace

kubectl run nginx --image=nginx --replicas=2 --namespace=myspace

kubectl describe quota --namespace=myspace

Name:                         test
Namespace:                    myspace
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  1     2
count/pods                    2     3
count/replicasets.extensions  1     4
count/secrets                 1     4

Kuota dan Kapasitas Klaster

ResourceQuota tidak tergantung pada kapasitas klaster. ResourceQuota ditentukan dalam satuan-satuan absolut. Jadi, jika kamu menambahkan Node ke klaster kamu, penambahan ini bukan berarti secara otomatis memberikan setiap Namespace kemampuan untuk menggunakan lebih banyak sumber daya.

Terkadang kebijakan yang lebih kompleks mungkin lebih diinginkan, seperti:

• Secara proporsional membagi sumber daya total klaster untuk beberapa tim.
• Mengizinkan setiap tim untuk meningkatkan penggunaan sumber daya sesuai kebutuhan, tetapi tetap memiliki batas yang cukup besar untuk menghindari kehabisan sumber daya.
• Mendeteksi permintaan dari sebuah Namespace, menambah Node, kemudian menambah kuota.

Kebijakan-kebijakan seperti itu dapat diterapkan dengan ResourceQuota sebagai dasarnya, dengan membuat sebuah "pengontrol" yang memantau penggunaan kuota dan menyesuaikan batas keras kuota untuk setiap Namespace berdasarkan sinyal-sinyal lainnya.

Perlu dicatat bahwa Resource Quota membagi agregat sumber daya klaster, tapi Resource Quota tidak membuat batasan-batasan terhadap Node: Pod-Pod dari beberapa Namespace boleh berjalan di Node yang sama.

Membatasi konsumsi Priority Class secara bawaan

Mungkin saja diinginkan untuk Pod-Pod pada kelas prioritas tertentu, misalnya "cluster-services", sebaiknya diizinkan pada sebuah Namespace, jika dan hanya jika terdapat sebuah objek kuota yang cocok.

Dengan mekanisme ini, operator-operator dapat membatasi penggunaan Priority Class dengan prioritas tinggi pada Namespace-Namespace tertentu saja dan tidak semua Namespace dapat menggunakan Priority Class tersebut secara bawaan.

Untuk memaksa aturan ini, flag kube-apiserver --admission-control-config-file sebaiknya digunakan untuk memberikan path menuju berkas konfigurasi berikut:

• apiserver.config.k8s.io/v1
• apiserver.k8s.io/v1alpha1

apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    apiVersion: apiserver.config.k8s.io/v1
    kind: ResourceQuotaConfiguration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

# Kedaluwarsa pada v1.17 digantikan oleh apiserver.config.k8s.io/v1
apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: "ResourceQuota"
  configuration:
    # Kedaluwarsa pada v1.17 digantikan oleh apiserver.config.k8s.io/v1, ResourceQuotaConfiguration
    apiVersion: resourcequota.admission.k8s.io/v1beta1
    kind: Configuration
    limitedResources:
    - resource: pods
      matchScopes:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

Sekarang, Pod-Pod "cluster-services" akan diizinkan hanya pada Namespace di mana ada sebuah objek kuota dengan sebuah scopeSelector yang cocok.

Contohnya:

    scopeSelector:
      matchExpressions:
      - scopeName: PriorityClass
        operator: In
        values: ["cluster-services"]

Lihat LimitedResources dan dokumen desain dukungan Quota untuk Priority Class untuk informasi lebih lanjut.

Contoh

Lihat contoh detail cara menggunakan sebuah Resource Quota.

Selanjutnya

Lihat dokumen desain ResourceQuota untuk informasi lebih lanjut.

3 - Pod Security Policy

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:

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.