Bermigrasi dari OpenShift ke GKE Enterprise: Memigrasikan batasan konteks keamanan OpenShift ke GKE Enterprise

Last reviewed 2022-01-24 UTC

Dokumen ini membantu Anda merencanakan migrasi kebijakan keamanan dari API batasan keamanan (SCC) OpenShift yang ditetapkan di cluster OpenShift sumber ke cluster GKE target. Implementasi ini menggunakan batasan Pengontrol Kebijakan untuk menentukan kebijakan yang dimigrasikan di cluster target.

Dokumen ini mengasumsikan bahwa Anda telah memahami Memigrasikan container ke Google Cloud: Bermigrasi dari OpenShift ke GKE Enterprise. Tutorial ini mengasumsikan bahwa Anda sudah memahami OpenShift dan Batasan Konteks Keamanan dan memiliki akses ke cluster OpenShift sumber dan cluster GKE target.

Dokumen ini adalah bagian dari seri multi-bagian tentang migrasi ke Google Cloud. Untuk ringkasan rangkaian ini, lihat Bermigrasi ke Google Cloud: Memilih jalur migrasi Anda.

Dokumen ini adalah bagian dari rangkaian yang membahas memigrasi containers ke Google Cloud:

Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke Google Kubernetes Engine (GKE)
Memigrasikan container ke Google Cloud: Bermigrasi dari OpenShift ke GKE Enterprise
Memigrasikan container ke Google Cloud: Memigrasikan project OpenShift ke GKE Enterprise
Bermigrasi dari OpenShift ke GKE Enterprise: Memigrasikan OpenShift SCC ke batasan Pengontrol Kebijakan (dokumen ini)

Dokumen ini berguna jika Anda berencana memigrasikan OpenShift SCC ke GKE Enterprise. Dokumen ini juga berguna jika Anda sedang mengevaluasi peluang untuk bermigrasi dan ingin mempelajari kemungkinan gambarannya.

Dokumen ini mengandalkan konsep yang dibahas dalam Migrasi ke Google Cloud: Memulai, dalam Memigrasikan container ke Google Cloud: Memigrasikan Kubernetes ke GKE, dalam Memigrasikan container ke Google Cloud: Bermigrasi dari OpenShift ke GKE Enterprise, dan dalam Praktik terbaik untuk networking GKE. Link ke dokumen-dokumen tersebut dicantumkan, jika diperlukan.

OpenShift SCC

SCC adalah resource khusus OpenShift berfungsi untuk menentukan kebijakan Pod, yang mana kebijakan ini akan menentukan tindakan apa yang dapat dilakukan Pod dan resource apa yang dapat diakses di node. Saat Anda membuat permintaan API untuk membuat pod, SCC akan mengevaluasi permintaan Pod, terkait dengan hak istimewa proses, berdasarkan serangkaian kebijakan yang ditentukan melalui SCC. SCC mengevaluasi permintaan untuk mengizinkan atau melarang eksekusi Pod sesuai dengan kebijakan yang dikonfigurasi. Untuk informasi selengkapnya tentang OpenShift SCC, lihat Mengelola batasan konteks keamanan.

OpenShift SCC Default

Cluster OpenShift 4.x berisi kumpulan SCC default yang dijelaskan dalam postingan blog Mengelola SCC dalam OpenShift oleh Red Hat.

Sinkronisasi Konfigurasi dan Pengontrol Kebijakan

Bagian ini menjelaskan Config Sync dan Pengontrol Kebijakan. Bagian ini memberikan link ke dokumentasi dan panduan yang relevan untuk menyiapkan Pengontrol Kebijakan guna melakukan tugas migrasi yang akan dijelaskan nanti dalam dokumen ini.

Config Sync

Config Sync memungkinkan Anda menggunakan repositori umum yang sesuai dengan Git untuk secara terpusat menentukan konfigurasi resource apa pun yang berlaku untuk semua cluster Kubernetes yang dikelola GKE Enterprise. Anda dapat menerapkan konfigurasi tersebut ke beberapa cluster.

