Bantu meningkatkan halaman ini

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

Untuk berkontribusi pada panduan pengguna ini, pilih GitHub tautan Edit halaman ini di yang terletak di panel kanan setiap halaman.

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

Putar otoritas sertifikat cluster EKS (CA)

Dalam infrastruktur kunci publik (PKI), otoritas sertifikat (CA) adalah entitas tepercaya yang mengeluarkan dan menandatangani sertifikat digital. Sertifikat ini menetapkan identitas dan memungkinkan komunikasi terenkripsi antar sistem menggunakan TLS (Transport Layer Security). Ketika klien terhubung ke server, server menyajikan sertifikat yang ditandatangani oleh CA. Klien memverifikasi sertifikat server terhadap CA yang dipercayainya sebelum mengizinkan koneksi dilanjutkan.

Di Amazon Elastic Kubernetes Service (Amazon EKS), CA dibuat untuk setiap cluster EKS pada saat pembuatan cluster. Ini mengikuti model yang sama dengan Kubernetes hulu: setiap cluster EKS memiliki CA sendiri yang menandatangani sertifikat untuk server API. Inilah yang memungkinkan komponen bidang kontrol, node pekerja, dan klien untuk mengotentikasi ke server API dan membuat koneksi terenkripsi ke cluster EKS.

Otoritas sertifikat (CA) ini memiliki periode validitas yang ditentukan. Rotasi CA adalah proses penggantian otoritas sertifikat cluster EKS Anda sebelum kedaluwarsa, memastikan cluster Anda tetap operasional dan dapat diakses. Kami memiliki perlindungan bawaan yang secara otomatis mengelola proses ini. Jika Anda tidak memulai rotasi CA sendiri, kami akan secara otomatis menambahkan CA penerus dan mengaktifkannya sebelum CA keluar berakhir, memastikan cluster Anda tetap tersedia.

Selama rotasi CA, CA penerus ditambahkan ke cluster EKS Anda. EKS mendistribusikan CA penerus ke semua komponen yang AWS dikelola (bidang kontrol, instans Mode Otomatis EKS, dan node AWS Fargate) secara otomatis. Anda bertanggung jawab untuk memperbarui node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal (seperti file dan CI/CD pipeline kubeconfig) untuk mempercayai CA penerus sebelum diaktifkan. Setelah CA penerus diaktifkan, klaster EKS beralih ke penandatanganan sertifikat dengan CA penerus. CA yang keluar kemudian pensiun.

Rotasi CA diperlukan untuk setiap cluster EKS karena CA memiliki masa validitas yang terbatas. Periode validitas tergantung pada kapan CA cluster dibuat. Untuk detail lebih lanjut, lihat bagian Pertanyaan yang sering diajukan. Perlindungan EKS memastikan cluster Anda sendiri tetap tersedia sepanjang siklus hidup rotasi, tetapi rotasi yang berhasil juga bergantung pada Anda memperbarui node pekerja yang Anda kelola dan klien eksternal sehingga mereka mempertahankan konektivitas setelah CA penerus diaktifkan.

API, pengalaman konsol, notifikasi, dan panduan langkah demi langkah di bagian berikut dirancang untuk mendukung Anda melalui proses ini. Lingkup tanggung jawab penuh tercakup dalam bagian model tanggung jawab bersama.

Cara kerja rotasi CA

Rotasi CA di Amazon EKS adalah proses multi-tahap. Kami memiliki pengamanan otomatis untuk menjaga ketersediaan cluster EKS di seluruh siklus hidup rotasi terlepas dari apakah Anda bertindak atau tidak. Rotasi yang berhasil, di mana semua komponen Anda mempertahankan konektivitas, memerlukan langkah-langkah yang dijelaskan di bagian berikut.

Tahap 1: Tambahkan CA penerus

CA penerus ditambahkan ke cluster EKS. Dari titik ini, cluster EKS mempercayai CA keluar dan CA penerus secara bersamaan. Sertifikat terus dikeluarkan oleh CA yang keluar. Tidak ada gangguan yang terjadi.

Anda dapat menambahkan CA penerus sendiri kapan saja menggunakan AWS CLI, EKS API, Konsol, atau infrastruktur sebagai kode (IAc) seperti AWS CloudFormation, selama cluster Anda dalam keadaan aktif. Jika tidak, kami akan secara otomatis menambahkannya atas nama Anda.

CA penerus tidak dapat diaktifkan sampai AWS menyelesaikan distribusi ke komponen ter AWS kelola di EKS (Tahap 2). Ini adalah waktu yang tepat untuk mulai mengidentifikasi node pekerja dan klien eksternal yang perlu diperbarui. Mengidentifikasi semua sistem yang terhubung ke server API cluster EKS Anda dapat memakan waktu, terutama di lingkungan dengan banyak tim, CI/CD pipeline, dan alat pemantauan. Memulai proses ini lebih awal memberi Anda fleksibilitas paling besar untuk mengoordinasikan pembaruan pada timeline Anda sendiri.

Tahap 2: Bagikan CA penerus

Setelah CA penerus ditambahkan, perbarui komponen yang AWS dikelola di cluster EKS Anda (bidang kontrol, instans Mode Otomatis EKS, dan node AWS Fargate) untuk mengenali dan mempercayai kedua CA. Anda dapat melacak kemajuan ini melalui status distribusi CA. CA penerus tidak dapat diaktifkan sampai distribusi selesai.

Setelah kami menyelesaikan distribusi CA ke komponen terkelola, Anda bertanggung jawab untuk memperbarui dua grup: node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal untuk mempercayai CA penerus. Ini memastikan mereka akan terus terhubung ke server API setelah CA penerus diaktifkan. Jika ada komponen yang tidak diperbarui sebelum aktivasi CA penerus, rollback CA tersedia untuk memulihkan konektivitas saat Anda menyelesaikan pembaruan yang tersisa.

Tahap 3: Aktifkan CA penerus

Setelah kami menyelesaikan distribusi CA penerus ke semua komponen yang AWS dikelola di EKS, CA penerus dapat diaktifkan. Sebaiknya aktifkan CA penerus pada timeline Anda sendiri. Beri diri Anda cukup waktu untuk menemukan dan memperbarui node pekerja yang Anda kelola dan klien eksternal untuk mempercayai CA penerus. Setelah aktivasi CA penerus, klaster EKS mengeluarkan sertifikat yang ditandatangani oleh CA penerus. CA keluar tetap tepercaya tetapi tidak lagi digunakan untuk penandatanganan. Jendela rollback tersedia untuk periode terbatas setelah aktivasi, memungkinkan Anda untuk kembali ke CA keluar jika diperlukan. Rollback dibahas secara rinci di bagian selanjutnya.

Anda dapat mengaktifkan CA penerus sendiri jika Anda yakin node pekerja yang Anda kelola dan klien telah diperbarui. Jika tidak, kami akan mengaktifkan CA penerus secara otomatis saat batas waktu kedaluwarsa mendekat.

