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 diam

Ada tiga opsi penyimpanan asli AWS yang berbeda yang dapat Anda gunakan dengan Kubernetes: EBS, EFS, dan untuk Lustre. FSx 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 termasuk 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 mengonfigurasi enkripsi saat istirahat untuk sistem file sebelum membuat PV. Untuk informasi lebih lanjut tentang enkripsi file EFS, silakan merujuk ke Enkripsi Data saat Istirahat. Selain menawarkan enkripsi saat istirahat, EFS dan FSx Lustre menyertakan opsi untuk mengenkripsi data dalam perjalanan. FSx untuk Lustre melakukan ini secara default. Untuk EFS, Anda dapat menambahkan enkripsi transport 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 Anda CMKs secara berkala

Konfigurasikan KMS untuk memutar secara otomatis. CMKs Ini akan memutar kunci Anda setahun sekali sambil menyimpan kunci lama tanpa batas waktu sehingga data Anda masih dapat didekripsi. Untuk informasi tambahan lihat Memutar kunci master 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 dalam etcd sebagai string yang dikodekan base64. Pada EKS, volume EBS untuk node etcd dienkripsi dengan enkripsi EBS. Sebuah 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 dalam 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

Audit penggunaan Rahasia Kubernetes

Pada EKS, aktifkan pencatatan audit dan buat filter CloudWatch metrik dan alarm untuk mengingatkan Anda saat 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 Wawasan CloudWatch Log:

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

Query 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 pengguna yang mencoba mengakses rahasia dan kode respons.

Putar rahasia Anda secara berkala

Kubernetes tidak secara otomatis memutar rahasia. Jika Anda harus memutar rahasia, pertimbangkan untuk menggunakan toko 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 dibagi antara aplikasi dalam namespace, buat namespace terpisah untuk aplikasi tersebut.

Gunakan volume mount alih-alih variabel lingkungan

Nilai variabel lingkungan dapat secara tidak sengaja muncul di log. Rahasia yang dipasang sebagai volume dipakai 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. Layanan ini menawarkan fitur-fitur seperti kontrol akses berbutir halus, enkripsi yang kuat, dan rotasi otomatis rahasia yang tidak tersedia dengan Rahasia Kubernetes. Rahasia Tertutup Bitnami adalah pendekatan lain yang menggunakan enkripsi asimetris untuk membuat “rahasia tertutup”. Kunci publik digunakan untuk mengenkripsi rahasia sementara kunci pribadi yang digunakan untuk mendekripsi rahasia disimpan di dalam cluster, memungkinkan Anda untuk menyimpan rahasia yang disegel dengan aman dalam sistem kontrol sumber seperti Git. Lihat Mengelola penyebaran rahasia di Kubernetes menggunakan Rahasia Tertutup untuk informasi lebih lanjut.

Karena penggunaan toko rahasia eksternal telah berkembang, begitu juga kebutuhan untuk mengintegrasikannya dengan Kubernetes. 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 ketika mereka kedaluwarsa dan dapat menyinkronkan rahasia AWS Secrets Manager ke Rahasia Kubernetes. Sinkronisasi rahasia dapat berguna ketika Anda perlu merujuk rahasia sebagai variabel lingkungan alih-alih membacanya dari volume.

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

rahasia eksternal 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, daripada 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 cara asli Kubernetes.

Alat dan sumber daya