Pengontrol Kebijakan

Pengontrol Kebijakan adalah pengontrol penerimaan dinamis Kubernetes yang memeriksa, mengaudit, dan menerapkan kepatuhan cluster Anda terhadap kebijakan yang ditetapkan secara terpusat. Pengontrol Kebijakan didasarkan pada project open source Open Policy Agent (OPA) Gatekeeper.

Penyiapan Sinkronisasi Konfigurasi dan Pengontrol Kebijakan

Untuk bersiap menerapkan kebijakan keamanan yang mencerminkan SCC OpenShift, Anda harus mengaktifkan komponen Config Sync dan Pengontrol Kebijakan untuk setiap cluster target Anda. Bagian ini menjelaskan cara menyiapkan komponen ini. Bagian Memigrasikan OpenShift SCC di bagian selanjutnya dalam dokumen ini menjelaskan cara menggunakan template batasan Pengontrol Kebijakan untuk menerapkan kebijakan keamanan.

Saat Anda menyiapkan Pengontrol Kebijakan, sebaiknya masukkan namespace terkait sistem yang tidak menjalankan Pod aplikasi ke dalam kolom Kecualikan namespace. Mengecualikan namespace terkait sistem akan membantu Anda menghindari risiko pemblokiran Pod sistem, yang nantinya memerlukan hak istimewa yang ditingkatkan. Namespace terkait sistem di cluster GKE dapat mencakup hal berikut:

kube-system
kube-public
gke-connect
gke-system
config-management-system
config-management-monitoring
gatekeeper-system
istio-system
cnrm-system
knative-serving
monitoring-system

Setelah Anda menyiapkan Pengontrol Kebijakan dengan pengecualian tadi, kecualikan namespace dari aplikasi batasan dengan menambahkan label admission.gatekeeper.sh/ignore=true ke setiap namespace. Jika label tidak ditambahkan ke setiap namespace, Pod sistem (dan juga seluruh cluster) dapat terpengaruh oleh kebijakan yang bersifat membatasi.

Memigrasikan OpenShift SCC ke batasan Pengontrol Kebijakan

Bagian ini menjelaskan cara mengekspor SCC dari cluster OpenShift dan mengonfigurasi batasan GKE Enterprise Policy Controller target agar sesuai dengan kebijakan yang diperlukan. Bagian ini juga menjelaskan beberapa perbedaan antara batasan SCC dan Pengontrol Kebijakan sehingga Anda dapat merencanakan migrasi dengan tepat.

Menilai OpenShift SCC

Untuk mengekspor daftar dan konfigurasi SCC yang diinstal di cluster OpenShift, Anda dapat menggunakan perintah berikut:

Mendapatkan daftar semua SCC:
```
oc get scc
```
Mengekspor konfigurasi setiap SCC:
```
oc get scc SCC_NAME > SCC_NAME.yaml
```
Ganti SCC_NAME dengan nama SCC yang konfigurasinya ingin Anda ekspor.

Setelah mengekspor konfigurasi, Anda dapat menganalisisnya dan menggunakan tabel di bagian Memetakan OpenShift SCC berikut untuk mengonfigurasi batasan Pengontrol Kebijakan yang cocok dengan persyaratan keamanan aplikasi Anda.

Memetakan OpenShift SCC ke template batasan Pengontrol Kebijakan

Tabel berikut menyediakan batasan dan setelan Pengontrol Kebijakan yang sesuai dengan kolom OpenShift SCC dan kemungkinan nilainya. Gunakan tabel ini untuk membantu mengonfigurasi batasan Pengontrol Kebijakan target yang cocok dengan persyaratan keamanan aplikasi yang diterapkan melalui OpenShift SCC di lingkungan sumber. Bagian Contoh migrasi menyeluruh dalam dokumen ini memberikan contoh cara menggunakan informasi dalam tabel.

