Berikan akses beban kerja Kubernetes untuk AWS menggunakan Akun Layanan Kubernetes - Amazon EKS
Token akun layananPengaya klasterMemberikan izin AWS Identity and Access Management untuk beban kerja di klaster Amazon Elastic Kubernetes Service

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

Berikan akses beban kerja Kubernetes untuk AWS menggunakan Akun Layanan Kubernetes

A Kubernetes akun layanan memberikan identitas untuk proses yang berjalan di Pod. Untuk informasi selengkapnya lihat Mengelola Akun Layanan di Kubernetes dokumentasi. Jika Pod membutuhkan akses ke AWS layanan, Anda dapat memetakan akun layanan ke AWS identitas Identity and Access Management untuk memberikan akses tersebut. Untuk informasi selengkapnya, lihat IAMperan untuk akun layanan.

Token akun layanan

BoundServiceAccountTokenVolumeFitur ini diaktifkan secara default di Kubernetes versi. Fitur ini meningkatkan keamanan token akun layanan dengan memungkinkan beban kerja berjalan Kubernetes untuk meminta token JSON web yang merupakan pemirsa, waktu, dan kunci terikat. Token akun layanan memiliki masa kedaluwarsa satu jam. Di sebelumnya Kubernetes versi, token tidak memiliki kedaluwarsa. Ini berarti bahwa klien yang mengandalkan token ini harus menyegarkan token dalam waktu satu jam. Klien Kubernetes berikut SDKs menyegarkan token secara otomatis dalam jangka waktu yang diperlukan:

  • Versi Go 0.15.7 dan yang lebih baru

  • Versi 12.0.0 Python dan yang lebih baru

  • Versi Java 9.0.0 dan yang lebih baru

  • JavaScript versi 0.10.3 dan yang lebih baru

  • Cabang Ruby master

  • Versi Haskell 0.3.0.0

  • C# versi 7.0.5 dan yang lebih baru

Jika beban kerja Anda menggunakan versi klien sebelumnya, maka Anda harus memperbaruinya. Untuk mengaktifkan kelancaran migrasi klien ke token akun layanan terikat waktu yang lebih baru, Kubernetes menambahkan periode kedaluwarsa yang diperpanjang ke token akun layanan selama satu jam default. Untuk EKS cluster Amazon, periode kedaluwarsa yang diperpanjang adalah 90 hari. EKSCluster Amazon Anda Kubernetes APIserver menolak permintaan dengan token yang berusia lebih dari 90 hari. Kami menyarankan Anda memeriksa aplikasi Anda dan dependensinya untuk memastikan bahwa klien Kubernetes sama atau lebih lambat dari versi yang SDKs tercantum sebelumnya.

Ketika API server menerima permintaan dengan token yang berumur lebih dari satu jam, server akan memberi anotasi pada peristiwa log API audit. annotations.authentication.k8s.io/stale-token Nilai anotasi terlihat seperti contoh berikut:

subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.

Jika klaster Anda mengaktifkan pencatatan bidang Kirim log pesawat kontrol ke CloudWatch Log kontrol, maka anotasi ada di log audit. Anda dapat menggunakan kueri Wawasan CloudWatch Log berikut untuk mengidentifikasi semua Pods di EKS cluster Amazon Anda yang menggunakan token basi:

fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime

subjectIni mengacu pada akun layanan yang Pod digunakan. elapsedtimeIni menunjukkan waktu yang telah berlalu (dalam detik) setelah membaca token terbaru. Permintaan ke API server ditolak ketika elapsedtime melebihi 90 hari (7.776.000 detik). Anda harus secara proaktif memperbarui aplikasi Anda Kubernetes klien SDK untuk menggunakan salah satu versi yang terdaftar sebelumnya yang secara otomatis menyegarkan token. Jika token akun layanan yang digunakan mendekati 90 hari dan Anda tidak memiliki cukup waktu untuk memperbarui SDK versi klien Anda sebelum token kedaluwarsa, maka Anda dapat menghentikan yang ada Pods dan membuat yang baru. Ini menghasilkan refetching token akun layanan, memberi Anda tambahan 90 hari untuk memperbarui versi klien Anda. SDKs

