Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Enkripsi data dan manajemen rahasia

Enkripsi saat diam

Ada tiga opsi AWS-native penyimpanan berbeda yang dapat Anda gunakan dengan Kubernetes: EBS, EFS, dan FSx for Lustre. Ketiganya menawarkan enkripsi at rest menggunakan kunci terkelola layanan atau kunci master pelanggan (CMK). Untuk EBS, Anda dapat menggunakan driver penyimpanan in-tree atau driver EBS CSI. Keduanya menyertakan parameter untuk mengenkripsi volume dan memasok CMK. Untuk EFS, Anda dapat menggunakan driver EFS CSI, namun, tidak seperti EBS, driver EFS CSI tidak mendukung penyediaan dinamis. Jika Anda ingin menggunakan EFS dengan EKS, Anda perlu menyediakan dan mengkonfigurasi enkripsi diam untuk sistem file sebelum membuat PV. Untuk informasi lebih lanjut tentang enkripsi file EFS, silakan lihat Enkripsi Data saat Istirahat. Selain menawarkan enkripsi saat istirahat, EFS dan FSx for Lustre menyertakan opsi untuk mengenkripsi data dalam transit. FSx for Lustre melakukan ini secara default. Untuk EFS, Anda dapat menambahkan enkripsi transportasi dengan menambahkan tls parameter ke mountOptions dalam PV Anda seperti dalam contoh ini:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  mountOptions:
    - tls
  csi:
    driver: efs.csi.aws.com
    volumeHandle: <file_system_id>

Driver FSx CSI mendukung penyediaan dinamis sistem file Lustre. Ini mengenkripsi data dengan kunci yang dikelola layanan secara default, meskipun ada opsi untuk menyediakan CMK Anda sendiri seperti dalam contoh ini:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: fsx-sc
provisioner: fsx.csi.aws.com
parameters:
  subnetId: subnet-056da83524edbe641
  securityGroupIds: sg-086f61ea73388fb6b
  deploymentType: PERSISTENT_1
  kmsKeyId: <kms_arn>

Enkripsi data saat istirahat

Mengenkripsi data saat istirahat dianggap sebagai praktik terbaik. Jika Anda tidak yakin apakah enkripsi diperlukan, enkripsi data Anda.

Putar CMK Anda secara berkala

Konfigurasikan KMS untuk secara otomatis memutar CMKs Anda. Ini akan memutar kunci Anda setahun sekali sambil menyimpan kunci lama tanpa batas sehingga data Anda masih dapat didekripsi. Untuk informasi tambahan, lihat Mem utar kunci utama pelanggan

Gunakan titik akses EFS untuk menyederhanakan akses ke kumpulan data bersama

Jika Anda telah berbagi kumpulan data dengan izin file POSIX yang berbeda atau ingin membatasi akses ke bagian dari sistem file bersama dengan membuat titik pemasangan yang berbeda, pertimbangkan untuk menggunakan titik akses EFS. Untuk mempelajari lebih lanjut tentang bekerja dengan titik akses, lihat https://docs.aws.amazon.com/efs/latest/ug/efs-access-points.html. Hari ini, jika Anda ingin menggunakan titik akses (AP), Anda harus mereferensikan AP dalam volumeHandle parameter PV.

Manajemen rahasia

Rahasia Kubernetes digunakan untuk menyimpan informasi sensitif, seperti sertifikat pengguna, kata sandi, atau kunci API. Mereka bertahan di etcd sebagai string yang dikodekan base64. Pada EKS, volume EBS untuk node etcd dienkripsi dengan enkripsi EBS. Pod dapat mengambil objek rahasia Kubernetes dengan mereferensikan rahasia di. podSpec Rahasia ini dapat dipetakan ke variabel lingkungan atau dipasang sebagai volume. Untuk informasi tambahan tentang membuat rahasia, lihat https://kubernetes.io/docs/concepts/configuration/secret/.

Gunakan AWS KMS untuk enkripsi amplop rahasia Kubernetes

Ini memungkinkan Anda untuk mengenkripsi rahasia Anda dengan kunci enkripsi data unik (DEK). DEK kemudian dienkripsi menggunakan kunci enkripsi kunci (KEK) dari AWS KMS yang dapat diputar secara otomatis pada jadwal berulang. Dengan plugin KMS untuk Kubernetes, semua rahasia Kubernetes disimpan di etcd dalam ciphertext alih-alih teks biasa dan hanya dapat didekripsi oleh server API Kubernetes. Untuk detail tambahan, lihat menggunakan dukungan penyedia enkripsi EKS untuk pertahanan secara mendalam