Kolom OpenShift SCC	Jenis / nilai yang mungkin muncul	Template batasan Pengontrol Kebijakan	Spesifikasi batasan Pengontrol Kebijakan
`allowPrivilegedContainer:`	Boolean	K8sPSPPrivilegedContainer	Mencegah container dengan hak istimewa jika diterapkan.
`allowHostIPC:`	Boolean	K8sPSPHostNamespace	Mencegah akses ke namespace `pid` dan `ipc` host jika diterapkan.
`allowHostPID:`	Boolean	K8sPSPHostNamespace	Mencegah akses ke namespace `pid` dan `ipc` host jika diterapkan.
`allowHostNetwork:`	Boolean	K8sPSPHostNetworkingPorts	Memiliki parameter boolean untuk mencegah akses ke jaringan host dan dapat menentukan rentang untuk port host yang dapat diakses.
`allowHostPorts:`	Boolean	K8sPSPHostNetworkingPorts	Memiliki parameter boolean untuk mencegah akses ke jaringan host dan dapat menentukan rentang untuk port host yang dapat diakses.
`readOnlyRootFilesystem:`	Boolean	K8sPSPReadOnlyRootFilesystem	Memungkinkan Anda memasang sistem file root container sebagai hanya baca jika diterapkan.
`allowPrivilegeEscalation: true`	Boolean	K8sPSPAllowPrivilegeEscalationContainer	Mencegah Pod dengan konteks keamanan `AllowPrivilegeEscalation` yang disetel ke true jika diterapkan.
`allowHostDirVolumePlugin:`	Boolean	K8sPSPVolumeTypes	Memiliki parameter untuk menentukan daftar jenis volume yang diizinkan (seperti dalam SCC) termasuk direktori host.
`volumes:`	Daftar array dengan jenis volume yang diizinkan	K8sPSPVolumeTypes	Memiliki parameter untuk menentukan daftar jenis volume yang diizinkan (seperti dalam SCC) termasuk direktori host.
`allowedCapabilities:`	Daftar array kemampuan Linux yang dapat diminta.	K8sPSPCapabilities	Memiliki parameter untuk menentukan kemampuan Linux yang dapat diminta (allowedCapabilities) dan yang dilarang (`requiredDropCapabilites`). Tidak dapat digunakan untuk langsung menambahkan atau menghapus kemampuan yang tercantum, seperti yang dapat dilakukan di `defaultAddCapabilities:` dan `requiredDropCapabilities:` di OpenShift SCC.
`defaultAddCapabilities:`	Daftar array kemampuan Linux yang harus ditambahkan ke setiap container.	K8sPSPCapabilities	Memiliki parameter untuk menentukan kemampuan Linux yang dapat diminta (allowedCapabilities) dan yang dilarang (`requiredDropCapabilites`). Tidak dapat digunakan untuk langsung menambahkan atau menghapus kemampuan yang tercantum, seperti yang dapat dilakukan di `defaultAddCapabilities:` dan `requiredDropCapabilities:` di OpenShift SCC.
`requiredDropCapabilities:`	Daftar array kemampuan Linux yang otomatis dihapus dari Pod atau container.	K8sPSPCapabilities	Memiliki parameter untuk menentukan kemampuan Linux yang dapat diminta (allowedCapabilities) dan yang dilarang (`requiredDropCapabilites`). Tidak dapat digunakan untuk langsung menambahkan atau menghapus kemampuan yang tercantum, seperti yang dapat dilakukan di `defaultAddCapabilities:` dan `requiredDropCapabilities:` di OpenShift SCC.
`fsGroup:`	Memiliki `type: key` yang dapat berupa salah satu dari hal berikut: `MustRunAs`: Memerlukan setidaknya satu rentang untuk ditentukan jika tidak menggunakan nilai yang telah dialokasikan sebelumnya. `RunAsAny`: Memungkinkan semua ID `fsGroup` ditentukan.	K8sPSPAllowedUsers	Memungkinkan Anda menentukan aturan yang memiliki fungsi serupa dengan `type: key` SCC dan rentang `id` untuk parameter `runAsUser`, `runAsGroup`, `supplementalGroups`, dan `fsGroup`. Dapat digunakan untuk menentukan rentang yang diizinkan untuk Pengguna, Grup, Grup Tambahan, atau Grup FS, tetapi tidak untuk menetapkan ID pengguna langsung di Pod seperti yang dapat dilakukan di SCC OpenShift.
`runAsUser:`	Memiliki `type: key` yang dapat berupa salah satu dari hal berikut: `MustRunAs`: Memerlukan runAsUser untuk dikonfigurasi. `MustRunAsRange`: Mewajibkan nilai minimum dan maksimum untuk ditentukan jika tidak menggunakan nilai yang telah dialokasikan sebelumnya dari namespace. `MustRunAsNonRoot`: Mewajibkan Pod dikirim dengan `runAsUser` bukan nol atau memiliki perintah USER yang ditentukan dalam gambar. `RunAsAny`: Memungkinkan setiap `runAsUser` untuk ditentukan.	K8sPSPAllowedUsers	Memungkinkan Anda menentukan aturan yang memiliki fungsi serupa dengan `type: key` SCC dan rentang `id` untuk parameter `runAsUser`, `runAsGroup`, `supplementalGroups`, dan `fsGroup`. Dapat digunakan untuk menentukan rentang yang diizinkan untuk Pengguna, Grup, Grup Tambahan, atau Grup FS, tetapi tidak untuk menetapkan ID pengguna langsung di Pod seperti yang dapat dilakukan di SCC OpenShift.
`supplementalGroups:`	Memiliki `type: key` yang dapat berupa salah satu dari hal berikut: `MustRunAs`: Memerlukan setidaknya satu rentang untuk ditentukan jika tidak menggunakan nilai yang telah dialokasikan sebelumnya dari namespace. `RunAsAny`: Memungkinkan semua supplementalGroups untuk ditentukan.	K8sPSPAllowedUsers	Memungkinkan Anda menentukan aturan yang memiliki fungsi serupa dengan `type: key` SCC dan rentang `id` untuk parameter `runAsUser`, `runAsGroup`, `supplementalGroups`, dan `fsGroup`. Dapat digunakan untuk menentukan rentang yang diizinkan untuk Pengguna, Grup, Grup Tambahan, atau Grup FS, tetapi tidak untuk menetapkan ID pengguna langsung di Pod seperti yang dapat dilakukan di SCC OpenShift.
`seLinuxContext:`	Memiliki `type: key` yang dapat berupa salah satu dari hal berikut: `MustRunAs`: Mewajibkan `seLinuxOptions` untuk dikonfigurasi jika tidak menggunakan nilai yang telah dialokasikan sebelumnya dari namespace. `RunAsAny`: Memungkinkan setiap `seLinuxOptions` untuk ditentukan.	K8sPSPSELinuxV2	Memiliki parameter `allowedSELinuxOptions` tempat Anda dapat menetapkan tingkat, peran, jenis, dan pengguna `seLinuxOptions` yang diizinkan