Periode kepercayaan ganda

Waktu antara menambahkan CA penerus (Tahap 1) dan mengeluarkan CA yang keluar disebut periode kepercayaan ganda. Selama waktu ini, cluster EKS mempercayai kedua CA secara bersamaan. Inilah yang membuat rotasi tidak mengganggu: komponen dapat diperbarui secara bertahap karena cluster EKS menerima sertifikat yang ditandatangani oleh salah satu CA.

Periode kepercayaan ganda memberi Anda waktu untuk mengidentifikasi dan memperbarui semua node pekerja yang Anda kelola dan klien eksternal tanpa perlu mengoordinasikan semua perubahan secara bersamaan.

Penting untuk memahami bagaimana aktivasi CA penerus mempengaruhi konektivitas. Ketika klien terhubung ke server API, ia memverifikasi identitas server dengan memeriksa bahwa sertifikat server ditandatangani oleh CA yang dipercaya.

Setelah CA penerus diaktifkan, server API menyajikan sertifikatnya yang ditandatangani oleh CA penerus. Klien yang telah memperbarui bundel kepercayaan mereka untuk menyertakan CA penerus akan berhasil memverifikasi dan terhubung seperti biasa. Klien yang belum memperbarui bundel kepercayaan mereka tidak akan mengenali sertifikat server dan tidak akan dapat membuat koneksi.

Diagram berikut menunjukkan aliran koneksi TLS setelah aktivasi CA penerus.

Inilah sebabnya mengapa memperbarui node pekerja dan klien eksternal sebelum aktivasi CA penerus adalah penting: mereka memerlukan CA penerus dalam bundel kepercayaan mereka untuk memverifikasi identitas server API dan terhubung. Periode kepercayaan ganda dan pengembalian CA memberi Anda waktu dan jaring pengaman untuk menyelesaikan ini.

Model tanggung jawab bersama

Rotasi CA di Amazon EKS mengikuti model tanggung jawab bersama yang sama yang berlaku secara luas AWS. AWS bertanggung jawab atas keamanan dan ketersediaan infrastruktur cloud, dan Anda bertanggung jawab atas keamanan dan konfigurasi beban kerja Anda di dalamnya. Untuk informasi selengkapnya tentang bagaimana tanggung jawab bersama berlaku untuk Amazon EKS, lihat praktik terbaik keamanan EKS.

Dalam konteks rotasi CA, ini berarti:

AWS bertanggung jawab untuk

Anda bertanggung jawab untuk

Kami tidak dapat melakukan tindakan ini atas nama Anda. Klien eksternal ada di luar batas AWS operasional. Node pekerja yang tidak dikelola oleh EKS Auto Mode atau Fargate memiliki konfigurasi kepercayaan CA yang ditetapkan pada waktu peluncuran atau melalui proses bootstrap yang hanya Anda kendalikan. Ini konsisten dengan cara kerja kepercayaan TLS: klien memiliki toko kepercayaannya sendiri, dan hanya administrator klien yang dapat memperbaruinya.

Bagian berikut berkembang di setiap sisi: AWS apa yang berguna untuk Anda, dan apa yang perlu Anda lakukan bersama dengan panduan langkah demi langkah tentang cara melakukannya.

Apa AWS melakukan untuk Anda

AWS mengelola hal-hal berikut sepanjang siklus siklus rotasi CA untuk cluster EKS Anda:

Pembuatan CA otomatis

Jika Anda tidak menambahkan CA penerus pada timeline Anda sendiri, kami akan menambahkannya secara otomatis saat CA keluar cluster EKS Anda mendekati kedaluwarsa. Ini memastikan proses rotasi dimulai dengan waktu yang cukup bagi Anda untuk menemukan dan memperbarui klien Anda sebelum batas waktu kedaluwarsa.

Pembaruan pesawat kontrol

Kami secara otomatis memperbarui bidang kontrol cluster EKS untuk mempercayai CA penerus. Setelah aktivasi CA penerus, pesawat kontrol mengeluarkan sertifikat yang ditandatangani oleh CA penerus. Tidak ada tindakan yang diperlukan dari Anda untuk pesawat kontrol.

Pembaruan Mode Otomatis EKS dan Fargate

Kami secara otomatis memperbarui node Mode Otomatis EKS dan pod Fargate untuk mempercayai CA penerus. Komponen-komponen ini sepenuhnya dikelola oleh kami dan tidak memerlukan tindakan dari Anda selama rotasi CA.

Pembaruan Kemampuan EKS

Kami secara otomatis memperbarui Kemampuan EKS (Peng AWS ontrol untuk Kubernetes (ACK), Argo CD, dan kro (Kube Resource Orchestrator)) untuk mempercayai CA penerus. Sumber daya terkelola ini berkomunikasi dengan server API cluster Anda dan diperbarui sebagai bagian dari proses distribusi CA. Tidak ada tindakan yang diperlukan dari Anda untuk sumber daya terkelola di Kapabilitas EKS. Untuk informasi selengkapnya, lihat Kemampuan EKS.

Pelacakan status distribusi

Saat kami memperbarui komponen terkelola di cluster EKS Anda, Anda dapat memantau kemajuan melalui status distribusi CA. Ini memberi tahu Anda apakah kami telah menyelesaikan sisi rotasi kami. CA penerus tidak dapat diaktifkan sampai distribusi selesai.

Built-in pengamanan

Kami memiliki perlindungan bawaan untuk melindungi cluster EKS Anda selama rotasi:

Perlindungan ini memastikan bahwa ketersediaan cluster EKS dipertahankan sepanjang siklus hidup rotasi terlepas dari apakah Anda bertindak atau tidak.

Notifikasi

Kami memberi tahu Anda pada setiap tahap siklus hidup rotasi CA. Pemberitahuan dikirimkan melalui AWS Kesehatan, Cluster Insights, dan email. Setiap notifikasi memberi tahu Anda apa yang terjadi, tindakan apa (jika ada) yang diperlukan dari Anda, dan di mana cluster EKS Anda berada di garis waktu rotasi.

Anda juga dapat mengonfigurasi notifikasi sendiri menggunakan Amazon EventBridge untuk mengintegrasikan peristiwa rotasi CA ke dalam alur kerja pemantauan dan peringatan yang ada.

Apa yang perlu Anda lakukan (dan mengapa)

Rotasi CA yang berhasil mengharuskan Anda memperbarui komponen yang AWS tidak dapat dijangkau atas nama Anda. Ini terbagi dalam dua kategori:

Klien eksternal

Sistem apa pun yang terhubung ke server API cluster EKS Anda dari luar cluster. Ini termasuk workstation pengembang, CI/CD pipeline (Jenkins, Ac GitHub tions,, ArgoCD) GitLab, alat pemantauan dan pengamatan, skrip otomatisasi, dan aplikasi apa pun yang menggunakan kubeconfig untuk berkomunikasi dengan server API.

