0Pricing
AWS Solutions Architect · บทเรียน

บทบาท IAM สำหรับบัญชีบริการ (IRSA)

ผูกบทบาท IAM แบบละเอียดเข้ากับบัญชีบริการ Kubernetes ด้วย IRSA เพื่อให้พ็อดเข้าถึงบริการ AWS ได้โดยไม่ต้องใช้สิทธิ์ระดับโหนด

บทบาท IAM สำหรับบัญชีบริการ (IRSA) เป็นบทเรียน AWS Solutions Architect ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AWS Solutions Architect และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

ปัญหา IAM ของ Pod

เมื่อ Pod ที่ทำงานอยู่ใน EKS จำเป็นต้องเรียกใช้ API ของ AWS เช่น อ่านข้อมูลจาก S3 หรือเขียนข้อมูลลง DynamoDB ก็จะต้องมีข้อมูลรับรองของ AWS วิธีที่ดูง่ายในตอนแรกคือสร้างผู้ใช้ IAM แล้วกำหนดคีย์การเข้าถึงเป็นตัวแปรสภาพแวดล้อมแบบฝังตายตัว แต่วิธีนี้ไม่ปลอดภัยและละเมิดหลักสิทธิ์เท่าที่จำเป็น เพราะ Pod ทั้งหมดบนโหนดเดียวกันใช้ข้อมูลรับรองร่วมกัน บทบาท IAM สำหรับบัญชีบริการ (IRSA) แก้ปัญหานี้ด้วยการผูกบทบาท IAM ที่กำหนดสิทธิ์อย่างละเอียดเข้ากับบัญชีบริการของ Kubernetes โดยตรง

IRSA ทำงานอย่างไร: การรวมศูนย์ข้อมูลประจำตัวด้วย OIDC

IRSA ทำงานผ่านการรวมศูนย์ข้อมูลประจำตัวด้วย OpenID Connect (OIDC) โดย EKS จะสร้างผู้ให้บริการ OIDC สำหรับคลัสเตอร์ของคุณ เมื่อ Pod อ้างอิงบัญชีบริการที่มีคำอธิบายประกอบเป็น ARN ของบทบาท IAM, EKS จะฉีดโทเค็นบัญชีบริการแบบ projected ที่มีลายเซ็นเข้าไปใน Pod SDK ของ AWS ใน Pod จะแลกเปลี่ยนโทเค็นนี้เป็นข้อมูลรับรอง AWS ชั่วคราวโดยใช้ API AssumeRoleWithWebIdentity ของ AWS STS โดยไม่ต้องใช้คีย์ที่มีอายุยาวนาน

# 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

ขั้นตอนที่ 1: เชื่อมโยงผู้ให้บริการ OIDC

ก่อนใช้ IRSA คุณต้องเชื่อมโยงตัวออกใบรับรอง OIDC ของ EKS ให้เป็นผู้ให้บริการข้อมูลประจำตัวที่เชื่อถือได้ในบัญชี AWS ของคุณ การดำเนินการนี้จะสร้างทรัพยากรผู้ให้บริการ OIDC ของ IAM ที่ AWS STS จะยอมรับ คำสั่ง eksctl จะจัดการขั้นตอนนี้ให้โดยอัตโนมัติ เมื่อสร้างเสร็จแล้ว คุณสามารถตรวจสอบได้ในคอนโซล IAM ภายใต้ผู้ให้บริการข้อมูลประจำตัว

# 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'

ขั้นตอนที่ 2: สร้างบทบาท IAM

บทบาท IAM สำหรับ IRSA ต้องมีนโยบายความน่าเชื่อถือที่อนุญาตให้ผู้ให้บริการ OIDC รับบทบาทนี้ได้ โดยจำกัดขอบเขตไว้ที่เนมสเปซและบัญชีบริการของ Kubernetes ที่ระบุ เงื่อนไขจะใช้ข้ออ้างสิทธิ์ sub ในโทเค็น OIDC ซึ่งกำหนดเป็น system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME วิธีนี้ทำให้มั่นใจได้ว่าเฉพาะ Pod ที่ใช้บัญชีบริการดังกล่าวเท่านั้นที่จะรับบทบาทได้ ไม่ใช่ Pod ใด ๆ ในคลัสเตอร์

# 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"
#       }
#     }
#   }]
# }