Mengaudit penggunaan Rahasia Kubernetes

Di EKS, aktifkan pencatatan audit dan buat filter CloudWatch metrik dan alarm untuk mengingatkan Anda ketika rahasia digunakan (opsional). Berikut ini adalah contoh filter metrik untuk log audit Kubernetes,. {($.verb="get") && ($.objectRef.resource="secret")} Anda juga dapat menggunakan kueri berikut dengan CloudWatch Log Insights:

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| stats count(*) by objectRef.name as secret
| filter verb="get" and objectRef.resource="secrets"

Kueri di atas akan menampilkan berapa kali rahasia telah diakses dalam jangka waktu tertentu.

fields @timestamp, @message
| sort @timestamp desc
| limit 100
| filter verb="get" and objectRef.resource="secrets"
| display objectRef.namespace, objectRef.name, user.username, responseStatus.code

Kueri ini akan menampilkan rahasia, bersama dengan namespace dan nama pengguna yang mencoba mengakses rahasia dan kode respons.

Putar rahasia Anda secara berkala

Kubernetes tidak secara otomatis memutar rahasia. Jika Anda harus merotasi rahasia, pertimbangkan untuk menggunakan penyimpanan rahasia eksternal, misalnya Vault atau AWS Secrets Manager.

Gunakan ruang nama terpisah sebagai cara untuk mengisolasi rahasia dari aplikasi yang berbeda

Jika Anda memiliki rahasia yang tidak dapat dibagikan antar aplikasi dalam namespace, buat namespace terpisah untuk aplikasi tersebut.

Gunakan dudukan volume alih-alih variabel lingkungan

Nilai variabel lingkungan dapat secara tidak sengaja muncul di log. Rahasia yang dipasang sebagai volume diinstansiasikan sebagai volume tmpfs (sistem file yang didukung RAM) yang secara otomatis dihapus dari node saat pod dihapus.

Gunakan penyedia rahasia eksternal

Ada beberapa alternatif yang layak untuk menggunakan rahasia Kubernetes, termasuk AWS Secrets Manager dan Hashicorp's Vault. https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/ Layanan ini menawarkan fitur-fitur seperti kontrol akses halus, enkripsi yang kuat, dan rotasi rahasia otomatis yang tidak tersedia dengan Kubernetes Secrets. Rahasia Ter segel Bitnami adalah pendekatan lain yang menggunakan enkripsi asimetris untuk membuat “rahasia tersegel”. Kunci publik digunakan untuk mengenkripsi rahasia sementara kunci pribadi yang digunakan untuk mendekripsi rahasia disimpan di dalam cluster, memungkinkan Anda untuk menyimpan rahasia tertutup dengan aman di sistem kontrol sumber seperti Git. Lihat M engelola penyebaran rahasia di Kubernetes menggunakan Sealed Secrets untuk informasi lebih lanjut.

Seiring dengan meningkatnya penggunaan toko rahasia eksternal, maka kebutuhan untuk mengintegrasikannya dengan Kubernetes. The Secret Store CSI Driver adalah proyek komunitas yang menggunakan model driver CSI untuk mengambil rahasia dari toko rahasia eksternal. Saat ini, Driver memiliki dukungan untuk AWS Secrets Manager, Azure, Vault, dan GCP. Penyedia AWS mendukung AWS Secrets Manager dan AWS Parameter Store. Ini juga dapat dikonfigurasi untuk memutar rahasia saat kedaluwarsa dan dapat menyinkronkan rahasia AWS Secrets Manager ke Rahasia Kubernetes. Sinkronisasi rahasia dapat berguna ketika Anda perlu mereferensikan rahasia sebagai variabel lingkungan alih-alih membacanya dari volume.

Untuk informasi tambahan tentang AWS Secrets & Configuration Provider (ASCP), lihat sumber daya berikut:

external-secret adalah cara lain untuk menggunakan toko rahasia eksternal dengan Kubernetes. Seperti Driver CSI, rahasia eksternal bekerja melawan berbagai backend yang berbeda, termasuk AWS Secrets Manager. Perbedaannya adalah, alih-alih mengambil rahasia dari toko rahasia eksternal, rahasia eksternal menyalin rahasia dari backend ini ke Kubernetes sebagai Rahasia. Ini memungkinkan Anda mengelola rahasia menggunakan toko rahasia pilihan Anda dan berinteraksi dengan rahasia dengan Kubernetes-native cara tertentu.

Alat dan sumber daya