Peran IAM untuk Akun Layanan (IRSA)

Saat pod yang berjalan di EKS perlu memanggil API AWS—misalnya membaca dari S3 atau menulis ke DynamoDB—pod tersebut memerlukan kredensial AWS. Pendekatan sederhana adalah membuat pengguna IAM lalu menuliskan kunci aksesnya secara langsung sebagai variabel lingkungan. Cara ini tidak aman dan melanggar prinsip hak akses paling rendah karena semua pod pada node yang sama berbagi kredensial. Peran IAM untuk Akun Layanan (IRSA) mengatasi masalah ini dengan mengaitkan peran IAM yang terperinci secara langsung ke akun layanan Kubernetes.

IRSA bekerja melalui federasi OpenID Connect (OIDC). EKS membuat penyedia OIDC untuk klaster Anda. Saat pod merujuk ke akun layanan yang diberi anotasi berisi ARN peran IAM, EKS menyuntikkan token akun layanan yang diproyeksikan dan ditandatangani ke dalam pod. AWS SDK di dalam pod menukarkan token ini dengan kredensial AWS sementara menggunakan API AssumeRoleWithWebIdentity milik AWS STS—tanpa memerlukan kunci yang berlaku lama.

Sebelum menggunakan IRSA, Anda harus mengaitkan penerbit OIDC EKS sebagai penyedia identitas tepercaya di akun AWS Anda. Proses ini membuat sumber daya penyedia OIDC IAM yang akan dikenali oleh AWS STS. Perintah eksctl menangani proses ini secara otomatis. Setelah dibuat, Anda dapat memverifikasinya di konsol IAM, pada bagian Identity Providers.

Peran IAM untuk IRSA harus memiliki kebijakan kepercayaan yang mengizinkan penyedia OIDC untuk mengasumsikannya, dengan cakupan pada namespace Kubernetes dan akun layanan tertentu. Kondisi tersebut menggunakan klaim sub dalam token OIDC, yang ditetapkan ke system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Dengan demikian, hanya pod yang menggunakan akun layanan tertentu tersebut yang dapat mengasumsikan peran—bukan sembarang pod dalam klaster.

Buat ServiceAccount Kubernetes di namespace target dan beri anotasi berisi ARN peran IAM. Saat pod merujuk ke akun layanan ini, EKS secara otomatis menyuntikkan token OIDC dan dua variabel lingkungan (AWS_WEB_IDENTITY_TOKEN_FILE dan AWS_ROLE_ARN). AWS SDK secara otomatis mendeteksi keduanya dan memanggil STS untuk mendapatkan kredensial sementara—tidak diperlukan perubahan kode pada aplikasi Anda.

Dalam spesifikasi pod atau deployment Anda, tetapkan serviceAccountName ke akun layanan yang telah diberi anotasi. Saat EKS menjadwalkan pod, EKS secara otomatis memasang token OIDC di /var/run/secrets/eks.amazonaws.com/serviceaccount/token dan menetapkan variabel lingkungan yang diperlukan. Setiap pemanggilan AWS SDK di dalam pod akan menggunakan kredensial peran IAM yang dipetakan secara transparan, tanpa konfigurasi kredensial secara eksplisit.

Dengan peran IAM node, setiap pod pada sebuah node mewarisi izin yang sama—pod yang disusupi dapat mengakses semua layanan AWS yang boleh diakses node tersebut. Dengan IRSA, setiap pod (melalui akun layanannya) hanya mengasumsikan peran yang dibutuhkannya. Hal ini mengikuti prinsip hak akses paling rendah pada tingkat pod dan membatasi dampak dari setiap insiden keamanan. AWS merekomendasikan IRSA daripada peran tingkat node untuk semua deployment EKS baru.

eksctl dapat membuat asosiasi OIDC, peran IAM, kebijakan kepercayaan, dan anotasi ServiceAccount Kubernetes dalam satu perintah menggunakan create iamserviceaccount. Ini adalah cara paling sederhana untuk menyiapkan IRSA tanpa menulis JSON kebijakan kepercayaan secara manual. Anda menentukan namespace, nama akun layanan, dan ARN kebijakan IAM yang akan dilampirkan, lalu eksctl menangani sisanya.

Banyak add-on dan pengontrol EKS memerlukan IRSA agar dapat berfungsi: Cluster Autoscaler memerlukan izin untuk memanggil API Auto Scaling EC2, AWS Load Balancer Controller memerlukan izin untuk membuat dan mengelola sumber daya ELB, external-dns memerlukan akses tulis ke Route 53, dan driver EBS CSI memerlukan izin untuk membuat serta memasang volume EBS. Selalu gunakan IRSA untuk komponen sistem ini—jangan pernah memberikan izin tersebut pada tingkat peran IAM node.

Token IRSA berumur pendek dan diputar secara otomatis oleh pengontrol proyeksi token Kubernetes sebelum kedaluwarsa. Audiens token default adalah sts.amazonaws.com dan masa berlakunya 24 jam, tetapi pengontrol memperbaruinya saat mencapai 80% dari masa berlaku. Kredensial AWS STS yang diperoleh melalui IRSA juga bersifat sementara (biasanya 1 jam). Rotasi otomatis ini menghilangkan beban rotasi kredensial yang muncul pada kunci akses IAM yang berlaku lama.

Setiap kali pod mengasumsikan peran IAM melalui IRSA, AWS CloudTrail mencatat peristiwa AssumeRoleWithWebIdentity. Peristiwa tersebut mencakup ARN peran yang diasumsikan, subjek token OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT), dan IP sumber. Ini menyediakan jejak audit lengkap tentang pod mana yang mengakses layanan AWS mana dan kapan—hal yang sangat penting untuk kepatuhan serta investigasi insiden di lingkungan yang diatur.

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Dalam pelajaran ini Anda telah mempelajari bahwa: IRSA menggunakan federasi OIDC untuk menukarkan token akun layanan Kubernetes dengan kredensial AWS sementara, kebijakan kepercayaan peran IAM membatasi akses ke namespace dan akun layanan tertentu, serta IRSA menyediakan hak akses paling rendah per pod yang jauh lebih baik daripada peran IAM tingkat node. Selanjutnya kita akan membahas Metrik CloudWatch, Namespace, dan Dimensi untuk mengamati sumber daya AWS Anda.