AWS Solutions Architect · درس

أدوار IAM لحسابات الخدمة (IRSA)

اربط أدوار IAM دقيقة الصلاحيات بحسابات خدمة Kubernetes باستخدام IRSA، حتى تتمكن الحُزم من الوصول إلى خدمات AWS دون أذونات على مستوى العُقد

أدوار IAM لحسابات الخدمة (IRSA) درس مجاني في AWS Solutions Architect على CoddyKit. هذا هو الدرس 4 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AWS Solutions Architect، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

مشكلة IAM في Pod

عندما يحتاج Pod يعمل في EKS إلى استدعاء واجهة برمجة تطبيقات AWS — مثل القراءة من S3 أو الكتابة إلى DynamoDB — فإنه يحتاج إلى بيانات اعتماد AWS. النهج البسيط هو إنشاء مستخدم IAM وتضمين مفاتيح الوصول الخاصة به مباشرةً في متغيرات البيئة. وهذا غير آمن وينتهك مبدأ أقل قدر من الصلاحيات، لأن جميع Pods الموجودة على العقدة نفسها تتشارك بيانات الاعتماد. يحل IAM Roles for Service Accounts (IRSA) هذه المشكلة من خلال ربط أدوار IAM دقيقة مباشرةً بحسابات خدمة Kubernetes.

كيفية عمل IRSA: اتحاد OIDC

يعمل IRSA من خلال اتحاد OpenID Connect (OIDC). ينشئ EKS موفّر OIDC لمجموعتك. عندما يشير Pod إلى حساب خدمة مرفق به تعليق يحتوي على ARN لدور IAM، يحقن EKS في Pod رمزًا مميزًا مُسقَطًا لحساب الخدمة وموقّعًا. تستبدل AWS SDK الموجودة في Pod هذا الرمز المميز ببيانات اعتماد AWS مؤقتة باستخدام واجهة برمجة التطبيقات 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 الخاص بكم. يؤدي ذلك إلى إنشاء مورد موفّر IAM OIDC سيتعرّف عليه 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. ويضمن ذلك أن Pods التي تستخدم حساب الخدمة المحدد فقط يمكنها تولّي الدور، وليس أي 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 في مساحة الأسماء المستهدفة، وأضيفوا إليه تعليقًا يتضمن ARN لدور IAM. عندما يشير Pod إلى حساب الخدمة هذا، يحقن EKS رمز OIDC المميز ومتغيري البيئة (AWS_WEB_IDENTITY_TOKEN_FILE وAWS_ROLE_ARN) تلقائيًا. تكتشف AWS SDK هذين المتغيرين تلقائيًا، وتستدعي 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: الإشارة إلى حساب الخدمة في Pods

في مواصفات Pod أو عملية النشر، اضبطوا serviceAccountName على حساب الخدمة الذي أُضيف إليه التعليق. عندما يجدول EKS الـPod، فإنه يحمّل رمز OIDC المميز تلقائيًا في المسار /var/run/secrets/eks.amazonaws.com/serviceaccount/token ويضبط متغيرات البيئة المطلوبة. وستستخدم أي مكالمة إلى AWS SDK داخل 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 وسياسة الثقة والتعليق الخاص بـKubernetes ServiceAccount في أمر واحد باستخدام 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 لكي تعمل: يحتاج Cluster Autoscaler إلى صلاحية استدعاء واجهة Auto Scaling API الخاصة بـEC2، ويحتاج AWS Load Balancer Controller إلى صلاحية إنشاء موارد ELB وإدارتها، ويحتاج external-dns إلى صلاحية الكتابة في Route 53، كما يحتاج EBS CSI driver إلى صلاحية إنشاء وحدات تخزين 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 مؤقتة أيضًا، وتبلغ مدتها عادةً ساعة واحدة. يلغي هذا التدوير التلقائي عبء تدوير بيانات الاعتماد الملازم لمفاتيح وصول 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 المصدر. ويوفر ذلك سجل تدقيق كاملًا يوضح أي Pods وصلت إلى أي خدمات 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 على مستوى العقدة. بعد ذلك سنستكشف المقاييس ومساحات الأسماء والأبعاد في CloudWatch لمراقبة موارد AWS الخاصة بكم.

الأسئلة الشائعة

هل درس «أدوار IAM لحسابات الخدمة (IRSA)» مجاني؟

نعم — نص درس «أدوار IAM لحسابات الخدمة (IRSA)» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AWS Solutions Architect، انتقل إلى CoddyKit PRO. تتضمن دورة AWS Solutions Architect 4 دروس في المجموع.

ماذا ستتعلم في «أدوار IAM لحسابات الخدمة (IRSA)»؟

اربط أدوار IAM دقيقة الصلاحيات بحسابات خدمة Kubernetes باستخدام IRSA، حتى تتمكن الحُزم من الوصول إلى خدمات AWS دون أذونات على مستوى العُقد تتمرن على AWS Solutions Architect مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AWS Solutions Architect؟

لا تُشترط خبرة سابقة. AWS Solutions Architect على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 4 من أصل 4.

كم من الوقت يستغرق درس «أدوار IAM لحسابات الخدمة (IRSA)»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AWS Solutions Architect هذا؟

نعم. كل درس في AWS Solutions Architect يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى AWS Solutions Architect