Perbedaan antara batasan OpenShift SCC dan Pengontrol Kebijakan

Bagian ini menjelaskan beberapa perbedaan antara batasan Pengontrol Kebijakan dan OpenShift SCC. Pertimbangkan perbedaan ini sebelum Anda menggunakan tabel tadi untuk men-deploy batasan di lingkungan target Anda.

Cara penerapan batasan ke resource

Anda dapat menetapkan OpenShift SCC untuk pengguna dan grup menggunakan spesifikasi users: atau group: yang ada dalam objek SCC. Dengan OpenShift 4.x dan versi yang lebih baru, Anda juga dapat menetapkan SCC kepada pengguna atau grup menggunakan role-based access control (RBAC). SCC juga memiliki kolom priority: yang digunakan untuk mengurutkan SCC yang diterapkan ke Pod.

Batasan Pengontrol Kebijakan diterapkan ke cluster, namespace, atau pod target menggunakan pemilih resource tertentu dalam batasan tersebut, bukan menargetkan pengguna atau akun layanan. Untuk informasi selengkapnya, lihat dokumentasi Pengontrol Kebijakan. Menggunakan pemilih resource tertentu akan membantu memastikan bahwa Pod berperilaku sama, baik pada pengguna dengan hak istimewa rendah yang menjalankannya dengan alat deployment atau admin cluster yang meluncurkannya dari command line.

