instruction: Provide Kubernetes YAML for configuration
output: ```yaml
  apiVersion: v1
   metadata:
   name: test-db-client-pod
   labels:
   name: test-db-client
   spec:
   volumes:
   - name: secret-volume
   secret:
   secretName: test-db-secret
   containers:
   - name: db-client-container
   image: myClientImage
   volumeMounts:
   - name: secret-volume
   readOnly: true
   mountPath: "/etc/secret-volume"
  EOF
  Tambahkan Pod-Pod terkait pada file kustomization.yaml yang sama$ cat <<EOF >> kustomization.yaml
  resources:
  - pod.yaml
  EOF
  Terapkan semua perubahan pada objek-objek tadi ke Apiserver dengan menggunakankubectl apply --k .
  Kedua container kemudian akan memiliki file-file berikut ini di dalam
  filesystem keduanya dengan value sebagai berikut untuk masing-masing environment:/etc/secret-volume/username
  /etc/secret-volume/password
  Perhatikan bahwa specs untuk kedua pod berbeda hanya pada satu field saja;
  hal ini bertujuan untuk memfasilitasi adanya kapabilitas yang berbeda dari templat
  konfigurasi umum yang tersedia.Kamu dapat mensimplifikasi spesifikasi dasar Pod dengan menggunakan dua buah service account yang berbeda:
  misalnya saja salah satunya disebut sebagai prod-user dengan prod-db-secret, dan satunya lagi disebut
  test-user dengan test-db-secret. Kemudian spesifikasi Pod tadi dapat diringkas menjadi:apiVersion: v1
  kind: Pod
  metadata:
   name: prod-db-client-pod
   labels:
   name: prod-db-client
  spec:
   serviceAccount: prod-db-client
   containers:
   - name: db-client-container
   image: myClientImage
  Contoh Penggunaan: Dotfiles pada volume secretDengan tujuan membuat data yang ada 'tersembunyi' (misalnya, di dalam sebuah file dengan nama yang dimulai
  dengan karakter titik), kamu dapat melakukannya dengan cara yang cukup sederhana, yaitu cukup dengan membuat
  karakter awal key yang kamu inginkan dengan titik. Contohnya, ketika sebuah secret di bawah ini di-mount
  pada sebuah volume:apiVersion: v1
  kind: Secret
  metadata:
   name: dotfile-secret
  data:
   .secret-file: dmFsdWUtMg0KDQo=
  ---
  apiVersion: v1
  kind: Pod
  metadata:
   name: secret-dotfiles-pod
  spec:
   volumes:
   - name: secret-volume
   secret:
   secretName: dotfile-secret
   containers:
   - name: dotfile-test-container
   image: registry.k8s.io/busybox
   command:
   - ls
   - "-l"
   - "/etc/secret-volume"
   volumeMounts:
   - name: secret-volume
   readOnly: true
   mountPath: "/etc/secret-volume"
  Volume secret-volume akan mengandung sebuah file, yang disebut sebagai .secret-file, serta
  container dotfile-test-container akan memiliki file konfigurasinya pada path
  /etc/secret-volume/.secret-file.Catatan:File-file yang diawali dengan karakter titik akan "tersembunyi" dari keluaran perintah ls -l;
  kamu harus menggunakan perintah ls -la untuk melihat file-file tadi dari sebuah direktori.Contoh Penggunaan: Secret yang dapat diakses hanya pada salah satu container di dalam podMisalkan terdapat sebuah program yang memiliki kebutuhan untuk menangani request HTTP,
  melakukan logika bisnis yang kompleks, serta kemudian menandai beberapa message yang ada
  dengan menggunakan HMAC. Karena program ini memiliki logika aplikasi yang cukup kompleks,
  maka bisa jadi terdapat beberapa celah terjadinya eksploitasi remote file pada server,
  yang nantinya bisa saja mengekspos private key yang ada pada attacker.Hal ini dapat dipisah menjadi dua buah proses yang berbeda di dalam dua container:
  sebuah container frontend yang menangani interaksi pengguna dan logika bisnis, tetapi
  tidak memiliki kapabilitas untuk melihat private key; container lain memiliki kapabilitas
  melihat private key yang ada dan memiliki fungsi untuk menandai request yang berasal
  dari frontend (melalui jaringan localhost).Dengan strategi ini, seorang attacker harus melakukan teknik tambahan
  untuk memaksa aplikasi melakukan hal yang acak, yang kemudian menyebabkan
  mekanisme pembacaan file menjadi lebih susah.Best practicesKlien yang menggunakan API secretKetika men-deploy aplikasi yang berinteraksi dengan API secret, akses yang dilakukan
  haruslah dibatasi menggunakan policy autorisasi seperti RBAC.Secret seringkali menyimpan value yang memiliki jangkauan spektrum
  kepentingan, yang mungkin saja dapat menyebabkan terjadinya eskalasi baik
  di dalam Kubernetes (misalnya saja token dari sebuah service account) maupun
  sistem eksternal. Bahkan apabila setiap aplikasi secara individual memiliki
  kapabilitas untuk memahami tingkatan yang dimilikinya untuk berinteraksi dengan secret tertentu,
  aplikasi lain dalam namespace itu bisa saja menyebabkan asumsi tersebut menjadi tidak valid.Karena alasan-alasan yang sudah disebutkan tadi request watch dan list untuk sebuah
  secret di dalam suatu namespace merupakan kapabilitas yang sebisa mungkin harus dihindari,
  karena menampilkan semua secret yang ada berimplikasi pada akses untuk melihat isi yang ada
  pada secret yang ada. Kapabilitas untuk melakukan request watch dan list pada semua secret di klaster
  hanya boleh dimiliki oleh komponen pada sistem level yang paling previleged.Aplikasi yang membutuhkan akses ke API secret harus melakukan request get pada
  secret yang dibutuhkan. Hal ini memungkinkan administrator untuk membatasi
  akses pada semua secret dengan tetap memberikan akses pada instans secret tertentu
  yang dibutuhkan aplikasi.Untuk meningkatkan performa dengan menggunakan iterasi get, klien dapat mendesain
  sumber daya yang merujuk pada suatu secret dan kemudian melakukan watch pada secret tersebut,
  serta melakukan request secret ketika terjadi perubahan pada rujukan tadi. Sebagai tambahan, API "bulk watch"
  yang dapat memberikan kapabilitas watch individual pada sumber daya melalui klien juga sudah direncanakan,
  dan kemungkinan akan diimplementasikan dirilis Kubernetes selanjutnya.Properti KeamananProteksiKarena objek secret dapat dibuat secara independen dengan pod yang menggunakannya,
  risiko tereksposnya secret di dalam workflow pembuatan, pemantauan, serta pengubahan pod.
  Sistem yang ada juga dapat memberikan tindakan pencegahan ketika berinteraksi dengan secret,
  misalnya saja tidak melakukan penulisan isi secret ke dalam disk apabila hal tersebut
  memungkinkan.Sebuah secret hanya diberikan pada node apabila pod yang ada di dalam node
  membutuhkan secret tersebut. Kubelet menyimpan secret yang ada pada tmpfs
  sehingga secret tidak ditulis pada disk. Setelah pod yang bergantung pada secret tersebut dihapus,
  maka kubelet juga akan menghapus salinan lokal data secret.Di dalam sebuah node bisa saja terdapat beberapa secret yang dibutuhkan
  oleh pod yang ada di dalamnya. Meskipun demikian, hanya secret yang di-request
  oleh sebuah pod saja yang dapat dilihat oleh container yang ada di dalamnya.
  Dengan demikian, sebuah Pod tidak memiliki akses untuk melihat secret yang ada
  pada pod yang lain.Di dalam sebuah pod bisa jadi terdapat beberapa container.
  Meskipun demikian, agar sebuah container bisa mengakses volume secret, container
  tersebut haruslah mengirimkan request volumeMounts yang ada dapat diakses dari
  container tersebut. Pengetahuan ini dapat digunakan untuk membentuk partisi security
  pada level pod.Pada sebagian besar distribusi yang dipelihara projek Kubernetes,
  komunikasi antara pengguna dan apiserver serta apisserver dan kubelet dilindungi dengan menggunakan SSL/TLS.
  Dengan demikian, secret dalam keadaan dilindungi ketika ditransmisi.FEATURE STATE:
  Kubernetes v1.13 [beta]Kamu dapat mengaktifkan enkripsi pada rest
  untuk data secret, sehingga secret yang ada tidak akan ditulis ke dalam etcd
  dalam keadaan tidak terenkripsi.ResikoPada API server, data secret disimpan di dalam etcd;
  dengan demikian:Administrator harus mengaktifkan enkripsi pada rest untuk data klaster (membutuhkan versi v1.13 atau lebih)Administrator harus membatasi akses etcd pada pengguna dengan kapabilitas adminAdministrator bisa saja menghapus data disk yang sudah tidak lagi digunakan oleh etcdJika etcd dijalankan di dalam klaster, administrator harus memastikan SSL/TLS
  digunakan pada proses komunikasi peer-to-peer etcd.Jika kamu melakukan konfigurasi melalui sebuah file manifest (JSON or YAML)
  yang menyimpan data secret dalam bentuk base64, membagi atau menyimpan secret ini
  dalam repositori kode sumber sama artinya dengan memberikan informasi mengenai data secret.
  Mekanisme encoding base64 bukanlah merupakan teknik enkripsi dan nilainya dianggap sama saja dengan plain text.Aplikasi masih harus melindungi value dari secret setelah membaca nilainya dari suatu volume
  dengan demikian risiko terjadinya logging secret secara tidak engaja dapat dihindari.Seorang pengguna yang dapat membuat suatu pod yang menggunakan secret, juga dapat melihat value secret.
  Bahkan apabila policy apiserver tidak memberikan kapabilitas untuk membaca objek secret, pengguna
  dapat menjalankan pod yang mengekspos secret.Saat ini, semua orang dengan akses root pada node dapat membaca secret apapun dari apiserver,
  dengan cara meniru kubelet. Meskipun begitu, terdapat fitur yang direncanakan pada rilis selanjutnya yang memungkinkan pengiriman secret hanya dapat
  mengirimkan secret pada node yang membutuhkan secret tersebut untuk membatasi adanya eksploitasi akses root pada node ini.SelanjutnyaMasukanApakah halaman ini membantu?Ya
  TidakTerima kasih atas masukannya. Jika kamu mempunyai pertanyaan yang spesifik terkait bagaimana menggunakan Kubernetes, tanyakanlah di
  Stack Overflow.
  Buat isu di repositori GitHub jika kamu ingin
  laporkan problem
  atau
  beri saran perbaikan.Last modified March 29, 2025 at 11:53 AM PST: fix: standardizing word 'klaster' outside glossary (b452fb2ffd)  Create child page
   Buat isu
   Print entire sectionIkhtisar SecretSecret Built-inMembuat Objek Secret Kamu SendiriMenggunakan SecretMenggunakan Secret sebagai File melalui PodMenggunakan Secret sebagai Variabel EnvironmentMenggunakan imagePullSecretsMekanisme yang Dapat Diterapkan agar imagePullSecrets dapat Secara Otomatis DigunakanMekanisme Mounting Otomatis dari Secret yang Sudah DibuatDetailBatasan-BatasanInteraksi Secret dan Pod LifetimeContoh-Contoh PenggunaanContoh Penggunaan: Pod dengan ssh keyContoh Penggunaan: Pod dengan kredensial prod / testContoh Penggunaan: Dotfiles pada volume secretContoh Penggunaan: Secret yang dapat diakses hanya pada salah satu container di dalam podBest practicesKlien yang menggunakan API secretProperti KeamananProteksiResikoSelanjutnya© 2025 Para Pencipta Kubernetes | Dokumentasi didistribusikan di bawah CC BY 4.0© 2025 Linux Foundation ®. Hak cipta dilindungi. Linux Foundation telah mendaftarkan merek dagang dan pengunaannya. Perinciannya bisa dilihat pada halaman penggunaan merek dagangICP license: 京ICP备17074266号-3
  ```