Jika Pod adalah bagian dari penerapan, cara yang disarankan untuk mengakhiri Pods sambil menjaga ketersediaan tinggi adalah melakukan roll out dengan perintah berikut. Ganti my-deployment dengan nama penyebaran Anda.

kubectl rollout restart deployment/my-deployment

Pengaya klaster

Add-on cluster berikut telah diperbarui untuk menggunakan Kubernetes klien SDKs yang secara otomatis mengisi ulang token akun layanan. Sebaiknya pastikan bahwa versi yang terdaftar, atau versi yang lebih baru, diinstal pada cluster Anda.

Memberikan izin AWS Identity and Access Management untuk beban kerja di klaster Amazon Elastic Kubernetes Service

Amazon EKS menyediakan dua cara untuk memberikan izin AWS Identity and Access Management ke beban kerja yang berjalan di EKS klaster Amazon: IAMperan untuk akun layanan, dan EKS Pod Identities.

IAMperan untuk akun layanan

IAMrole for service account (IRSA) mengonfigurasi aplikasi Kubernetes yang berjalan AWS dengan IAM izin berbutir halus untuk mengakses berbagai sumber daya lain AWS seperti bucket Amazon S3, tabel Amazon DynamoDB, dan banyak lagi. Anda dapat menjalankan beberapa aplikasi bersama-sama di EKS cluster Amazon yang sama, dan memastikan setiap aplikasi hanya memiliki set izin minimum yang diperlukan. IRSAdibangun untuk mendukung berbagai Kubernetes opsi penyebaran yang didukung oleh AWS seperti AmazonEKS, Amazon EKS Anywhere, Red Hat OpenShift Service aktif AWS, dan dikelola sendiri Kubernetes cluster di EC2 instans Amazon. Jadi, IRSA dibangun menggunakan AWS layanan dasar sepertiIAM, dan tidak mengambil ketergantungan langsung pada EKS layanan Amazon dan. EKS API Untuk informasi selengkapnya, lihat IAMperan untuk akun layanan.

EKSIdentitas Pod

EKSPod Identity menawarkan kepada administrator klaster alur kerja yang disederhanakan untuk mengautentikasi aplikasi untuk mengakses berbagai AWS sumber daya lain seperti bucket Amazon S3, tabel Amazon DynamoDB, dan banyak lagi. EKSPod Identity EKS hanya untuk, dan sebagai hasilnya, Pod Identity menyederhanakan bagaimana administrator klaster dapat mengkonfigurasi aplikasi Kubernetes untuk mendapatkan izin. IAM Izin ini sekarang dapat dengan mudah dikonfigurasi dengan lebih sedikit langkah langsung melalui AWS Management Console, EKSAPI, dan AWS CLI, dan tidak ada tindakan apa pun untuk diambil di dalam cluster di mana pun Kubernetes benda. Administrator klaster tidak perlu beralih antara IAM layanan EKS dan layanan, atau menggunakan IAM operasi istimewa untuk mengonfigurasi izin yang diperlukan oleh aplikasi Anda. IAMperan sekarang dapat digunakan di beberapa cluster tanpa perlu memperbarui kebijakan kepercayaan peran saat membuat cluster baru. IAMkredensil yang disediakan oleh EKS Pod Identity mencakup tag sesi peran, dengan atribut seperti nama klaster, namespace, nama akun layanan. Tag sesi peran memungkinkan administrator untuk membuat peran tunggal yang dapat bekerja di seluruh akun layanan dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang cocok. Untuk informasi selengkapnya, lihat Pelajari caranya EKS Pod Identity memberikan akses pod ke layanan AWS.

