Cloud & IT Cert Prep · Pelajaran

Peranan IAM untuk Akaun Perkhidmatan (IRSA)

Ikat peranan IAM terperinci pada akaun perkhidmatan Kubernetes dengan IRSA supaya pod boleh mengakses perkhidmatan AWS tanpa kebenaran pada peringkat nod.

Pelajaran 4 daripada 413 langkah

Peranan IAM untuk Akaun Perkhidmatan (IRSA) ialah pelajaran Cloud & IT Cert Prep percuma di CoddyKit. Ini ialah pelajaran 4 daripada 4. Anda boleh membaca keseluruhan pelajaran di bawah secara percuma — kemudian berlatih secara praktikal dalam pelayar menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7. Pelajaran ini merupakan sebahagian daripada laluan pembelajaran Cloud & IT Cert Prep, dan kemajuan anda disegerakkan merentas web serta aplikasi CoddyKit. Kursus Cloud & IT Cert Prep merangkumi sejumlah 4 pelajaran.

Masalah IAM Pod

Apabila pod yang berjalan dalam EKS perlu memanggil API AWS — contohnya, membaca daripada S3 atau menulis ke DynamoDB — pod tersebut memerlukan kelayakan AWS. Pendekatan naif adalah dengan mencipta pengguna IAM dan menetapkan kunci aksesnya secara terus sebagai pemboleh ubah persekitaran. Kaedah ini tidak selamat dan melanggar prinsip keistimewaan minimum kerana semua pod pada nod yang sama berkongsi kelayakan tersebut. Peranan IAM untuk Akaun Perkhidmatan (IRSA) menyelesaikan masalah ini dengan memautkan peranan IAM yang terperinci secara terus kepada akaun perkhidmatan Kubernetes.

Cara IRSA Berfungsi: Persekutuan OIDC

IRSA berfungsi melalui persekutuan OpenID Connect (OIDC). EKS mencipta pembekal OIDC untuk kluster anda. Apabila pod merujuk akaun perkhidmatan yang dianotasi dengan ARN peranan IAM, EKS menyuntik token akaun perkhidmatan terunjur yang ditandatangani ke dalam pod. SDK AWS dalam pod menukar token ini dengan kelayakan AWS sementara menggunakan API AssumeRoleWithWebIdentity AWS STS — tiada kunci jangka panjang diperlukan.

# View the OIDC issuer URL for your cluster
aws eks describe-cluster \
  --name my-cluster \
  --query 'cluster.identity.oidc.issuer' \
  --output text

# Example output:
# https://oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEIDSTRING

Langkah 1: Kaitkan Pembekal OIDC

Sebelum menggunakan IRSA, anda mesti mengaitkan penerbit OIDC EKS sebagai pembekal identiti yang dipercayai dalam akaun AWS anda. Tindakan ini mencipta sumber pembekal OIDC IAM yang akan dikenali oleh AWS STS. Perintah eksctl mengendalikan proses ini secara automatik. Setelah dicipta, anda boleh mengesahkannya dalam konsol IAM di bawah Pembekal Identiti.

# Associate the OIDC provider using eksctl (simplest method)
eksctl utils associate-iam-oidc-provider \
  --region us-east-1 \
  --cluster my-cluster \
  --approve

# Verify the provider was created
aws iam list-open-id-connect-providers \
  --query 'OpenIDConnectProviderList[].Arn'

Langkah 2: Cipta Peranan IAM

Peranan IAM untuk IRSA mesti mempunyai dasar kepercayaan yang membenarkan pembekal OIDC mengambil peranan tersebut, dengan skop yang terhad kepada ruang nama Kubernetes dan akaun perkhidmatan tertentu. Syarat ini menggunakan tuntutan sub dalam token OIDC, yang ditetapkan kepada system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Ini memastikan hanya pod yang menggunakan akaun perkhidmatan tertentu itu boleh mengambil peranan tersebut — bukan sebarang pod dalam kluster.