Sistem ini masing-masing mempertahankan konfigurasi kepercayaan mereka sendiri. Ketika CA penerus diaktifkan, server API menyajikan sertifikat yang ditandatangani oleh CA penerus. Memperbarui klien ini untuk mempercayai CA penerus sebelum aktivasi CA penerus memastikan mereka mempertahankan konektivitas. Jika klien terlewatkan, CA rollback dapat memulihkan akses saat Anda menyelesaikan pembaruan.

Node pekerja (Mode Otomatis non-EKS, Non-Fargate)

Node pekerja yang tidak dikelola oleh EKS Auto Mode atau Fargate memiliki konfigurasi kepercayaan CA yang ditetapkan pada waktu peluncuran atau melalui proses bootstrap kubelet. Node ini perlu disegarkan sehingga mereka mempercayai CA penerus. Tindakan yang diperlukan tergantung pada jenis node pekerja:

Grup simpul terkelola

Lakukan pembaruan versi grup node, yang memicu penggantian node bergulir. Bootstrap node baru dengan konfigurasi kepercayaan CA yang diperbarui secara otomatis.

Karpenter-controlled simpul

Jika deteksi drift diaktifkan, Karpenter akan memutar node dalam jendela drift yang dikonfigurasi dan node baru akan mengambil CA penerus tanpa tindakan manual. Jika deteksi penyimpangan dinonaktifkan atau disetel ke jendela panjang, perlakukan node ini sama dengan node yang dikelola sendiri.

Self-managed simpul

Ganti node sehingga mereka melakukan bootstrap dengan konfigurasi kepercayaan CA yang diperbarui. Ini biasanya melibatkan memperbarui template peluncuran dengan data CA yang diperbarui dan memicu penggantian bergulir melalui grup Penskalaan Otomatis Anda.

Simpul hibrida

Perbarui konfigurasi kepercayaan pada setiap node hybrid untuk menyertakan CA penerus. Proses spesifik tergantung pada bagaimana node hybrid Anda di-bootstrap dan bagaimana konfigurasi kepercayaannya dikelola.

Anda dapat mengidentifikasi jenis node pekerja yang berjalan di cluster EKS menggunakan Cluster Insights. Panduan langkah demi langkah terperinci untuk memperbarui setiap jenis disediakan di bagian selanjutnya.

Kami menyediakan rollback CA sebagai jaring pengaman jika ada node pekerja yang terlewatkan. Namun, memperbarui semua node pekerja sebelum aktivasi CA penerus menghindari gangguan konektivitas sepenuhnya. Node yang tidak diperbarui sebelum CA penerus diaktifkan akan kehilangan konektivitas ke server API cluster EKS sampai diganti atau rollback CA dilakukan.

Mengapa hanya Anda yang bisa melakukan ini

Klien eksternal ada di luar batas AWS operasional. CI/CD Pipeline yang berjalan di jaringan perusahaan Anda, laptop pengembang, alat pemantauan yang dihosting di tempat: tidak AWS memiliki mekanisme untuk menjangkau sistem ini dan memperbarui konfigurasi kepercayaan mereka.

Non-EKS Node pekerja Mode Otomatis memiliki konfigurasi kepercayaan yang dikendalikan melalui template peluncuran, skrip data pengguna, atau proses bootstrap yang Anda miliki. Memperbarui mereka memerlukan penggantian node atau memodifikasi konfigurasinya, yang keduanya merupakan tindakan dalam infrastruktur Anda.

Ini adalah kendala dari model kepercayaan TLS yang digunakan oleh Kubernetes saat ini. Tidak ada mekanisme tingkat protokol bagi server API untuk menanyakan apakah klien telah memperbarui bundel kepercayaannya. Server hanya dapat menyajikan sertifikatnya ketika klien terhubung. Jika klien mempercayai CA yang menandatanganinya, koneksi berhasil. Jika tidak, itu gagal. Tidak ada jalur verifikasi pra-aktivasi yang memungkinkan AWS untuk mengkonfirmasi kesiapan komponen Anda atas nama Anda.

Kapan memulai

Mulailah mengidentifikasi klien eksternal Anda sedini mungkin. Ini adalah bagian rotasi CA yang paling memakan waktu, terutama di lingkungan dengan beberapa tim yang secara independen menyebarkan beban kerja ke cluster EKS. Semakin awal Anda memulai penemuan klien, semakin banyak waktu yang Anda miliki untuk mengoordinasikan pembaruan di seluruh tim tanpa tekanan.

Panduan terperinci tentang cara memperbarui setiap jenis node klien dan pekerja disediakan di bagian berikut.

Prasyarat

Sebelum memulai rotasi CA, konfirmasikan hal berikut:

Tidak ada izin IAM tambahan yang diperlukan selain yang diperlukan untuk mengelola cluster EKS Anda. Jika Anda dapat memanggil API EKS untuk cluster EKS Anda hari ini, Anda dapat melakukan rotasi CA.

Memulai

Anda dapat melakukan rotasi CA menggunakan AWS CLI atau konsol Amazon EKS. Pastikan Anda menjalankan AWS CLI versi 2.x atau yang lebih baru (aws --versionuntuk memeriksa).

Menggunakan AWS CLI

Panduan berikut mencakup proses rotasi CA ujung ke ujung menggunakan API AWS CLI dan EKS.

Langkah 1: Periksa CA aktif Anda

Lihat otoritas sertifikat aktif di cluster EKS Anda.

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Keluaran yang diharapkan

{
    "certificateAuthorities": [
        {
            "id": "a1b2c3d4-5678-90ab-cdef-example11111",
            "createdAt": "2024-01-15T10:30:00-07:00",
            "createdBy": "EKS",
            "activatedAt": "2024-01-15T10:30:00-07:00",
            "activatedBy": "EKS",
            "signingStatus": "IN_USE",
            "distributionStatus": "COMPLETE"
        }
    ]
}

Ini menunjukkan CA yang dibuat saat cluster EKS Anda dibuat. Saat ini sedang digunakan (sertifikat penandatanganan) dan distribusi selesai (semua komponen yang AWS dikelola di EKS mempercayainya).

Langkah 2: Lihat detail CA dan kedaluwarsa

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2

Keluaran yang diharapkan

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example11111",
        "createdAt": "2024-01-15T10:30:00-07:00",
        "createdBy": "EKS",
        "activatedAt": "2024-01-15T10:30:00-07:00",
        "activatedBy": "EKS",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "validity": {
            "notBefore": "2024-01-15T10:30:00-07:00",
            "notAfter": "2029-01-14T10:30:00-07:00"
        },
        "rollbackAvailable": false
    }
}

validityBlok menunjukkan kapan CA dibuat (notBefore) dan kapan kedaluwarsa (notAfter). rollbackAvailablemenunjukkan apakah Anda dapat kembali ke CA sebelumnya setelah aktivasi CA penerus. Untuk CA awal yang dibuat dengan cluster EKS Anda, ini false karena tidak ada CA sebelumnya untuk dikembalikan.