Membandingkan Identitas EKS Pod dan IRSA

Pada tingkat tinggi, baik EKS Pod Identity dan IRSA memungkinkan Anda untuk memberikan IAM izin untuk aplikasi yang berjalan pada klaster Kubernetes. Tetapi mereka pada dasarnya berbeda dalam cara Anda mengonfigurasinya, batas yang didukung, dan fitur yang diaktifkan. Di bawah ini, kami membandingkan beberapa aspek kunci dari kedua solusi.

Atribut EKSIdentitas Pod IRSA

Ekstensibilitas peran

Anda harus mengatur setiap peran sekali untuk membangun kepercayaan dengan prinsipal EKS layanan Amazon yang baru diperkenalkan. pods.eks.amazonaws.com Setelah langkah satu kali ini, Anda tidak perlu memperbarui kebijakan kepercayaan peran setiap kali digunakan di klaster baru.

Anda harus memperbarui kebijakan kepercayaan IAM peran dengan EKS klaster baru OIDC titik akhir penyedia setiap kali Anda ingin menggunakan peran di cluster baru.

Skalabilitas cluster

EKSPod Identity tidak mengharuskan pengguna untuk menyiapkan IAM OIDC penyedia, jadi batasan ini tidak berlaku.

Setiap EKS cluster memiliki OpenID Connect (OIDC) penerbit URL yang terkait dengannya. Untuk digunakanIRSA, unik OpenID Connect penyedia perlu dibuat untuk setiap EKS cluster diIAM. IAMmemiliki batas global default 100 OIDC penyedia untuk setiap AWS akun. Jika Anda berencana untuk memiliki lebih dari 100 EKS cluster untuk setiap AWS akun denganIRSA, maka Anda akan mencapai IAM OIDC batas penyedia.

Skalabilitas peran

EKSPod Identity tidak mengharuskan pengguna untuk mendefinisikan hubungan kepercayaan antara IAM peran dan akun layanan dalam kebijakan kepercayaan, sehingga batasan ini tidak berlaku.

DalamIRSA, Anda menentukan hubungan kepercayaan antara IAM peran dan akun layanan dalam kebijakan kepercayaan peran. Secara default, panjang ukuran kebijakan kepercayaan adalah2048. Ini berarti bahwa Anda biasanya dapat mendefinisikan 4 hubungan kepercayaan dalam satu kebijakan kepercayaan. Meskipun Anda bisa mendapatkan batas panjang kebijakan kepercayaan yang meningkat, Anda biasanya terbatas pada maksimal 8 hubungan kepercayaan dalam satu kebijakan kepercayaan.

Peran dapat digunakan kembali

AWS STSKredensi sementara yang disediakan oleh EKS Pod Identity mencakup tag sesi peran, seperti nama klaster, namespace, nama akun layanan. Tag sesi peran memungkinkan administrator untuk membuat IAM peran tunggal yang dapat digunakan dengan beberapa akun layanan, dengan izin efektif yang berbeda, dengan mengizinkan akses ke AWS sumber daya berdasarkan tag yang dilampirkan padanya. Ini juga disebut kontrol akses berbasis atribut ()ABAC. Untuk informasi selengkapnya, lihat Pemberian Izin pods akses ke AWS sumber daya berdasarkan tag.

AWS STStag sesi tidak didukung. Anda dapat menggunakan kembali peran antar klaster, tetapi setiap pod menerima semua izin peran tersebut.

Lingkungan yang didukung

EKSPod Identity hanya tersedia di AmazonEKS.

IRSAdapat digunakan seperti AmazonEKS, Amazon EKS Anywhere, Red Hat OpenShift Service on AWS, dan self-managed Kubernetes cluster di EC2 instans Amazon.

EKSversi yang didukung

EKS Kubernetes versi 1.24 atau yang lebih baru. Untuk versi platform tertentu, lihatEKSVersi cluster Pod Identity.

Semua versi EKS cluster yang didukung.