Batasan Pengontrol Kebijakan juga mendukung mode uji coba, yang memungkinkan Anda menguji kebijakan dan mengaudit pelanggaran sebelum penerapan yang sebenarnya. Menggunakan mode ini membantu Anda mencegah dampak pada workload yang ada, sementara SCC akan selalu diterapkan jika berlaku untuk pengguna.

Mutasi Pod SCC menggunakan nilai yang telah dialokasikan sebelumnya di namespace OpenShift

Di OpenShift SCC, Anda dapat mengubah konteks keamanan setiap Pod, tempat SCC diterapkan. Hal ini dilakukan menggunakan ID spesifik dari rentang yang telah dialokasikan sebelumnya, yang disediakan oleh anotasi dalam namespace. Anda melakukannya menggunakan kolom RunAsUser, fsGroup, supplementalGroups, dan seLinuxContext dengan jenis strategi MustRunAs atau MustRunAsRange.

Misalnya, pertimbangkan SCC restricted yang memiliki kolom RunAsUser dengan jenis strategi MustRunAsRange tanpa rentang yang ditentukan dalam SCC. Dalam skenario ini, setiap Pod yang menerima penerapan SCC akan mendapatkan ID RunAsUser dari rentang yang ditentukan dalam anotasi openshift.io/sa.scc.uid-range dalam namespace Pod.

Batasan Pengontrol Kebijakan beserta kemampuan mutasi menyediakan validasi dan mutasi Pod. Namun, batasan tidak menggunakan anotasi dalam namespace untuk memberikan nilai pada konteks keamanan Pod. Bagian berikutnya, Contoh migrasi menyeluruh, memberikan contoh bagaimana tim pengiriman aplikasi Anda harus secara eksplisit mengonfigurasi Konteks Keamanan di Pod untuk mematuhi batasan yang menerapkan pembatasan yang serupa dengan yang disebutkan sebelumnya.

Contoh migrasi menyeluruh

Bagian ini memberikan contoh file manifes target yang menyertakan semua batasan Pengontrol Kebijakan dan mutator yang Anda perlukan untuk memetakan SCC default OpenShift berikut di cluster GKE target Anda:

privileged
anyuid
nonroot
restricted

Pod mendapatkan batasan pengontrol kebijakan yang berbeda saat Anda memetakan kebijakan SCC yang ditetapkan di lingkungan OpenShift sumber, bergantung pada namespace tempat Pod dijalankan:

Workload yang memerlukan akses hak istimewa tertinggi, seperti kemampuan untuk berjalan dalam mode hak istimewa atau mengakses berbagai resource host, harus beroperasi dalam namespace yang dikecualikan. Namespace ini secara khusus diuraikan dalam konfigurasi Pengontrol Kebijakan.