Langkah 3: Tambahkan CA penerus

aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2

Ini menambahkan CA penerus ke cluster EKS Anda. Tanggapan termasuk yang dapat updateId Anda gunakan untuk melacak kemajuan.

Langkah 4: Lacak pembaruan

aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2

Tunggu sampai status pembaruan adaSuccessful.

Langkah 5: Verifikasi status distribusi

aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2

Anda sekarang harus melihat dua CA. CA penerus akan memiliki signingStatus: NOT_USED dan distributionStatus akan maju dari COMPLETE setelah IN_PROGRESS AWS memperbarui semua komponen terkelola di cluster EKS Anda.

Jangan lanjutkan sampai status distribusi CA penerus adaCOMPLETE.

Langkah 6: Perbarui kubeconfig Anda

aws eks update-kubeconfig --name my-cluster --region us-west-2

Ini memperbarui kubeconfig lokal Anda untuk mempercayai kedua CA. Setelah ini, perintah kubectl Anda akan terus bekerja setelah CA penerus diaktifkan.

Langkah 7: Perbarui node pekerja yang Anda kelola dan klien eksternal

Ini dibahas secara rinci di bagian selanjutnya. Setelah semua node pekerja yang Anda kelola dan klien eksternal telah diperbarui untuk mempercayai CA penerus, lanjutkan ke aktivasi.

Langkah 8: Aktifkan CA penerus

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <successor-ca-id> --region us-west-2

Setelah aktivasi CA penerus, cluster EKS Anda mengeluarkan sertifikat yang ditandatangani oleh CA penerus. Verifikasi konektivitas untuk mengonfirmasi bahwa semua komponen berfungsi seperti yang diharapkan.

Menggunakan konsol Amazon EKS

Konsol Amazon EKS menyediakan pengalaman terpandu untuk rotasi CA. Anda dapat melihat status CA Anda, menambahkan CA penerus, memantau kemajuan distribusi, dan mengaktifkan CA penerus langsung dari konsol.

Gambar berikut menunjukkan tampilan detail otoritas sertifikat di konsol Amazon EKS selama rotasi aktif. CA aktif dan CA penerus keduanya ditampilkan dengan status penandatanganan, tanggal kedaluwarsa, dan hari hingga kedaluwarsa.

Gambar berikut menunjukkan tampilan kemajuan rotasi di konsol Amazon EKS. Setiap langkah proses rotasi ditampilkan dengan status saat ini, termasuk menambahkan, mendistribusikan, memperbarui node pekerja dan klien eksternal, aktivasi, dan penghapusan CA keluar.

Memperbarui klien Kubernetes Anda

Setelah CA penerus ditambahkan dan AWS telah menyelesaikan distribusi ke komponen terkelola di cluster EKS Anda (distributionStatus: COMPLETE), Anda perlu memperbarui komponen Anda sendiri untuk mempercayai CA penerus. “Klien” dalam konteks ini adalah sistem apa pun yang terhubung ke server API cluster EKS Anda. Ini termasuk konfigurasi kubectl lokal Anda, CI/CD pipeline, alat pemantauan, skrip otomatisasi, dan node pekerja Anda.

Data CA yang diperbarui untuk cluster EKS Anda (yang sekarang berisi CA saat ini dan penerus) dapat diambil menggunakan:

aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text

Gunakan nilai ini untuk memperbarui konfigurasi kepercayaan dari setiap jenis klien di subbagian berikut.

Kubeconfig (workstation pengembang, saluran pipa, CI/CD otomatisasi)

Jalankan yang berikut ini untuk memperbarui kubeconfig lokal Anda:

aws eks update-kubeconfig --name my-cluster --region us-west-2

Ini secara otomatis mengambil data CA terbaru dan memperbarui kubeconfig Anda. Sistem apa pun yang menggunakan kubeconfig ini akan mempercayai kedua CA.

Untuk CI/CD pipeline dan otomatisasi yang menghasilkan kubeconfig mereka sendiri (misalnya, menggunakan API EKS secara langsung atau menyimpan kubeconfig sebagai rahasia), perbarui certificate-authority-data bidang dengan nilai yang diambil dari. describe-cluster

Grup simpul terkelola

Lakukan pembaruan versi grup node untuk memicu penggantian node bergulir:

aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2

Node baru bootstrap dengan data CA yang diperbarui secara otomatis. Penggantian bergulir memastikan node diganti satu per satu tanpa mengganggu beban kerja yang sedang berjalan.

Jika Anda mengelola grup node melalui Terraform atau CloudFormation, rotasi CA tidak membuat penyimpangan dalam status IAc Anda. Siklus hidup CA dikelola melalui API EKS khusus yang terpisah dari konfigurasi sumber daya cluster Anda. Untuk detail lebih lanjut tentang bagaimana rotasi CA berinteraksi dengan infrastruktur sebagai kode, lihat bagian Infrastruktur sebagai kode.

Template peluncuran kustom dengan AMI khusus

Jika grup node Anda digunakan dengan AMI khusus, AWS tidak menggabungkan data pengguna. Anda bertanggung jawab untuk menyediakan konfigurasi bootstrap yang benar, termasuk bundel kepercayaan CA yang diperbarui. Rotasi CA tidak memperbarui data pengguna untuk Anda, dan node tanpa CA penerus gagal bergabung dengan cluster.

Verifikasi node berjalan pada template peluncuran yang diperbarui

Sebelum melanjutkan ke aktivasi, konfirmasikan bahwa semua node dalam grup node terkelola Anda berjalan pada versi template peluncuran terbaru. Versi ini harus berisi bundel kepercayaan CA yang diperbarui.

Karpenter-controlled simpul

Jika deteksi penyimpangan diaktifkan di Karpenter Anda NodePool, Karpenter akan secara otomatis mendeteksi bahwa node berjalan dengan data CA yang sudah ketinggalan zaman dan memutarnya dalam jendela gangguan yang dikonfigurasi. Node baru akan mengambil CA penerus tanpa tindakan manual.

Verifikasi deteksi penyimpangan diaktifkan dalam NodePool konfigurasi Anda:

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    budgets:
      - nodes: "10%"
  template:
    spec:
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: default

Jika disruption dikonfigurasi dengan kebijakan konsolidasi, deteksi penyimpangan aktif secara default. Karpenter akan mengganti node yang telah hanyut dari keadaan yang diinginkan, yang mencakup perubahan data CA.

Jika deteksi penyimpangan diaktifkan, verifikasi bahwa anggaran gangguan Anda memungkinkan semua Karpenter-controlled node diganti sebelum tanggal aktivasi CA penerus. Jika anggaran terlalu ketat (misalnya, jendela pemeliharaan sempit dengan persentase penggantian rendah), tidak semua node mungkin diganti tepat waktu.