# Trust policy for the IRSA role (JSON)
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {
#       "Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID"
#     },
#     "Action": "sts:AssumeRoleWithWebIdentity",
#     "Condition": {
#       "StringEquals": {
#         "oidc.eks.us-east-1.amazonaws.com/id/EXAMPLEID:sub":
#           "system:serviceaccount:production:s3-reader"
#       }
#     }
#   }]
# }

Langkah 3: Anotasi Akaun Perkhidmatan

Cipta ServiceAccount Kubernetes dalam ruang nama sasaran dan anotasinya dengan ARN peranan IAM. Apabila pod merujuk akaun perkhidmatan ini, EKS menyuntik token OIDC dan dua pemboleh ubah persekitaran (AWS_WEB_IDENTITY_TOKEN_FILE dan AWS_ROLE_ARN) secara automatik. SDK AWS mengesan kedua-duanya secara automatik dan memanggil STS untuk mendapatkan kelayakan sementara — tiada perubahan kod diperlukan dalam aplikasi anda.

# Create and annotate the Kubernetes service account
kubectl create serviceaccount s3-reader -n production

kubectl annotate serviceaccount s3-reader \
  -n production \
  eks.amazonaws.com/role-arn=arn:aws:iam::111122223333:role/S3ReaderRole

# Verify the annotation
kubectl describe serviceaccount s3-reader -n production

Langkah 4: Rujuk Akaun Perkhidmatan dalam Pod

Dalam spesifikasi pod atau penggunaan anda, tetapkan serviceAccountName kepada akaun perkhidmatan yang telah dianotasi. Apabila EKS menjadualkan pod, EKS memasang token OIDC secara automatik di /var/run/secrets/eks.amazonaws.com/serviceaccount/token dan menetapkan pemboleh ubah persekitaran yang diperlukan. Sebarang panggilan SDK AWS dalam pod akan menggunakan kelayakan peranan IAM yang dipetakan secara telus tanpa sebarang konfigurasi kelayakan yang jelas.

# Pod spec using IRSA service account
apiVersion: v1
kind: Pod
metadata:
  name: s3-app
  namespace: production
spec:
  serviceAccountName: s3-reader
  containers:
  - name: app
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-app:latest
    # AWS SDK auto-detects IRSA — no credential config needed
    # AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN are injected

IRSA berbanding Peranan IAM Nod: Perbezaan Utama

Dengan peranan IAM nod, setiap pod pada sesuatu nod mewarisi kebenaran yang sama — pod yang terjejas boleh mengakses semua perkhidmatan AWS yang dibenarkan untuk diakses oleh nod tersebut. Dengan IRSA, setiap pod (melalui akaun perkhidmatannya) hanya mengambil peranan yang diperlukan. Ini mengikuti prinsip keistimewaan minimum pada peringkat pod dan mengehadkan kesan sebarang insiden keselamatan. AWS mengesyorkan IRSA berbanding peranan pada peringkat nod untuk semua penggunaan EKS baharu.

Menggunakan eksctl untuk Mencipta Peranan IRSA

eksctl boleh mencipta perkaitan OIDC, peranan IAM, dasar kepercayaan dan anotasi ServiceAccount Kubernetes dalam satu perintah menggunakan create iamserviceaccount. Ini ialah cara paling mudah untuk menyediakan IRSA tanpa menulis JSON dasar kepercayaan secara manual. Anda menentukan ruang nama, nama akaun perkhidmatan dan ARN dasar IAM yang hendak dilampirkan, kemudian eksctl mengendalikan selebihnya.

# Create everything needed for IRSA in one command
eksctl create iamserviceaccount \
  --name s3-reader \
  --namespace production \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --approve \
  --override-existing-serviceaccounts

IRSA untuk Add-On AWS

Banyak add-on dan pengawal EKS memerlukan IRSA untuk berfungsi: Cluster Autoscaler memerlukan kebenaran untuk memanggil API EC2 Auto Scaling, AWS Load Balancer Controller memerlukan kebenaran untuk mencipta dan mengurus sumber ELB, external-dns memerlukan akses tulis Route 53, dan pemacu EBS CSI memerlukan kebenaran untuk mencipta serta melampirkan volum EBS. Sentiasa gunakan IRSA untuk komponen sistem ini — jangan berikan kebenaran tersebut pada peringkat peranan IAM nod.

# Create IRSA for the EBS CSI driver
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --role-name AmazonEKS_EBS_CSI_DriverRole

Penyegaran Token dan Penggiliran Kelayakan

Token IRSA berumur pendek dan diputar secara automatik oleh pengawal unjuran token Kubernetes sebelum tamat tempoh. Khalayak token lalai ialah sts.amazonaws.com dan tempoh tamatnya ialah 24 jam, tetapi pengawal menyegarkannya apabila 80% daripada jangka hayatnya telah berlalu. Kelayakan AWS STS yang diperoleh melalui IRSA juga bersifat sementara (biasanya 1 jam). Penggiliran automatik ini menghapuskan beban penggiliran kelayakan yang wujud bersama kunci akses IAM berjangka panjang.

# Inspect the projected service account token inside a pod
kubectl exec -n production s3-app -- \
  cat /var/run/secrets/eks.amazonaws.com/serviceaccount/token

# Decode the JWT header and payload to see expiry and audience
# jwt.io or: base64 -d <<< "PAYLOAD_SECTION"

Mengaudit Penggunaan IRSA dengan CloudTrail

Setiap kali pod mengambil peranan IAM melalui IRSA, AWS CloudTrail merekodkan peristiwa AssumeRoleWithWebIdentity. Peristiwa tersebut merangkumi ARN peranan yang diambil, subjek token OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) dan IP sumber. Ini menyediakan jejak audit lengkap tentang pod yang mengakses perkhidmatan AWS tertentu serta masanya — penting untuk pematuhan dan penyiasatan insiden dalam persekitaran yang dikawal selia.