Tidak ada batasan yang diterapkan ke namespace yang dikecualikan. Workload yang memiliki akses dengan hak istimewa tertinggi ini biasanya merupakan komponen sistem atau berbagai workload yang diterapkan SCC dengan hak istimewa di lingkungan OpenShift sumber.
Semua Pod yang dibuat di namespace yang tidak dikecualikan mendapatkan batasan paling ketat. Batasan ini menolak akses ke semua fitur host dan mengharuskan Pod untuk berjalan dengan UID yang merupakan bagian dari rentang tertentu. Konfigurasi ini cocok dengan kebijakan yang diterapkan oleh SCC yang restricted OpenShift. Pengecualian untuk konfigurasi ini mencakup hal berikut:
- Pod yang dibuat dalam namespace yang memiliki label security=anyuid mendapatkan batasan ketat sebelumnya, tetapi diizinkan untuk berjalan dengan berbagai UID dan GID. Cara ini cocok dengan batasan SCC anyuid pada OpenShift.
- Pod yang dibuat dalam namespace yang memiliki label security=nonroot akan mendapatkan batasan ketat sebelumnya. Namun, Pod diizinkan berjalan dengan segala UID non-root. Cara ini cocok dengan batasan SCC nonroot di OpenShift.

Contoh manifes target

Berikut adalah contoh manifes tunggal yang menyertakan sekumpulan batasan Pengontrol Kebijakan dan mutator yang cocok dengan perilaku yang dijelaskan dalam contoh migrasi menyeluruh sebelumnya. Sebaiknya tinjau dan sesuaikan batasan atau cakupannya dalam contoh ini berdasarkan kebutuhan organisasi Anda.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNamespace
metadata:
  name: psp-host-namespace
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPHostNetworkingPorts
metadata:
  name: psp-host-network-ports
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    hostNetwork: false
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: restricted-capabilities
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid"]
  location: "spec.containers[name:*].securityContext.capabilities.drop"
  parameters:
    assign:
      value: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: restricted-capabilities
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid"]
  parameters:
    requiredDropCapabilities: ["KILL","MKNOD","SYS_CHROOT"]
---
apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: anyuid-capabilities
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  match:
    scope: Namespaced
    kinds:
    - apiGroups: ["*"]
      kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["anyuid"]
  location: "spec.containers[name:*].securityContext.capabilities.drop"
  parameters:
    assign:
      value: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPCapabilities
metadata:
  name: anyuid-capabilities
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["anyuid"]
  parameters:
    requiredDropCapabilities: ["MKNOD"]
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: restricted-users-and-groups
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: NotIn
          key: security
          values: ["anyuid","nonroot"]
  parameters:
    runAsUser:
      rule: MustRunAs # MustRunAsNonRoot # RunAsAny
      ranges:
        - min: 1000
          max: 2000
    fsGroup:
      rule: MustRunAs # MayRunAs # RunAsAny
      ranges:
        - min: 1000
          max: 2000
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: nonroot-users-and-groups
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaceSelector:
      matchExpressions:
        - operator: In
          key: security
          values: ["nonroot"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot
    fsGroup:
      rule: MustRunAsNonRoot
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
  name: psp-volume-types
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    volumes:
      - configMap
      - downwardAPI
      - emptyDir
      - nfs
      - persistentVolumeClaim
      - projected
      - secret

Batasan restricted-users-and-groups dalam manifes contoh menggunakan template K8sPSPAllowedUsers agar secara eksplisit menetapkan rentang contoh 1000-2000 untuk parameter runAsUser: dan fsGroup:. Setiap Pod yang tidak ditetapkan untuk menggunakan ID dalam rentang tersebut, maka runAsUser: dan fsGroup: akan diblokir.

GKE Enterprise dan Kubernetes tidak menggunakan anotasi namespace untuk memutasikan Pod secara otomatis dengan ID pengguna atau grup tertentu. Oleh karena itu, untuk membatasi rentang UID seperti pada contoh sebelumnya, tim pengiriman aplikasi Anda harus secara eksplisit menetapkan UID yang sesuai pada pod yang dibuat, atau Anda harus sepenuhnya menghapus batasan untuk mengizinkan semua ID.

Berikut adalah contoh manifes Pod yang mematuhi batasan sebelumnya di namespace mana pun tempat Anda membuatnya (manifes sesuai dengan SCC restricted):

apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod-example
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 1100
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo

Langkah selanjutnya

Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.