Jika deteksi penyimpangan dinonaktifkan atau anggaran gangguan membatasi penggantian ke jendela yang melebihi garis waktu rotasi Anda, Anda dapat memicu penggantian node secara manual dengan menutup dan menguras node:

kubectl cordon <node-name>
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

Karpenter akan menyediakan node pengganti yang melakukan bootstrap dengan data CA yang diperbarui.

Self-managed simpul

Untuk node yang dikelola sendiri, Anda perlu memperbarui data CA di template peluncuran atau skrip data pengguna yang digunakan node Anda selama bootstrap:

Node baru akan melakukan bootstrap dengan data CA yang diperbarui dan mempercayai CA saat ini dan penerus.

AWS Pod Fargate (tipe peluncuran EKS Fargate)

AWS Pod Fargate di cluster EKS Anda bekerja secara berbeda dari mode peluncuran bidang data EKS lainnya (grup node terkelola, node yang dikelola sendiri, Karpenter-controlled node).

Ketika sebuah pod terhubung ke server API, dua hal terjadi: pod mengotentikasi dirinya sendiri menggunakan token akun layanannya (membuktikan identitasnya ke server API), dan pod memverifikasi identitas server API dengan memeriksa apakah sertifikat server ditandatangani oleh CA yang dipercayainya. Data CA yang disimpan di lingkungan pod inilah yang memungkinkan verifikasi ini. Jika server API mulai menyajikan sertifikat yang ditandatangani oleh CA penerus yang tidak dipercaya pod, pod akan menolak koneksi.

Dalam mode peluncuran bidang data EKS lainnya (grup node terkelola, node yang dikelola sendiri, Karpenter-controlled node), data CA hidup di node. Saat Anda mengganti node, node baru melakukan bootstrap dengan data CA yang diperbarui. Pod yang dijadwalkan ke node baru tersebut menerima data CA yang diperbarui, memungkinkan mereka memverifikasi server API terlepas dari CA mana yang menandatangani sertifikatnya.

Di Fargate, setiap pod berjalan di lingkungan komputasi khusus sendiri dengan proses kubeletnya sendiri. Kubelet ini melakukan bootstrap dengan data CA pada saat pod dibuat. Tidak ada node bersama di bawahnya, dan Anda tidak memiliki akses langsung ke komputasi yang mendasarinya.

Tidak ada tindakan pelanggan yang diperlukan untuk node AWS Fargate di EKS selama rotasi CA. AWS secara alami mendaur ulang pod di node Fargate melalui proses tambalannya. Setelah CA penerus ditambahkan, pod Fargate yang sudah ada sebelumnya didaur ulang sebagai bagian dari proses ini. Mereka akan mempercayai CA penerus tanpa tindakan apa pun dari Anda. Karena AWS menambahkan CA penerus jauh sebelum garis waktu aktivasi CA AWS yang diprakarsai di EKS, pod Fargate akan didaur ulang dan mempercayai CA penerus pada saat AWS mengaktifkan CA penerus. Ada perlindungan bawaan yang mencegah aktivasi CA penerus sampai pod Fargate selesai didaur ulang.

Ini berarti kedua opsi bidang data terkelola (Mode Otomatis EKS dan Fargate) untuk cluster EKS memiliki pengalaman pengguna yang sama untuk rotasi CA: tidak ada tindakan pelanggan yang diperlukan untuk node pekerja Anda. Anda masih bertanggung jawab untuk memperbarui klien eksternal yang terhubung ke server API.

Ini adalah kasus tepi. Mengingat garis waktu rotasi (CA penerus ditambahkan bertahun-tahun sebelum kedaluwarsa), siklus tambalan alami akan selesai jauh sebelum aktivasi CA penerus di sebagian besar skenario. Perlindungan ada sebagai tindakan pencegahan untuk kasus yang tidak mungkin di mana pelanggan mencoba aktivasi awal.

Klien eksternal (alat pemantauan, integrasi pihak ketiga)

Aplikasi atau alat apa pun yang terhubung ke server API cluster EKS Anda menggunakan kubeconfig atau konfigurasi kepercayaan sertifikat perlu diperbarui dengan data CA yang diperbarui. Hal ini mencakup:

Untuk masing-masing, ganti data CA yang disimpan dengan nilai yang diperbarui daridescribe-cluster.

Cara memverifikasi klien telah diperbarui

Setelah memperbarui klien, konfirmasikan masih dapat berkomunikasi dengan server API:

kubectl get nodes

Jika perintah berhasil, kubeconfig Anda mempercayai data CA aktif. Setelah aktivasi CA penerus, jalankan perintah yang sama untuk mengonfirmasi konektivitas lanjutan.

Infrastruktur sebagai kode

Anda dapat melakukan rotasi CA bersama infrastruktur yang ada sebagai kode (IaC) tanpa membuat penyimpangan atau memerlukan perubahan pada konfigurasi IAc Anda.

Mengapa rotasi CA tidak memengaruhi status IAc Anda

Siklus hidup CA dikelola melalui API EKS khusus (create-certificate-authorityactivate-certificate-authority,,delete-certificate-authority) yang sepenuhnya terpisah dari konfigurasi sumber daya cluster EKS. Apakah rotasi CA dimulai oleh Anda, atau secara otomatis oleh AWS, tidak ada properti yang dilacak oleh perkakas IAc Anda pada sumber daya cluster EKS yang dimodifikasi.

Ini berarti:

certificateAuthority.dataBidang yang dikembalikan oleh describe-cluster adalah output read-only. Ini mencerminkan bundel kepercayaan gabungan saat ini (kedua CA selama periode kepercayaan ganda) tetapi bukan properti yang dapat dikonfigurasi. Alat iAC tidak melacaknya sebagai sesuatu untuk direkonsiliasi.

Bidang atribusi (createdBy,activatedBy) pada setiap catatan CA memungkinkan Anda membedakan antara operasi yang Anda mulai dan operasi yang AWS dimulai secara otomatis, yang mendukung alur kerja audit dan manajemen perubahan.

Menggunakan CloudFormation dengan rotasi CA

Rotasi CA dapat dipicu melalui CloudFormation penggunaan WriteOnly properti pada AWS::EKS::Cluster sumber daya. Properti ini memicu aktivasi tetapi tidak disimpan dalam status tumpukan, jadi pembaruan tumpukan berikutnya tanpa itu tidak mencoba untuk mengembalikan atau menonaktifkan.

# Phase 1: Add to existing stack that manages your cluster
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster

Pembaruan tumpukan pertama ini menambahkan CA penerus ke cluster Anda. Tunggu hingga status distribusi CA penerus mencapai COMPLETE sebelum melanjutkan.

# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
    NewCA:
        Type: AWS::EKS::CertificateAuthority
        Properties:
            ClusterName: my-cluster

    # Update your existing Cluster resource to activate
    MyCluster:
        Type: AWS::EKS::Cluster
        Properties:
            Name: my-cluster
            ActiveCertificateAuthorityId: !GetAtt NewCA.Id