ขั้นตอนที่ 3: เพิ่มคำอธิบายประกอบให้บัญชีบริการ

สร้าง ServiceAccount ของ Kubernetes ในเนมสเปซเป้าหมาย แล้วเพิ่มคำอธิบายประกอบด้วย ARN ของบทบาท IAM เมื่อ Pod อ้างอิงบัญชีบริการนี้ EKS จะฉีดโทเค็น OIDC และตัวแปรสภาพแวดล้อมสองรายการ (AWS_WEB_IDENTITY_TOKEN_FILE และ AWS_ROLE_ARN) ให้โดยอัตโนมัติ SDK ของ AWS จะตรวจพบสิ่งเหล่านี้และเรียกใช้ STS เพื่อรับข้อมูลรับรองชั่วคราวโดยอัตโนมัติ โดยไม่ต้องแก้ไขโค้ดในแอปพลิเคชัน

# 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

ขั้นตอนที่ 4: อ้างอิงบัญชีบริการใน Pod

ในข้อกำหนดของ Pod หรือการนำไปใช้งาน ให้กำหนด serviceAccountName เป็นบัญชีบริการที่เพิ่มคำอธิบายประกอบไว้ เมื่อ EKS จัดตารางให้ Pod ระบบจะเมานต์โทเค็น OIDC ที่ /var/run/secrets/eks.amazonaws.com/serviceaccount/token และกำหนดตัวแปรสภาพแวดล้อมที่จำเป็นให้โดยอัตโนมัติ การเรียกใช้ SDK ของ AWS ภายใน Pod จะใช้ข้อมูลรับรองของบทบาท IAM ที่แมปไว้โดยอัตโนมัติ โดยไม่ต้องกำหนดข้อมูลรับรองอย่างชัดเจน

# 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 เทียบกับบทบาท IAM ของโหนด: ความแตกต่างสำคัญ

เมื่อใช้บทบาท IAM ของโหนด Pod ทุกตัวบนโหนดจะได้รับสิทธิ์ชุดเดียวกัน หาก Pod ถูกเจาะระบบ ก็อาจเข้าถึงบริการ AWS ทั้งหมดที่โหนดได้รับอนุญาตให้เข้าถึงได้ แต่เมื่อใช้IRSA แต่ละ Pod (ผ่านบัญชีบริการของตน) จะรับเฉพาะบทบาทที่จำเป็นเท่านั้น วิธีนี้เป็นไปตามหลักสิทธิ์เท่าที่จำเป็นในระดับ Pod และจำกัดขอบเขตความเสียหายจากเหตุการณ์ด้านความปลอดภัย AWS แนะนำให้ใช้ IRSA แทนบทบาทระดับโหนดสำหรับการนำ EKS ไปใช้งานใหม่ทั้งหมด

การใช้ eksctl เพื่อสร้างบทบาท IRSA

eksctl สามารถสร้างการเชื่อมโยง OIDC, บทบาท IAM, นโยบายความน่าเชื่อถือ และคำอธิบายประกอบของ ServiceAccount ใน Kubernetes ได้ด้วยคำสั่งเดียวโดยใช้ create iamserviceaccount นี่เป็นวิธีที่ง่ายที่สุดในการตั้งค่า IRSA โดยไม่ต้องเขียน JSON ของนโยบายความน่าเชื่อถือด้วยตนเอง คุณเพียงระบุเนมสเปซ ชื่อบัญชีบริการ และ ARN ของนโยบาย IAM ที่ต้องการแนบ จากนั้น eksctl จะจัดการส่วนที่เหลือให้

# 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 สำหรับส่วนเสริมของ AWS

ส่วนเสริมและตัวควบคุมของ EKS จำนวนมากต้องใช้ IRSA จึงจะทำงานได้: ตัวปรับขนาดอัตโนมัติของคลัสเตอร์ต้องมีสิทธิ์เรียกใช้ API ของการปรับขนาดอัตโนมัติของ EC2, ตัวควบคุมตัวจัดสรรภาระงานของ AWSต้องมีสิทธิ์สร้างและจัดการทรัพยากร ELB, external-dnsต้องมีสิทธิ์เขียนใน Route 53 และไดรเวอร์ EBS CSIต้องมีสิทธิ์สร้างและเชื่อมต่อโวลุ่ม EBS โปรดใช้ IRSA กับองค์ประกอบระบบเหล่านี้เสมอ อย่ามอบสิทธิ์เหล่านี้ในระดับบทบาท IAM ของโหนด

