Manajemen akses cluster

Manajemen akses yang efektif sangat penting untuk menjaga keamanan dan integritas kluster Amazon EKS Anda. Panduan ini membahas berbagai opsi untuk manajemen akses EKS, dengan fokus pada penggunaan AWS IAM Identity Center (sebelumnya AWS SSO). Kami akan membandingkan pendekatan yang berbeda, mendiskusikan trade-off mereka, dan menyoroti batasan dan pertimbangan yang diketahui.

Opsi manajemen akses EKS

catatan

ConfigMapmanajemen akses berbasis (aws-auth ConfigMap) tidak digunakan lagi dan digantikan oleh Cluster Access Management (CAM) API. Untuk kluster EKS baru, terapkan CAM API untuk mengelola akses cluster. Untuk cluster yang ada menggunakan aws-auth ConfigMap, migrasi ke menggunakan CAM API.

Opsi 1: Pusat Identitas AWS IAM dengan API Manajemen Akses Cluster (CAM)

• Pengguna terpusat dan manajemen izin

• Integrasi dengan penyedia identitas yang ada (misalnya Microsoft AD, Okta, PingId dan lainnya)

• CAM API menggunakan Entri Akses untuk menautkan prinsipal AWS IAM (pengguna atau peran) ke kluster EKS. Entri ini bekerja dengan identitas terkelola IAM Identity Center, memungkinkan administrator untuk mengontrol akses klaster untuk pengguna dan grup yang ditentukan di Pusat Identitas.

Aliran otentikasi kluster EKS:

1. Prinsipal (pengguna manusia) atau proses otomatis mengautentikasi melalui AWS IAM dengan menghadirkan izin akun AWS yang sesuai. Pada langkah ini, mereka dipetakan ke prinsipal AWS IAM yang sesuai (peran atau pengguna).

2. Selanjutnya, entri akses EKS memetakan prinsipal IAM ini ke prinsipal Kubernetes RBAC (pengguna atau grup) dengan mendefinisikan kebijakan akses yang sesuai, yang hanya berisi izin Kubernetes.

3. Ketika pengguna akhir Kubernetes mencoba mengakses klaster, permintaan otentikasi diproses oleh aws-iam-authenticator AWS EKS CLI dan divalidasi terhadap konteks klaster dalam file kubeconfig.

4. Akhirnya, otorisasi EKS memverifikasi izin yang terkait dengan entri akses pengguna yang diautentikasi dan memberikan atau menolak akses yang sesuai.

   • API menggunakan Kebijakan Akses Khusus Amazon EKS untuk menentukan tingkat otorisasi untuk setiap Entri Akses. Kebijakan ini dapat dipetakan ke peran dan izin yang disiapkan di Pusat Identitas IAM, memastikan kontrol akses yang konsisten di seluruh layanan AWS dan kluster EKS.

Manfaat dibandingkan manajemen akses ConfigMap berbasis:

1. Mengurangi risiko kesalahan konfigurasi: Manajemen berbasis API langsung menghilangkan kesalahan umum yang terkait dengan pengeditan manual. ConfigMap Ini membantu mencegah penghapusan yang tidak disengaja atau kesalahan sintaks yang dapat mengunci pengguna keluar dari cluster.

2. Prinsip hak istimewa terkecil yang disempurnakan: Menghapus kebutuhan akan izin cluster-admin dari identitas pembuat klaster dan memungkinkan penetapan izin yang lebih terperinci dan sesuai. Anda dapat memilih untuk menambahkan izin ini untuk kasus penggunaan break-glass.

3. Model keamanan yang disempurnakan: Menyediakan validasi bawaan entri akses sebelum diterapkan. Selain itu, menawarkan integrasi yang lebih ketat dengan AWS IAM untuk otentikasi.

4. Operasi yang disederhanakan: Menawarkan cara yang lebih intuitif untuk mengelola izin melalui perkakas asli AWS.

Praktik terbaik:

1. Gunakan AWS Organizations untuk mengelola beberapa akun dan menerapkan kebijakan kontrol layanan (SCPs).

2. Terapkan prinsip hak istimewa terkecil dengan membuat set izin khusus untuk peran EKS yang berbeda (misalnya admin, pengembang, hanya-baca).

3. Memanfaatkan Attribute-based Access Control (ABAC) untuk secara dinamis menetapkan izin ke Pod berdasarkan atribut pengguna.

4. Secara teratur mengaudit dan meninjau izin akses.

Pertimbangan/batasan:

1. Peran ARNs yang dihasilkan oleh Identity Center memiliki sufiks acak, membuatnya sulit untuk digunakan dalam konfigurasi statis.

2. Dukungan terbatas untuk izin berbutir halus di tingkat sumber daya Kubernetes. Konfigurasi tambahan diperlukan untuk peran Kubernetes RBAC kustom. Bersama dengan Kubernetes-native RBAC, pertimbangkan untuk menggunakan Kyverno untuk manajemen izin lanjutan di kluster EKS.

Opsi 2: AWS IAM Users/Roles dipetakan ke grup Kubernetes

Kelebihan:

1. Kontrol halus atas izin IAM.

2. Peran yang dapat diprediksi dan statis ARNs

Kontra:

1. Peningkatan overhead manajemen untuk akun pengguna

2. Kurangnya manajemen identitas terpusat

3. Potensi proliferasi entitas IAM

Praktik terbaik:

1. Gunakan peran IAM alih-alih pengguna IAM untuk meningkatkan keamanan dan pengelolaan

2. Menerapkan konvensi penamaan untuk peran untuk memastikan konsistensi dan kemudahan manajemen

3. Memanfaatkan kondisi kebijakan IAM untuk membatasi akses berdasarkan tag atau atribut lainnya.

4. Putar tombol akses secara teratur dan tinjau izin.

Pertimbangan/batasan:

1. Masalah skalabilitas saat mengelola sejumlah besar pengguna atau peran

2. Tidak ada kemampuan masuk tunggal bawaan

Opsi 3: Penyedia OIDC

Kelebihan:

1. Integrasi dengan sistem manajemen identitas yang ada

2. Mengurangi overhead manajemen untuk akun pengguna

Kontra:

1. Kompleksitas konfigurasi tambahan

2. Potensi peningkatan latensi selama otentikasi

3. Ketergantungan pada penyedia identitas eksternal

Praktik Terbaik:

1. Konfigurasikan penyedia OIDC dengan hati-hati untuk memastikan validasi token yang aman.

2. Gunakan token berumur pendek dan terapkan mekanisme penyegaran token.

3. Secara teratur mengaudit dan memperbarui konfigurasi OIDC.

Tinjau panduan ini untuk implementasi referensi mengintegrasikan penyedia Single Sign-On eksternal dengan Amazon EKS

Pertimbangan/batasan:

1. Integrasi native terbatas dengan layanan AWS dibandingkan dengan IAM.

2. URL penerbit penyedia OIDC harus dapat diakses publik agar EKS dapat menemukan kunci penandatanganan.

AWS EKS Pod Identity vs IRSA untuk beban kerja

Amazon EKS menyediakan dua cara untuk memberikan izin AWS IAM untuk beban kerja yang berjalan di klaster Amazon EKS: peran IAM untuk akun layanan (IRSA), dan Identitas Pod EKS.

Meskipun IRSA dan EKS Pod Identities memberikan manfaat dari akses hak istimewa yang paling sedikit, isolasi kredensyal, dan auditabilitas, EKS Pod Identity adalah cara yang disarankan untuk memberikan izin untuk beban kerja.

Untuk panduan rinci tentang Identitas dan kredensyal untuk pod EKS, silakan merujuk ke bagian Identitas dan Kredensial dari praktik terbaik Keamanan.

Rekomendasi

Kombinasikan IAM Identity Center dengan CAM API

• Manajemen yang disederhanakan: Dengan menggunakan API Manajemen Akses Cluster bersama dengan IAM Identity Center, administrator dapat mengelola akses kluster EKS bersama layanan AWS lainnya, mengurangi kebutuhan untuk beralih di antara antarmuka yang berbeda atau mengedit secara manual. ConfigMaps

• Gunakan entri akses untuk mengelola izin Kubernetes dari prinsipal IAM dari luar klaster. Anda dapat menambahkan dan mengelola akses ke cluster dengan menggunakan EKS API, AWS Command Line Interface, AWS, AWS SDKs CloudFormation, dan AWS Management Console. Ini berarti Anda dapat mengelola pengguna dengan alat yang sama dengan yang Anda buat dengan cluster.

• Izin Kubernetes granular dapat diterapkan dengan memetakan pengguna atau grup Kubernetes dengan prinsipal IAM yang terkait dengan identitas SSO melalui entri akses dan kebijakan akses.

• Untuk memulai, ikuti Ubah mode autentikasi untuk menggunakan entri akses, lalu Memigrasi entri ConfigMap aws-auth yang ada untuk mengakses entri.