Pembaruan tumpukan kedua ini memicu aktivasi CA penerus. Karena ActiveCertificateAuthorityId merupakan WriteOnly properti, itu tidak dikembalikan saat dibaca dan tidak CloudFormation akan mendeteksi penyimpangan jika CA aktif berubah di luar CloudFormation (misalnya, melalui aktivasi otomatis oleh AWS).

Penting: CloudFormation Integrasi rotasi CA mengikuti pola yang berbeda dari CloudFormation sumber daya biasa. Otoritas sertifikat di EKS bukanlah sumber daya independen dengan ARN sendiri. Itu ada sebagai bagian dari siklus hidup sertifikat cluster dan diotorisasi melalui cluster itu sendiri, mirip dengan bagaimana kebijakan peran IAM diotorisasi melalui peran induknya (AWS::IAM::RolePolicy) atau asosiasi EIP diotorisasi melalui instansnya (AWS::EC2::EIPAssociation). Pelanggan yang mengelola rotasi CA CloudFormation harus menyadari perbedaan ini.

Grup node terkelola dan IaC

Melakukan pembaruan versi grup node untuk menyegarkan node dengan konfigurasi kepercayaan CA yang diperbarui adalah tindakan operasional. Node baru secara otomatis melakukan bootstrap dengan data kepercayaan CA aktif dari cluster. Jika template iAC Anda tidak melakukan hardcode data CA dalam template peluncuran atau data pengguna, tidak diperlukan perubahan templat.

Kembalikan CA

Setelah mengaktifkan CA penerus, Anda dapat mengembalikan ke CA sebelumnya jika Anda menemukan masalah konektivitas dengan node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) atau klien eksternal. Menggulir kembali mengaktifkan kembali CA sebelumnya sebagai otoritas penandatanganan untuk cluster EKS Anda.

Ketika rollback CA tersedia

CA rollback tersedia setelah aktivasi CA selama:

Anda dapat memeriksa apakah rollback CA tersedia kapan saja menggunakan rollbackAvailable bidang yang dikembalikan oleh: describe-certificate-authority

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2

{
    "certificateAuthority": {
        "id": "a1b2c3d4-5678-90ab-cdef-example22222",
        "signingStatus": "IN_USE",
        "distributionStatus": "COMPLETE",
        "rollbackAvailable": true
    }
}

Ketika rollback CA tidak tersedia

Rollback CA tidak tersedia setelah aktivasi otomatis akhir. Jika AWS mengaktifkan CA penerus untuk waktu terakhir (45 hari sebelum CA kedaluwarsa), rotasi harus dilanjutkan ke depan. Aktivasi otomatis akhir hanya terjadi jika aktivasi otomatis pertama sebelumnya diputar kembali. Ini ada sebagai pengamanan terakhir untuk memastikan klaster EKS tidak mencapai kedaluwarsa CA tanpa CA yang valid.

Cara memutar kembali

Untuk mengembalikan, aktifkan kembali CA sebelumnya:

aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id <previous-ca-id> --region us-west-2

Apa yang terjadi selama rollback CA

Kapan mempertimbangkan rollback CA

CA rollback adalah mekanisme keamanan untuk situasi di mana aktivasi CA penerus mengungkapkan masalah konektivitas yang tidak Anda tangkap sebelumnya:

Setelah memutar kembali, Anda mempertahankan periode kepercayaan ganda penuh untuk mengidentifikasi dan memperbaiki masalah sebelum mengaktifkan kembali CA penerus.

Pemulihan tanpa rollback CA

Jika Anda mengaktifkan CA penerus sebelum memperbarui grup node terkelola dan jendela rollback CA tidak lagi tersedia (misalnya, setelah batas waktu aktivasi otomatis akhir), Anda dapat memulihkan dengan melakukan pembaruan bergulir pada grup node yang terpengaruh. Namun, upaya pembaruan bergulir awal akan gagal karena node yang terputus tidak dapat menerima perintah penggusuran pod dari server API.

Langkah pemulihan

Pertimbangan dan batasan

Ketersediaan wilayah

Rotasi CA tersedia di semua AWS Wilayah komersial di mana Amazon EKS didukung.

Maksimal dua CA

Cluster EKS dapat memiliki paling banyak dua CA setiap saat: CA aktif dan satu penerus. Anda tidak dapat menambahkan CA penerus kedua sampai rotasi sebelumnya selesai.

Tidak ada pencabutan sertifikat

Rotasi CA tidak mendukung pencabutan sertifikat individual. Ini konsisten dengan Kubernetes hulu, yang tidak menerapkan pencabutan sertifikat (CRL atau OCSP). Rotasi menggantikan seluruh CA, yang secara alami membatalkan semua sertifikat yang ditandatangani oleh CA keluar setelah dihapus dari bundel kepercayaan.

AWS-lampiran CA tidak dapat dihapus

Jika AWS secara otomatis menambahkan CA penerus, Anda tidak dapat menghapusnya. Perlindungan ini memastikan proses rotasi tidak dapat terganggu oleh penghapusan yang tidak disengaja. Customer-appended CA dapat dihapus selama mereka bukan CA penandatanganan aktif.

Masa berlaku CA

CA asli yang dibuat dengan cluster Anda memiliki masa berlaku 10 tahun. CA penerus yang dibuat melalui proses rotasi memiliki masa berlaku 5 tahun. Semua CA masa depan untuk cluster Anda akan mengikuti masa berlaku 5 tahun. Periksa kedaluwarsa CA Anda menggunakandescribe-certificate-authority.

Ukuran data pengguna EC2 selama kepercayaan ganda

Selama periode kepercayaan ganda, bundel kepercayaan cluster Anda bertambah besar karena berisi dua sertifikat CA (sekitar 2,8 KB digabungkan, atau sekitar 1,9 KB dengan kompresi gzip). Untuk node pekerja di mana data pengguna khusus disediakan dalam template peluncuran EC2, verifikasi bahwa ukuran data pengguna total Anda tidak melebihi batas data pengguna EC2 sebesar 16KB. Jika data pengguna yang ada mendekati batas ini, penambahan CA kedua dapat menyebabkan pembuatan template peluncuran gagal dan mencegah penyediaan node baru. Pertimbangkan untuk mengompresi konten data pengguna Anda menggunakan gzip untuk mengurangi ukuran.

Peningkatan versi selama rotasi CA

Peningkatan versi cluster EKS dan rotasi CA adalah operasi independen. Namun, Anda tidak dapat melakukan keduanya secara bersamaan. Jika operasi rotasi CA sedang berlangsung, peningkatan versi akan ditolak sampai operasi CA selesai, dan sebaliknya.

Bawa CA Anda Sendiri (BYOCA)

Menggunakan CA Pri AWS badi Anda sendiri untuk mendukung sertifikat cluster EKS Anda saat ini tidak didukung.

