Berikan akses beban kerja Kubernetes untuk menggunakan Akun Layanan AWSKubernetes - Amazon EKS
Token akun layananPengaya klasterKredensi IAM untuk Pod

Bantu tingkatkan halaman ini

Ingin berkontribusi pada panduan pengguna ini? Gulir ke bagian bawah halaman ini dan pilih Edit halaman ini GitHub. Kontribusi Anda akan membantu membuat panduan pengguna kami lebih baik untuk semua orang.

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 menggunakan Akun Layanan AWSKubernetes

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

Token akun layanan

BoundServiceAccountTokenVolumeFitur ini diaktifkan secara default dalam Kubernetes versi. Fitur ini meningkatkan keamanan token akun layanan dengan memungkinkan beban kerja berjalan Kubernetes untuk meminta token web JSON yang merupakan pemirsa, waktu, dan kunci terikat. Token akun layanan memiliki masa kedaluwarsa satu jam. Di Kubernetes versi sebelumnya, token tidak memiliki kedaluwarsa. Ini berarti bahwa klien yang mengandalkan token ini harus menyegarkan token dalam waktu satu jam. SDK Kubernetes klien berikut 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 tambahkan periode kedaluwarsa yang diperpanjang ke token akun layanan selama satu jam default. Untuk cluster Amazon EKS, periode kedaluwarsa yang diperpanjang adalah 90 hari. Server Kubernetes API klaster Amazon EKS Anda menolak permintaan dengan token yang berusia lebih dari 90 hari. Kami menyarankan Anda memeriksa aplikasi Anda dan dependensinya untuk memastikan bahwa SDK klien Kubernetes sama atau lebih lambat dari versi yang tercantum sebelumnya.

Saat server API menerima permintaan dengan token yang berumur lebih dari satu jam, server API akan menganotasi peristiwa log audit API. 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 kontrol, maka anotasi ada di log audit. Anda dapat menggunakan kueri Wawasan CloudWatch Log berikut untuk mengidentifikasi semua Pods di klaster Amazon EKS 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 server API ditolak ketika elapsedtime melebihi 90 hari (7.776.000 detik). Anda harus secara proaktif memperbarui SDK Kubernetes klien aplikasi Anda untuk menggunakan salah satu versi yang tercantum sebelumnya yang secara otomatis menyegarkan token. Jika token akun layanan yang digunakan mendekati 90 hari dan Anda tidak memiliki cukup waktu untuk memperbarui versi SDK klien Anda sebelum token kedaluwarsa, maka Anda dapat menghentikan yang sudah ada Pods dan membuat yang baru. Ini menghasilkan refetching token akun layanan, memberi Anda tambahan 90 hari untuk memperbarui SDK versi klien Anda.

Jika Pod merupakan bagian dari penerapan, cara yang disarankan untuk menghentikan Pods sambil menjaga ketersediaan tinggi adalah dengan melakukan peluncuran dengan perintah berikut. Ganti my-deployment dengan nama penerapan Anda.

kubectl rollout restart deployment/my-deployment

Pengaya klaster

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

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

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

IAM role untuk akun layanan

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

Identitas EKS Pod

EKS Pod 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. EKS Pod Identity hanya untuk EKS, dan sebagai hasilnya, ini 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, EKS API, dan AWS CLI, dan tidak ada tindakan apa pun untuk diambil di dalam cluster di Kubernetes objek apa pun. Administrator klaster tidak perlu beralih antara layanan EKS dan IAM, atau menggunakan operasi IAM istimewa untuk mengonfigurasi izin yang diperlukan oleh aplikasi Anda. Peran IAM sekarang dapat digunakan di beberapa cluster tanpa perlu memperbarui kebijakan kepercayaan peran saat membuat cluster baru. Kredensi IAM yang disediakan oleh EKS Pod Identity mencakup tag sesi peran, dengan atribut seperti nama cluster, 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 Identitas EKS Pod.

Membandingkan Identitas Pod EKS dan IRSA

Pada tingkat tinggi, baik EKS Pod Identity dan IRSA memungkinkan Anda untuk memberikan izin IAM 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.

Identitas Pod EKS IRSA

Ekstensibilitas peran

Anda harus mengatur setiap peran sekali untuk membangun kepercayaan dengan prinsipal layanan Amazon EKS 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 peran IAM dengan titik akhir OIDC penyedia kluster EKS baru setiap kali Anda ingin menggunakan peran dalam klaster baru.

Skalabilitas cluster

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

Setiap kluster EKS memiliki URL penerbit OpenID Connect (OIDC) yang terkait dengannya. Untuk menggunakan IRSA, OpenID Connect penyedia unik perlu dibuat untuk setiap cluster EKS di IAM. IAM memiliki batas global default 100 OIDC penyedia untuk masing-masing Akun AWS. Jika Anda berencana untuk memiliki lebih dari 100 kluster EKS untuk masing-masing Akun AWS dengan IRSA, maka Anda akan mencapai batas penyedia IAMOIDC.

Skalabilitas peran

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

Dalam IRSA, Anda mendefinisikan hubungan kepercayaan antara peran IAM 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 STS Kredensi 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 peran IAM 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 Attribute-based Access Control (ABAC). Untuk informasi selengkapnya, lihat Menentukan izin untuk Identitas Pod EKS untuk mengambil peran berdasarkan tag.

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

Lingkungan didukung

EKS Pod Identity hanya tersedia di Amazon EKS.

IRSA dapat digunakan seperti Amazon EKS, Amazon EKS Anywhere Layanan OpenShift Red Hat di AWS, dan Kubernetes cluster yang dikelola sendiri di instans Amazon EC2.

Versi EKS didukung

KubernetesVersi EKS 1.24 atau yang lebih baru. Untuk versi platform tertentu, lihatEKS Pod Identity versi cluster.

Semua versi cluster EKS yang didukung.