Praktik terbaik enkripsi untuk Amazon EKS - AWS Panduan Preskriptif

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

Praktik terbaik enkripsi untuk Amazon EKS

Amazon Elastic Kubernetes Service (Amazon EKS) membantu Anda menjalankan AWS Kubernetes tanpa perlu menginstal atau memelihara control plane atau node Kubernetes Anda sendiri. Di Kubernetes, rahasia membantu Anda mengelola informasi sensitif, seperti sertifikat pengguna, kata sandi, atau kunci API. Secara default, rahasia ini disimpan tanpa terenkripsi di penyimpanan data dasar server API, yang disebut etcd. Di Amazon EKS, volume Amazon Elastic Block Store (Amazon EBS) etcd untuk node dienkripsi dengan enkripsi Amazon EBS. Setiap pengguna dengan akses API atau akses ke etcd dapat mengambil atau memodifikasi rahasia. Selain itu, siapa pun yang berwenang untuk membuat pod di namespace dapat menggunakan akses itu untuk membaca rahasia apa pun di namespace itu. Anda dapat mengenkripsi rahasia ini saat istirahat di Amazon EKS dengan menggunakan AWS KMS keys, baik kunci AWS terkelola atau kunci yang dikelola pelanggan. Pendekatan alternatif untuk menggunakan etcd adalah menggunakan AWS Secrets and Config Provider (ASCP) (GitHub repositori). ASCP terintegrasi dengan IAM dan kebijakan berbasis sumber daya untuk membatasi dan membatasi akses ke rahasia hanya dalam pod Kubernetes tertentu di dalam klaster.

Anda dapat menggunakan layanan AWS penyimpanan berikut dengan Kubernetes:

  • Untuk Amazon EBS, Anda dapat menggunakan driver penyimpanan in-tree atau driver Amazon EBS CSI. Keduanya mencakup parameter untuk mengenkripsi volume dan memasok kunci yang dikelola pelanggan.

  • Untuk Amazon Elastic File System (Amazon EFS), Anda dapat menggunakan driver Amazon EFS CSI dengan dukungan untuk penyediaan dinamis dan statis.

Pertimbangkan praktik terbaik enkripsi berikut untuk layanan ini:

  • Jika Anda menggunakanetcd, yang menyimpan objek rahasia yang tidak dienkripsi secara default, lakukan hal berikut untuk membantu melindungi rahasia:

    • Enkripsi data rahasia saat istirahat (dokumentasi Kubernetes).

    • Gunakan AWS KMS untuk enkripsi amplop rahasia Kubernetes. Ini memungkinkan Anda untuk mengenkripsi rahasia Anda dengan kunci data yang unik. Anda dapat menggunakan AWS KMS kunci enkripsi kunci untuk mengenkripsi kunci data. Anda dapat secara otomatis memutar kunci enkripsi kunci pada jadwal berulang. Dengan AWS KMS plugin untuk Kubernetes, semua rahasia Kubernetes disimpan dalam ciphertext. etcd Mereka hanya dapat didekripsi oleh server API Kubernetes. Untuk informasi selengkapnya, lihat Menggunakan dukungan penyedia enkripsi Amazon EKS untuk pertahanan secara mendalam dan Mengenkripsi rahasia Kubernetes dengan AWS KMS klaster yang ada.

    • Aktifkan atau konfigurasikan otorisasi melalui aturan kontrol akses berbasis peran (RBAC) yang membatasi membaca dan menulis rahasia. Batasi izin untuk membuat rahasia baru atau mengganti yang sudah ada. Untuk informasi selengkapnya, lihat Ikhtisar otorisasi (dokumentasi Kubernetes).

    • Jika Anda mendefinisikan beberapa kontainer dalam sebuah pod dan hanya satu dari kontainer tersebut yang membutuhkan akses ke rahasia, tentukan volume mount sehingga container lain tidak memiliki akses ke rahasia itu. Rahasia yang dipasang sebagai volume dipakai sebagai tmpfs volume dan secara otomatis dihapus dari node saat pod dihapus. Anda juga dapat menggunakan variabel lingkungan, tetapi kami tidak merekomendasikan pendekatan ini karena nilai variabel lingkungan dapat muncul di log. Untuk informasi selengkapnya, lihat Rahasia (dokumentasi Kubernetes).

    • Jika memungkinkan, hindari pemberian akses ke watch dan list permintaan rahasia dalam namespace. Di Kubernetes API, permintaan ini sangat kuat karena memungkinkan klien untuk memeriksa nilai setiap rahasia di namespace tersebut.

    • Izinkan hanya administrator klaster untuk mengaksesetcd, termasuk akses hanya-baca.

    • Jika ada beberapa etcd contoh, pastikan etcd menggunakan TLS untuk komunikasi antar etcd rekan.

  • Jika Anda menggunakan ASCP, lakukan hal berikut untuk membantu melindungi rahasia:

    • Gunakan peran IAM untuk akun layanan untuk membatasi akses rahasia hanya ke pod yang diotorisasi.

    • Aktifkan enkripsi rahasia Kubernetes dengan menggunakan Penyedia AWS Enkripsi (GitHub repositori) untuk mengimplementasikan enkripsi amplop dengan kunci KMS yang dikelola pelanggan.

  • Untuk membantu mengurangi risiko kebocoran data dari variabel lingkungan, kami sarankan Anda menggunakan dan AWS Secrets Manager Config Provider for Secret Store CSI Driver (). GitHub Driver ini memungkinkan Anda untuk membuat rahasia yang disimpan di Secrets Manager dan parameter yang disimpan di Parameter Store muncul sebagai file yang dipasang di pod Kubernetes.

    catatan

    AWS Fargate tidak didukung.

  • Buat filter CloudWatch metrik Amazon dan alarm untuk mengirim peringatan untuk operasi yang ditentukan administrator, seperti penghapusan rahasia atau penggunaan versi rahasia dalam masa tunggu yang akan dihapus. Untuk informasi selengkapnya, lihat Membuat alarm berdasarkan deteksi anomali.