Pertanyaan umum

Bagaimana cara memulai rotasi CA?

Untuk memulai, jalankan aws eks list-certificate-authorities --cluster-name my-cluster untuk melihat CA aktif Anda dan kedaluwarsanya. Jika Anda siap untuk memulai rotasi, jalankan aws eks create-certificate-authority --cluster-name my-cluster untuk menambahkan CA penerus. Proses selangkah demi selangkah tercakup di bagian Memulai. Anda juga dapat melakukan rotasi CA melalui konsol Amazon EKS.

Apakah ada biaya yang terkait dengan rotasi CA?

Tidak. Rotasi CA tersedia tanpa biaya tambahan untuk semua cluster EKS.

Apa yang terjadi jika saya tidak memutar CA saya sebelum kedaluwarsa?

Kami memiliki pengamanan otomatis yang mencegah klaster EKS Anda mencapai kedaluwarsa CA tanpa CA yang valid. Jika Anda tidak memulai rotasi CA sendiri, kami akan secara otomatis menambahkan dan mengaktifkan CA penerus sebelum kedaluwarsa, memastikan cluster Anda tetap tersedia.

Namun, rotasi yang berhasil juga mengharuskan Anda memperbarui node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal untuk mempercayai CA penerus. Jika komponen ini tidak diperbarui sebelum CA penerus diaktifkan, mereka akan kehilangan konektivitas ke server API.

Di Kubernetes, jika CA tidak dirotasi sebelum kedaluwarsa, semua sertifikat yang ditandatangani oleh CA tersebut menjadi tidak valid. Server API tidak dapat lagi dijangkau oleh klien mana pun, dan cluster menjadi tidak tersedia.

Berapa banyak waktu yang saya miliki untuk menyelesaikan rotasi CA?

Waktu keseluruhan untuk menyelesaikan rotasi CA tergantung pada pengam AWS anan otomatis dan proses pembaruan Anda sendiri.

AWS memberikan garis waktu yang pasti untuk apa yang dikelolanya. CA penerus ditambahkan kira-kira 2 tahun sebelum CA keluar Anda kedaluwarsa. Jika Anda tidak mengaktifkan CA penerus sendiri, kami akan mengaktifkannya secara otomatis sekitar 6 bulan sebelum kedaluwarsa. Jika Anda melakukan rollback setelah aktivasi otomatis, kami akan melakukan aktivasi otomatis terakhir 45 hari sebelum kedaluwarsa. Perlindungan ini memastikan cluster EKS Anda tetap tersedia terlepas dari apakah Anda bertindak.

Rotasi CA yang berhasil juga bergantung pada Anda memperbarui node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal untuk mempercayai CA penerus sebelum aktivasi CA penerus. Berapa lama waktu yang dibutuhkan tergantung pada konfigurasi node pekerja bidang data Anda, jejak klien eksternal Anda, dan berapa lama waktu yang dibutuhkan untuk melakukan penemuan dan pembaruan komponen ini.

Apakah rotasi CA menyebabkan downtime untuk cluster saya?

Tidak. Cluster EKS Anda tetap tersedia di seluruh siklus hidup rotasi CA. Pesawat kontrol terus melayani permintaan di setiap tahap. Selama periode kepercayaan ganda, baik CA keluar maupun penerus dipercaya secara bersamaan, memungkinkan komponen diperbarui secara bertahap tanpa gangguan pada operasi cluster. Jika Anda memutar kembali ke CA sebelumnya karena menemukan masalah di sisi klien, lakukan roll AWS forward akhir kira-kira 45 hari sebelum kedaluwarsa CA keluar sebagai perlindungan.

Penting untuk membedakan antara cluster EKS (bidang kontrol) dan komponen bidang data Anda. Bidang kontrol sepenuhnya dikelola oleh AWS dan tetap tersedia selama rotasi.

Untuk Mode Otomatis EKS dan Fargate, AWS memperbarui node pekerja secara otomatis. Tidak ada risiko kehilangan konektivitas untuk node pekerja Anda dalam mode peluncuran bidang data ini. Anda masih bertanggung jawab untuk memperbarui klien eksternal yang terhubung ke server API.

Untuk grup node terkelola, node yang dikelola sendiri, Karpenter-controlled instans (tanpa deteksi drift diaktifkan), dan node hibrida, Anda bertanggung jawab untuk mengganti atau memperbarui node tersebut sebelum aktivasi CA penerus. Jika tidak diganti, node tersebut akan kehilangan konektivitas ke bidang kontrol setelah CA penerus diaktifkan, meskipun bidang kontrol itu sendiri tetap beroperasi penuh.

Apakah beban kerja saya akan terganggu selama rotasi CA?

Beban kerja (pod) yang sedang berjalan tidak terganggu oleh rotasi CA itu sendiri. Pod berkomunikasi satu sama lain melalui jaringan cluster, yang tidak terpengaruh oleh perubahan CA. CA digunakan untuk komunikasi antara komponen dan server API, bukan untuk lalu lintas pod-to-pod.

Jika node pekerja Anda perlu diganti sebagai bagian dari memperbaruinya agar mempercayai CA penerus (misalnya, grup node terkelola yang melakukan pembaruan bergulir, atau Karpenter mengganti node drift), pod pada node tersebut akan dijadwalkan ulang sebagai bagian dari proses penggantian node normal. Ini adalah perilaku Kubernetes standar selama penggantian node, bukan efek samping dari rotasi CA. Pastikan Anda memiliki Pod Disruption Budget (PDB) yang dikonfigurasi untuk beban kerja penting untuk mengontrol cara pod diusir selama penggantian node.

Kapan CA cluster saya akan kedaluwarsa?

Anda dapat memeriksa kapan CA cluster Anda kedaluwarsa menggunakan AWS CLI, EKS API, atau konsol Amazon EKS. Misalnya, Anda dapat menjalankan yang berikut ini:

aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id <ca-id> --region us-west-2 --query 'certificateAuthority.validity.notAfter'

Anda dapat menemukan ID CA Anda dengan menjalankanaws eks list-certificate-authorities --cluster-name my-cluster.

Berapa masa berlaku CA cluster saya?

CA asli yang dibuat dengan cluster Anda memiliki masa berlaku 10 tahun. CA penerus yang dibuat melalui proses rotasi memiliki masa berlaku 5 tahun. Semua CA masa depan untuk cluster Anda akan mengikuti masa berlaku 5 tahun. Anda dapat memeriksa kedaluwarsa CA Anda menggunakandescribe-certificate-authority.

Bisakah saya memulai rotasi CA sendiri sebelumnya AWS Apakah itu secara otomatis?

Ya. Anda dapat menambahkan CA penerus kapan saja menggunakanaws eks create-certificate-authority --cluster-name my-cluster. Anda tidak perlu menunggu AWS untuk memulai rotasi. Memulai lebih awal memberi Anda lebih banyak waktu untuk mengidentifikasi dan memperbarui node pekerja dan klien eksternal sesuai jadwal Anda sendiri.