# 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

การรีเฟรชโทเค็นและการหมุนเวียนข้อมูลรับรอง

โทเค็น IRSA มีอายุสั้นและถูกหมุนเวียนโดยอัตโนมัติโดยตัวควบคุมการฉายโทเค็นของ Kubernetes ก่อนหมดอายุ ผู้รับโทเค็นเริ่มต้นคือ sts.amazonaws.com และมีอายุ 24 ชั่วโมง แต่ตัวควบคุมจะรีเฟรชโทเค็นเมื่อผ่านไป 80% ของอายุโทเค็น ข้อมูลรับรอง AWS STS ที่ได้รับผ่าน IRSA ก็เป็นข้อมูลชั่วคราวเช่นกัน (โดยทั่วไปมีอายุ 1 ชั่วโมง) การหมุนเวียนโดยอัตโนมัตินี้ช่วยขจัดภาระในการหมุนเวียนข้อมูลรับรองที่เกิดจากคีย์การเข้าถึง IAM ซึ่งมีอายุยาวนาน

# 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"

การตรวจสอบการใช้งาน IRSA ด้วย CloudTrail

ทุกครั้งที่ Pod รับบทบาท IAM ผ่าน IRSA, AWS CloudTrail จะบันทึกเหตุการณ์ AssumeRoleWithWebIdentity เหตุการณ์ดังกล่าวประกอบด้วย ARN ของบทบาทที่รับ ข้อมูลประธานของโทเค็น OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) และ IP ต้นทาง จึงมีบันทึกการตรวจสอบที่ครบถ้วนว่า Pod ใดเข้าถึงบริการ AWS ใดและเมื่อใด ซึ่งสำคัญอย่างยิ่งต่อการปฏิบัติตามข้อกำหนดและการตรวจสอบเหตุการณ์ในสภาพแวดล้อมที่อยู่ภายใต้การกำกับดูแล

# 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

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด AWS Solutions Architect (SAA-C03) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า IRSA ใช้การรวมศูนย์ข้อมูลประจำตัวด้วย OIDC เพื่อแลกเปลี่ยนโทเค็นบัญชีบริการของ Kubernetes เป็นข้อมูลรับรอง AWS ชั่วคราว, นโยบายความน่าเชื่อถือของบทบาท IAMจำกัดการเข้าถึงไว้ที่เนมสเปซและบัญชีบริการที่ระบุ และIRSA มอบสิทธิ์เท่าที่จำเป็นแยกตาม Pod ซึ่งเหนือกว่าบทบาท IAM ระดับโหนดอย่างมาก บทถัดไปเราจะสำรวจ Metrics, Namespaces และ Dimensions ของ CloudWatch เพื่อใช้สังเกตทรัพยากร AWS ของคุณ

คำถามที่พบบ่อย

บทเรียน “บทบาท IAM สำหรับบัญชีบริการ (IRSA)” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “บทบาท IAM สำหรับบัญชีบริการ (IRSA)” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AWS Solutions Architect ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AWS Solutions Architect มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “บทบาท IAM สำหรับบัญชีบริการ (IRSA)”

ผูกบทบาท IAM แบบละเอียดเข้ากับบัญชีบริการ Kubernetes ด้วย IRSA เพื่อให้พ็อดเข้าถึงบริการ AWS ได้โดยไม่ต้องใช้สิทธิ์ระดับโหนด คุณปฏิบัติ AWS Solutions Architect ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AWS Solutions Architect หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AWS Solutions Architect บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “บทบาท IAM สำหรับบัญชีบริการ (IRSA)” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AWS Solutions Architect นี้ได้ไหม

ได้ บทเรียน AWS Solutions Architect ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. ระนาบควบคุมและโหนดผู้ปฏิบัติงานของ EKS
  2. โปรไฟล์ Fargate สำหรับพ็อดแบบไร้เซิร์ฟเวอร์
  3. เครือข่าย EKS: VPC CNI และการทำโหลดบาลานซ์
  4. บทบาท IAM สำหรับบัญชีบริการ (IRSA)
← กลับไปที่ AWS Solutions Architect