# Search CloudTrail for IRSA calls
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRoleWithWebIdentity \
  --start-time '2024-01-01T00:00:00Z' \
  --query 'Events[].{Time:EventTime,Role:CloudTrailEvent}' \
  --output table

Semakan Pantas

Uji pemahaman anda tentang konsep AWS Solutions Architect (SAA-C03) daripada pelajaran ini.

Jawab dalam pelajaran interaktif

Ulang Kaji Pelajaran

Dalam pelajaran ini anda telah mempelajari bahawa: IRSA menggunakan persekutuan OIDC untuk menukar token akaun perkhidmatan Kubernetes kepada kelayakan AWS sementara, dasar kepercayaan peranan IAM mengehadkan akses kepada ruang nama dan akaun perkhidmatan tertentu, dan IRSA menyediakan keistimewaan minimum bagi setiap pod yang jauh lebih baik berbanding peranan IAM pada peringkat nod. Seterusnya kita akan meneroka Metrics, Namespaces dan Dimensions CloudWatch untuk memantau sumber AWS anda.

Percuma untuk bermula

Pelajari Cloud & IT Cert Prep dengan tutor kecerdasan buatan — percuma

Tulis dan jalankan kod sebenar dalam pelayar anda, dapatkan bantuan segera daripada tutor kecerdasan buatan yang tersedia 24/7, dan sambung semula dari tempat anda berhenti di web atau dalam aplikasi.

Kursus: 150
Pelajaran: 600

Mula belajar secara percuma Lihat kursus penuh

Soalan Lazim

Adakah pelajaran “Peranan IAM untuk Akaun Perkhidmatan (IRSA)” percuma?

Ya — teks penuh “Peranan IAM untuk Akaun Perkhidmatan (IRSA)” boleh dibaca secara percuma di web ini. Untuk berlatih secara interaktif menggunakan penyunting kod terbina dalam dan tutor kecerdasan buatan 24/7, serta membuka kunci baki kursus Cloud & IT Cert Prep, tingkat taraf kepada CoddyKit PRO. Kursus Cloud & IT Cert Prep merangkumi sejumlah 4 pelajaran.

Apakah yang akan saya pelajari dalam “Peranan IAM untuk Akaun Perkhidmatan (IRSA)”?

Ikat peranan IAM terperinci pada akaun perkhidmatan Kubernetes dengan IRSA supaya pod boleh mengakses perkhidmatan AWS tanpa kebenaran pada peringkat nod. Anda berlatih Cloud & IT Cert Prep menggunakan kod praktikal yang dijalankan terus dalam pelayar, manakala tutor kecerdasan buatan 24/7 menjawab soalan anda semasa anda mengikuti pelajaran.

Adakah saya memerlukan pengalaman untuk memulakan Cloud & IT Cert Prep?

Tiada pengalaman terdahulu diperlukan. Pembelajaran Cloud & IT Cert Prep di CoddyKit disusun untuk pelajar daripada peringkat pemula hingga lanjutan, jadi anda boleh bermula di sini atau dari awal dan belajar mengikut kadar anda sendiri. Ini ialah pelajaran 4 daripada 4.

Berapa lamakah pelajaran “Peranan IAM untuk Akaun Perkhidmatan (IRSA)” diambil?

Kebanyakan pelajaran CoddyKit mengambil masa kira-kira 5–10 minit. Setiap pelajaran ringkas dan interaktif, jadi anda boleh membuat kemajuan secara berterusan dan menyambung tepat dari tempat anda berhenti di web atau aplikasi.

Bolehkah saya menulis dan menjalankan kod dalam pelajaran Cloud & IT Cert Prep ini?

Ya. Setiap pelajaran Cloud & IT Cert Prep menyertakan penyunting kod terbina dalam, jadi anda boleh menulis dan menjalankan kod sebenar terus dalam pelayar serta menerima maklum balas kecerdasan buatan serta-merta — tanpa memerlukan persediaan setempat.

Semua pelajaran dalam kursus ini

Satah Kawalan dan Nod Pekerja EKS
Profil Fargate untuk Pod Tanpa Pelayan
Rangkaian EKS: VPC CNI dan Pengimbangan Beban
Peranan IAM untuk Akaun Perkhidmatan (IRSA)

← Kembali ke Cloud & IT Cert Prep