Dapatkah saya mengembalikan setelah mengaktifkan CA penerus?

Ya, rollback CA tersedia setelah aktivasi CA penerus selama jendela rollback belum kedaluwarsa. CA rollback mengaktifkan kembali CA sebelumnya sebagai otoritas penandatanganan. Ini tidak tersedia setelah aktivasi otomatis akhir (45 hari sebelum kedaluwarsa CA). Anda dapat memeriksa rollbackAvailable bidang di CA Anda menggunakandescribe-certificate-authority. Lihat bagian CA Rollback untuk detailnya.

Bagaimana saya tahu kapan aman untuk mengaktifkan CA penerus?

Aman untuk mengaktifkan CA penerus ketika semua node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal telah diperbarui untuk mempercayai CA penerus. Anda dapat memverifikasi ini dengan mengonfirmasi bahwa setiap klien dapat berhasil berkomunikasi dengan server API menggunakan konfigurasi kepercayaan yang diperbarui. AWS tidak memberikan indikator tunggal bahwa semua klien siap, karena tidak dapat melihat ke dalam sistem eksternal Anda. Mulailah proses penemuan lebih awal untuk memberi diri Anda waktu untuk mengidentifikasi semua klien.

Bagaimana cara memantau kemajuan rotasi CA di beberapa cluster?

Anda dapat menyelesaikan ini secara terprogram menggunakan API AWS CLI atau EKS. Gunakan aws eks list-certificate-authorities untuk setiap cluster. Bidang-bidang berikut memberikan kesadaran situasional untuk pemantauan tingkat armada:

Contoh skrip berikut memeriksa status rotasi CA di seluruh daftar cluster:

#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"

for CLUSTER in "${CLUSTERS[@]}"; do
  echo "--- $CLUSTER ---"
  aws eks list-certificate-authorities \
    --cluster-name "$CLUSTER" \
    --region "$REGION" \
    --query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
    --output table
done

Anda dapat memperpanjang ini untuk mencakup beberapa wilayah dan akun, dan memfilter klaster yang memiliki CA penerus ditambahkan, sedang menunggu tindakan Anda, atau mendekati tenggat waktu aktivasi otomatis.

Pemberitahuan juga dikirimkan per cluster melalui AWS Kesehatan dan email pada setiap tahap siklus hidup rotasi.

Apa yang terjadi jika saya mengaktifkan CA penerus sebelum memperbarui semua klien saya?

Setiap klien yang belum diperbarui untuk mempercayai CA penerus akan kehilangan konektivitas ke cluster EKS. Setelah aktivasi CA penerus, server API menyajikan sertifikat yang ditandatangani oleh CA penerus. Klien yang tidak mempercayainya akan gagal verifikasi TLS mereka dan tidak dapat terhubung. Jika ini terjadi, Anda dapat mengembalikan ke CA sebelumnya (jika jendela rollback masih tersedia) untuk memulihkan konektivitas saat Anda memperbaiki klien yang tersisa.

Apa yang terjadi jika saya melewatkan tenggat waktu kedaluwarsa CA?

AWS mencegah hal ini terjadi. Pengawasan otomatis memastikan klaster EKS Anda tidak mencapai kedaluwarsa CA tanpa CA yang valid. Kami akan menambahkan CA penerus jika Anda belum melakukannya, dan akan mengaktifkannya secara otomatis sekitar 6 bulan sebelum kedaluwarsa. Jika Anda memutar kembali setelah aktivasi otomatis pertama, lakukan AWS gulungan terakhir 45 hari sebelum kedaluwarsa. Cluster Anda akan tetap tersedia.

Namun, jika node pekerja yang Anda kelola (Mode Otomatis non-EKS, non-Fargate) dan klien eksternal belum diperbarui untuk mempercayai CA penerus pada saat aktivasi otomatis terjadi, komponen tersebut akan kehilangan konektivitas ke server API.

Bisakah saya kehilangan akses ke cluster saya selama rotasi CA?

Cluster EKS Anda (bidang kontrol) tetap tersedia di seluruh siklus hidup rotasi CA. AWS pengamanan memastikan cluster itu sendiri tidak menjadi tidak tersedia.

Namun, klien individu yang Anda kelola dapat kehilangan akses jika mereka tidak diperbarui untuk mempercayai CA penerus sebelum aktivasi CA penerus. Misalnya, jika kubeconfig, CI/CD pipeline, atau alat pemantauan Anda masih mereferensikan hanya CA keluar, klien tersebut tidak akan dapat terhubung setelah CA penerus diaktifkan. Jika ini terjadi, CA rollback dapat memulihkan akses saat Anda memperbarui klien yang terpengaruh.

Apakah saya perlu me-restart pod saya?

Menjalankan pod beban kerja tidak secara langsung terpengaruh oleh rotasi CA. Kubelet pada setiap node menangani komunikasi server API, sehingga pod beban kerja akan terus berjalan tanpa gangguan selama node Anda diperbarui. Namun, pengontrol dan operator dalam klaster yang menggunakan client-go untuk berkomunikasi dengan server API mungkin perlu dihidupkan ulang setelah aktivasi CA penerus, karena client-go tidak membaca ulang bundel kepercayaan CA secara dinamis. Khus AWS usnya untuk node Fargate, AWS menangani pembaruan secara otomatis melalui proses daur ulang pod alami.

Apakah bundel kepercayaan saya akan berubah selama rotasi?

Ya. Selama rotasi CA, bundel kepercayaan cluster Anda akan berisi dua otoritas sertifikat secara bersamaan: CA keluar dan CA penerus. Ini adalah perilaku yang diharapkan selama periode kepercayaan ganda dan merupakan bagaimana proses rotasi mempertahankan konektivitas untuk semua komponen.

Aplikasi dan klien harus dikonfigurasi untuk mempercayai bundel CA daripada menyematkan ke sertifikat CA tunggal. Penjepitan CA (validasi ketat terhadap CA tunggal) tidak disarankan, karena akan menyebabkan kegagalan saat bundel kepercayaan diperbarui. Ini berlaku untuk konfigurasi TLS sisi klien yang terhubung ke server API cluster EKS Anda.

Mengapa garis waktu notifikasi saya berbeda dari apa yang dijelaskan dokumentasi ini?

Jika cluster Anda dibuat pada 2018-2019, cluster Anda akan menerima notifikasi otomatis pada timeline yang disesuaikan. Pemberitahuan pertama Anda akan menyertakan tanggal yang relevan dan langkah selanjutnya khusus untuk cluster Anda. Tonggak notifikasi standar dihitung relatif terhadap tanggal kedaluwarsa CA cluster Anda. Untuk cluster dalam rentang ini, tanggal yang dihitung tersebut mendahului ketersediaan fitur ini, sehingga jadwal yang disesuaikan diterapkan.