Amankan Kubernetes dengan AWS Private CA - AWS Private Certificate Authority
Penggunaan cross-account dari cert-managerTemplat sertifikat yang didukung Contoh solusi

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

Amankan Kubernetes dengan AWS Private CA

Kontainer dan aplikasi Kubernetes menggunakan sertifikat digital untuk menyediakan autentikasi dan enkripsi yang aman melalui TLS. Solusi yang diadopsi secara luas untuk manajemen siklus hidup sertifikat TLS di Kubernetes adalah cert-manager, add-on untuk Kubernetes yang meminta sertifikat, mendistribusikannya ke container Kubernetes, dan mengotomatiskan pembaruan sertifikat.

AWS Private CA menyediakan plug-in open-source ke cert-manager, aws-privateca-issuer, untuk pengguna cert-manager yang ingin menyiapkan CA tanpa menyimpan kunci pribadi di cluster. Pengguna dengan persyaratan peraturan untuk mengontrol akses ke dan mengaudit operasi CA mereka dapat menggunakan solusi ini untuk meningkatkan auditabilitas dan mendukung kepatuhan. Anda dapat menggunakan plugin AWS Private CA Issuer dengan Amazon Elastic Kubernetes Service (Amazon EKS), Kubernetes yang AWS dikelola sendiri, atau di Kubernetes lokal. Anda dapat menggunakan plug-in dengan arsitektur x86 dan ARM.

Diagram di bawah ini menunjukkan beberapa opsi yang tersedia untuk menggunakan TLS di cluster Amazon EKS. Klaster contoh ini, yang berisi berbagai sumber daya, terletak di belakang penyeimbang beban. Angka-angka tersebut mengidentifikasi titik akhir yang mungkin untuk komunikasi yang diamankan dengan TLS, termasuk penyeimbang beban eksternal, pengendali ingress, pod individu dalam layanan, dan sepasang pod yang berkomunikasi secara aman satu sama lain.

Topologi Kubernetes yang disederhanakan

  1. Penghentian di penyeimbang beban.

    Elastic Load Balancing (ELB) adalah layanan AWS Certificate Manager terintegrasi, yang berarti Anda dapat menyediakan ACM dengan CA pribadi, menandatangani sertifikat dengannya, dan menginstalnya menggunakan konsol ELB. Solusi ini menyediakan komunikasi terenkripsi antara klien jarak jauh dan penyeimbang beban. Data diteruskan tanpa dienkripsi ke klaster EKS. Atau, Anda dapat memberikan sertifikat pribadi ke penyeimbang AWS non-beban untuk mengakhiri TLS.

  2. Penghentian pada pengontrol ingress Kubernetes.

    Pengendali ingress berada di dalam klaster EKS sebagai penyeimbang beban asli dan router. Jika Anda telah menginstal cert-manager dan aws-privateca-issuer, dan menyediakan klaster dengan CA pribadi, Kubernetes dapat menginstal sertifikat TLS yang ditandatangani pada pengontrol, yang memungkinkannya berfungsi sebagai titik akhir klaster untuk komunikasi eksternal. Komunikasi antara penyeimbang beban dan pengendali ingress dienkripsi, dan setelah ingress, data melewati tanpa terenkripsi ke sumber daya klaster.

  3. Penghentian di pod.

    Setiap pod adalah grup dari satu atau lebih kontainer yang berbagi penyimpanan dan sumber daya jaringan. Jika Anda telah menginstal cert-manager dan aws-privateca-issuer, dan menyediakan klaster dengan CA pribadi, Kubernetes dapat menginstal sertifikat TLS yang ditandatangani pada pod sesuai kebutuhan. Koneksi TLS yang berakhir pada pod tidak tersedia secara default untuk pod lain dalam klaster.

  4. Mengamankan komunikasi antar pod.

    Anda juga dapat menyediakan beberapa pod dengan sertifikat yang memungkinkan mereka untuk berkomunikasi satu sama lain. Skenario berikut ini mungkin terjadi:

    • Penyediaan dengan sertifikat yang ditandatangani sendiri dan dibuat oleh Kubernetes. Ini mengamankan komunikasi antar pod, tetapi sertifikat yang ditandatangani sendiri tidak memenuhi persyaratan HIPAA atau FIPS.

    • Penyediaan dengan sertifikat yang ditandatangani oleh CA privat. Seperti pada angka 2 dan 3 di atas, ini memerlukan pemasangan cert-manager dan aws-privateca-issuer, dan menyediakan cluster dengan CA pribadi. Kubernetes kemudian dapat menginstal sertifikat TLS yang ditandatangani pada pod sesuai kebutuhan.

Penggunaan cross-account dari cert-manager

Administrator dengan akses lintas akun ke CA dapat menggunakan cert-manager untuk menyediakan klaster Kubernetes. Untuk informasi selengkapnya, lihat Praktik terbaik keamanan untuk akses lintas akun ke pribadi CAs.

catatan

Hanya templat AWS Private CA sertifikat tertentu yang dapat digunakan dalam skenario lintas akun. Lihat Templat sertifikat yang didukung daftar templat yang tersedia.

Templat sertifikat yang didukung

Tabel berikut mencantumkan AWS Private CA template yang dapat digunakan dengan cert-manager untuk menyediakan klaster Kubernetes.

Template yang didukung untuk Kubernetes Support untuk penggunaan lintas akun
BlankEndEntityCertificate_ CSRPassthrough /V1 definisi
CodeSigningCertificate/V1 definisi
EndEntityCertificate/V1 definisi ✓
EndEntityClientAuthCertificate/V1 definisi ✓
EndEntityServerAuthCertificate/V1 definisi ✓
OCSPSigningDefinisi sertifikat/V1

Contoh solusi

Solusi integrasi berikut menunjukkan cara mengonfigurasi akses ke klaster AWS Private CA Amazon EKS.