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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html), [EFS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html), dan FSx [for](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html) 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](https://github.com/kubernetes-sigs/aws-ebs-csi-driver). Keduanya termasuk parameter untuk mengenkripsi volume dan memasok CMK. Untuk EFS, Anda dapat menggunakan [driver EFS CSI](https://github.com/kubernetes-sigs/aws-efs-csi-driver), 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](https://docs.aws.amazon.com/efs/latest/ug/encryption-at-rest.html) Istirahat. Selain menawarkan enkripsi saat istirahat, EFS dan FSx for Lustre menyertakan opsi untuk mengenkripsi data dalam perjalanan. FSx for 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:
```
[Driver FSx CSI](https://github.com/kubernetes-sigs/aws-fsx-csi-driver) 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:
```
**penting**
Per 28 Mei 2020 semua data yang ditulis ke volume fana di pod EKS Fargate dienkripsi secara default menggunakan algoritme kriptografi standar industri. AES-256 Tidak ada modifikasi pada aplikasi Anda yang diperlukan karena enkripsi dan dekripsi ditangani dengan mulus oleh layanan.
### 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 memutar CMK Anda secara otomatis. 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](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)
### 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.
**penting**
Per 23 Maret 2021 driver EFS CSI mendukung penyediaan dinamis EFS Access Points. Access point adalah titik masuk khusus aplikasi ke dalam sistem file EFS yang membuatnya lebih mudah untuk berbagi sistem file antara beberapa pod. Setiap sistem file EFS dapat memiliki hingga 120 PV. Lihat [Memperkenalkan penyediaan dinamis Amazon EFS CSI](https://aws.amazon.com/blogs/containers/introducing-efs-csi-dynamic-provisioning/) untuk informasi tambahan.
## 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.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html) 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/.
**Awas**
Rahasia dalam namespace tertentu dapat direferensikan oleh semua pod di namespace rahasia.
**Awas**
Node authorizer memungkinkan Kubelet untuk membaca semua rahasia yang dipasang ke node.
### 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](https://aws.amazon.com/blogs/containers/using-eks-encryption-provider-support-for-defense-in-depth/)
### 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](https://aws.amazon.com/secrets-manager/) Vault.](https://www.hashicorp.com/blog/injecting-vault-secrets-into-kubernetes-pods-via-a-sidecar/) 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](https://github.com/bitnami-labs/sealed-secrets) 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](https://aws.amazon.com/blogs/opensource/managing-secrets-deployment-in-kubernetes-using-sealed-secrets/) untuk informasi lebih lanjut.
Karena penggunaan toko rahasia eksternal telah berkembang, begitu juga kebutuhan untuk mengintegrasikannya dengan Kubernetes. [Secret Store CSI Driver](https://github.com/kubernetes-sigs/secrets-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](https://github.com/aws/secrets-store-csi-driver-provider-aws), 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.
**catatan**
Ketika driver CSI toko rahasia harus mengambil rahasia, ia mengasumsikan peran IRSA yang ditugaskan ke pod yang mereferensikan rahasia. Kode untuk operasi ini dapat ditemukan [di sini](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/auth/auth.go).
Untuk informasi tambahan tentang AWS Secrets & Configuration Provider (ASCP) lihat sumber daya berikut:
+ [Cara menggunakan AWS Secrets Configuration Provider dengan Kubernetes Secret Store CSI Driver](https://aws.amazon.com/blogs/security/how-to-use-aws-secrets-configuration-provider-with-kubernetes-secrets-store-csi-driver/)
+ [Mengintegrasikan rahasia Secrets Manager dengan Kubernetes Secrets Store CSI Driver](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_csi_driver.html)
[rahasia eksternal adalah](https://github.com/external-secrets/external-secrets) 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 Kubernetes-native cara tertentu.
## Alat dan sumber daya
+ [Lokakarya Perendaman Keamanan Amazon EKS - Enkripsi Data dan Manajemen Rahasia](https://catalog.workshops.aws/eks-security-immersionday/en-US/13-data-encryption-and-secret-management)