AWS IAM Authenticator for Kubernetes

أداة لاستخدام بيانات اعتماد AWS IAM للمصادقة على مجموعة Kubernetes. كان العمل الأولي على هذه الأداة بقيادة Heptio. يتلقى المشروع مساهمات من عدة مهندسين من المجتمع، ويُدار حاليًا بواسطة Heptio ومهندسي Amazon EKS مفتوحة المصدر.

Table of Contents

• لماذا أحتاج هذا؟
• كيف أستخدمه؟
• استخدام Kops
• كيف يعمل؟
• ما هو معرّف المجموعة؟
• تحديد بيانات الاعتماد واستخدام ملفات تعريف AWS
• تفويض API من خارج المجموعة
• استكشاف الأخطاء وإصلاحها
• صيغة التكوين الكاملة
• التطوير
• المجتمع والنقاش والمساهمة والدعم

لماذا أحتاج هذا؟

إذا كنت مسؤولًا تدير مجموعة Kubernetes على AWS، فأنت بالفعل بحاجة إلى إدارة بيانات اعتماد AWS IAM لتوفير المجموعة وتحديثها. باستخدام AWS IAM Authenticator for Kubernetes، تتجنب الحاجة إلى إدارة بيانات اعتماد منفصلة للوصول إلى Kubernetes. توفر AWS IAM أيضًا عددًا من الخصائص المفيدة مثل سجل تدقيق خارج النطاق (عبر CloudTrail) وفرض المصادقة الثنائية (2FA/MFA).

إذا كنت تبني مثبّت Kubernetes على AWS، فإن AWS IAM Authenticator for Kubernetes يمكنه تبسيط عملية الإقلاع لديك. لن تحتاج إلى تهريب بيانات اعتماد المسؤول الأولية بأمان من مجموعتك المثبتة حديثًا. بدلاً من ذلك، يمكنك إنشاء دور مخصص KubernetesAdmin في وقت توفير المجموعة وإعداد Authenticator للسماح بتسجيل دخول مسؤولي المجموعة.

كيف أستخدمه؟

بافتراض أن لديك مجموعة تعمل على AWS وتريد إضافة دعم AWS IAM Authenticator for Kubernetes، ستحتاج إلى:

1. إنشاء دور IAM ستستخدمه لتحديد هوية المستخدمين.
2. تشغيل خادم Authenticator كـ DaemonSet.
3. تكوين خادم API الخاص بك للتواصل مع Authenticator.
4. إعداد kubectl لاستخدام رموز Authenticator.

1. إنشاء دور IAM

أولاً، يجب عليك إنشاء دور IAM واحد أو أكثر سيتم تعيينه للمستخدمين/المجموعات داخل مجموعة Kubernetes الخاصة بك. أسهل طريقة للقيام بذلك هي تسجيل الدخول إلى وحدة تحكم AWS:

• اختر خيار "Role for cross-account access" / "Provide access between AWS accounts you own".
• الصق رقم معرف حساب AWS الخاص بك (متوفر في أعلى اليمين في وحدة التحكم).
• لا يحتاج دورك إلى أي سياسات إضافية مرفقة.

سيؤدي هذا إلى إنشاء دور IAM بدون أذونات يمكن أن تفترضه المستخدمون/الأدوار المصرح لهم في حسابك. لاحظ Amazon Resource Name (ARN) لدورك، والذي ستحتاجه أدناه.

يمكنك أيضًا القيام بذلك في خطوة واحدة باستخدام AWS CLI بدلاً من وحدة تحكم AWS:```sh

get your account ID

ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')

define a role trust policy that opens the role to users in your account (limited by IAM policy)

POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')

create a role named KubernetesAdmin (will print the new role's ARN)

aws iam create-role
--role-name KubernetesAdmin
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)."
--assume-role-policy-document "$POLICY"
--output text
--query 'Role.Arn'

يمكنك أيضًا تخطي هذه الخطوة واستخدام:
 - دور موجود (مثل دور وصول عبر الحسابات).
 - مستخدم IAM (انظر `mapUsers` أدناه).
 - مثيل EC2 أو دور موحّد (انظر `mapRoles` أدناه).

### 2. تشغيل الخادم
من المفترض أن يعمل الخادم على كل عقدة من عُقدك الرئيسية كـ DaemonSet مع شبكة المضيف بحيث يمكنه كشف منفذ localhost.

للحصول على نموذج لإعداد ConfigMap وDaemonSet، راجع [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/deploy/example.yaml).
قبل تطبيقه، حدّث هذه القيم لكلاسترك:
 - استبدل عناصر IAM ARNs النائبة (`arn:aws:iam::000000000000:...`) في `config.yaml`.
 - اضبط `clusterID` على قيمة فريدة لكلاسترك.
 - تحقق من أن قواعد جدولة DaemonSet تتطابق مع تسميات/taints لعُقد control-plane.

ثم انشره:```sh
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator

بمجرد تشغيل Pod على عقدة مستوى التحكم، سيقوم aws-iam-authenticator server بإنشاء ملف kubeconfig الخاص بـ webhook على المضيف في المسار /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (أو المسار المُكوَّن عبر --generate-kubeconfig).

(اختياري) إنشاء شهادة ومفتاح وkubeconfig مسبقًا

إذا كنت تبني أداة تثبيت آلية، يمكنك أيضًا إنشاء ملفات الشهادة والمفتاح وkubeconfig الخاصة بـ webhook مسبقًا بسهولة باستخدام aws-iam-authenticator init. ينشئ هذا الأمر الملفات ويضعها في دلائل المخرجات المُكوَّنة.

يمكنك تشغيل هذا على كل عقدة رئيسية قبل بدء تشغيل خادم API. يمكنك أيضًا إنشاؤها قبل توفير العقد الرئيسية وتثبيتها في مسارات المضيف المناسبة.

إذا لم تقم بإنشاء الملفات مسبقًا، فسيقوم aws-iam-authenticator server بإنشائها عند الطلب. هذا يعمل، لكنه يتطلب إعادة تشغيل خادم Kubernetes API بعد التثبيت.

3. تكوين خادم API الخاص بك ليتواصل مع الخادم

تتكامل Kubernetes API مع AWS IAM Authenticator for Kubernetes باستخدام webhook لمصادقة الرموز. عند تشغيل aws-iam-authenticator server، سينشئ ملف تكوين webhook ويحفظه على نظام ملفات المضيف. ستحتاج إلى إضافة flag إضافي واحد إلى تكوين خادم API الخاص بك:``` --authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml

في العديد من العناقيد، يعمل خادم API كبودٍ ثابت.
يمكنك إضافة الخيار إلى `/etc/kubernetes/manifests/kube-apiserver.yaml`.
تأكد من أن دليل المضيف `/etc/kubernetes/aws-iam-authenticator/` مركّب داخل بود خادم API الخاص بك.
قد تحتاج أيضًا إلى إعادة تشغيل الخفي kubelet على عقدتك الرئيسية لتطبيق تعريف البود الثابت المحدّث:```
systemctl restart kubelet.service

4. إنشاء تعيينات دور/مستخدم IAM إلى مستخدم/مجموعة Kubernetes

السلوك الافتراضي للخادم هو جلب التعيينات حصرياً من حقلَي mapUsers وmapRoles في ملف الإعداد الخاص به. انظر تنسيق الإعداد الكامل أدناه للحصول على التفاصيل.

باستخدام علامة --backend-mode، يمكنك تكوين الخادم ليجلب التعيينات من خلفيتين إضافيتين: ConfigMap بنمط EKS (--backend-mode=EKSConfigMap) أو موارد مخصصة IAMIdentityMapping (--backend-mode=CRD). الخلفية الافتراضية، وهي ملف إعداد الخادم المثبَّت بواسطة بود الخادم، تقابل --backend-mode=MountedFile.

يمكنك تمرير قائمة مفصولة بفواصل من هذه الخلفيات ليقوم الخادم بالبحث فيها بالترتيب. على سبيل المثال، مع --backend-mode=EKSConfigMap,MountedFile، سيبحث الخادم في ConfigMap بنمط EKS عن التعيينات ثم، إذا لم يعثر على تعيين لدور/مستخدم IAM المحدد، يبحث في ملف إعداد الخادم. إذا وُجد تعيين لنفس دور/مستخدم IAM في خلفيات متعددة، سيستخدم الخادم التعيين الموجود في الخلفية التي تظهر أولاً في القائمة المفصولة بفواصل. في هذا المثال، إذا وُجد تعيين في EKS ConfigMap فسيتم استخدامه سواء وُجد تعيين مكرر أو متعارض في ملف إعداد الخادم أم لا.

لاحظ أنه عند تعيين خلفية واحدة فقط، سيلجأ الخادم فقط إلى تلك الخلفية ويتجاهل الأخرى حتى لو كانت موجودة. على سبيل المثال، مع --backend-mode=CRD، سيلجأ الخادم فقط إلى IAMIdentityMappings ويتجاهل الملف المثبّت وEKS ConfigMap.

MountedFile

هذه هي الخلفية الافتراضية للتعيينات وهي كافية لمعظم المستخدمين. انظر تنسيق الإعداد الكامل أدناه للحصول على التفاصيل.

CRD (alpha)

تعمل هذه الخلفية على تمثيل كل تعيين IAM كمورد IAMIdentityMapping مورد مخصص في Kubernetes. هذا النهج يتيح لك الحفاظ على التعيينات بطريقة أصلية في Kubernetes باستخدام kubectl أو واجهة API. بالإضافة إلى ذلك، يمكن رصد أخطاء الصياغة (مثل YAML غير المحاذى) بسهولة أكبر ولن تؤثر على جميع التعيينات.

لإعداد CRD من نوع IAMIdentityMapping، ستحتاج أولاً إلى تنفيذ أمر apply على manifest الخاص بـ CRD:``` kubectl apply -f deploy/iamidentitymapping.yaml

بعد نشر وحدات CRD، يمكنك بعد ذلك إنشاء موارد مخصصة (Custom Resources) تمثل
هويات IAM الخاصة بك. انظر
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/deploy/example-iamidentitymapping.yaml):```
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
  name: kubernetes-admin
spec:
  # Arn of the User or Role to be allowed to authenticate
  arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
  # Username that Kubernetes will see the user as, this is useful for setting
  # up allowed specific permissions for different users
  username: kubernetes-admin
  # Groups to be attached to your users/roles. For example `system:masters` to
  # create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
  # access the API server.
  groups:
  - system:masters

EKSConfigMap

يعمل ConfigMap بنمط EKS باسم kube-system/aws-auth كخلفية للخدمة. من المتوقع أن يكون ConfigMap بنفس التنسيق تمامًا كما في مجموعات EKS: https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. هذا مفيد إذا كنت تنتقل من EKS أو إليها وتريد الاحتفاظ بتعييناتك، أو إذا كنت تشغّل EKS بالإضافة إلى مجموعة أو أكثر من مجموعات AWS الأخرى وتريد نفس التعيينات في كل منها.

DynamicFile

يمكن لملف محلي محدد عبر cfg.dynamicfilepath أن يعمل كخلفية للخدمة. من المتوقع أن يكون محتوى الملف بنفس التنسيق تمامًا مثل EKSConfigMap. كلما تغيّر محتوى هذا الملف، سيقوم المصادق (authenticator) بإعادة تحميله تلقائيًا. وهذا يوفر مرونة أكبر في إدارة تعيينات ARN.

تحقق من https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml لمعرفة كيفية تكوين وضع DynamicFile.

شغّل make e2e RUNNER=kind للتجربة على مجموعة kind مع تفعيل وضع DynamicFile.

5. كيفية تكوين reservedPrefixConfig لأسماء مستخدمي Kubernetes

يمكن أن يدعم aws-iam-authenticator بادئة محجوزة لاسم مستخدم k8s. إذا تم تعيين البادئة المحجوزة، فإن اسم المستخدم الذي يبدأ بالبادئة المحجوزة لن يتم توثيقه، مع ظهور الخطأ "username must not begin with with the following prefixes:".

تحقق من https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml لمعرفة كيفية تكوين البادئة المحجوزة.

6. إعداد kubectl لاستخدام رموز المصادقة المقدمة من AWS IAM Authenticator for Kubernetes

أخيرًا، بعد إعداد الخادم، ستحتاج إلى المصادقة. ستظل بحاجة إلى kubeconfig يحتوي على البيانات العامة حول مجموعتك (شهادة CA للمجموعة، وعنوان نقطة النهاية). ومع ذلك، يجب أن يتضمن قسم users في إعداداتك قسم exec (راجع مستندات المكوّن الإضافي لبيانات اعتماد kubectl):```yaml

[...]

users:

• name: kubernetes-admin user: exec: apiVersion: client.authentication.k8s.io/v1beta1 command: aws-iam-authenticator args: - "token" - "-i" - "REPLACE_ME_WITH_YOUR_CLUSTER_ID" - "-r" - "REPLACE_ME_WITH_YOUR_ROLE_ARN"

  no client certificate/key needed here!

هذا يعني أن `kubeconfig` هو بيانات عامة بالكامل ويمكن مشاركته بين جميع مستخدمي Authenticator.
قد يكون من المنطقي رفعه إلى موقع عام موثوق مثل AWS S3.

تأكد من تثبيت الثنائي `aws-iam-authenticator`.
يمكنك تثبيته باستخدام `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest`.

للمصادقة، شغّل `kubectl --kubeconfig /path/to/kubeconfig" [...]`.
سيقوم kubectl بتنفيذ (`exec`) الثنائي `aws-iam-authenticator` مع المعاملات المقدمة في kubeconfig الخاص بك، مما سيولّد رمزًا مميزًا (token) ويمرّره إلى خادم API (apiserver).
الرمز المميز صالح لمدة 15 دقيقة (أقصر قيمة تسمح بها AWS) ويمكن إعادة استخدامه عدة مرات.

يمكنك أيضًا تحديد اسم الجلسة عند إنشاء الرمز المميز من خلال تضمين المعامل `--session-name or -s`. لا يمكن استخدام هذا المعامل مع `--forward-session-name`.

يمكنك أيضًا حذف `-r ROLE_ARN` لتوقيع الرمز المميز ببيانات اعتمادك الحالية دون افتراض دور مخصص.
هذا مفيد إذا كنت تريد المصادقة كمستخدم IAM مباشرةً، أو إذا كنت تريد المصادقة باستخدام دور مثيل EC2 أو دور موحّد (federated role).

## استخدام Kops
يمكن تهيئة المجموعات (Clusters) المُدارة بواسطة [Kops](https://github.com/kubernetes/kops) لاستخدام Authenticator. للحصول على تعليمات الاستخدام، راجع [وثائق Kops](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).

## كيف يعمل؟
يعمل باستخدام نقطة نهاية API الخاصة بـ AWS [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html).
تُرجع هذه النقطة معلومات حول أي بيانات اعتماد AWS IAM تستخدمها للاتصال بها.

#### جانب العميل (`aws-iam-authenticator token`)
نستخدم هذه الـ API بطريقة غير اعتيادية إلى حدٍ ما، حيث يقوم عميل Authenticator بتوليد طلب إلى نقطة النهاية وتوقيعه مسبقًا.
نقوم بتسلسل (serialize) هذا الطلب إلى رمز مميز يمكنه المرور عبر نظام مصادقة Kubernetes.

#### جانب الخادم (`aws-iam-authenticator server`)
يتم تمرير الرمز المميز عبر خادم API الخاص بـ Kubernetes إلى نقطة نهاية `/authenticate` في خادم Authenticator عبر إعداد webhook.
يتحقق خادم Authenticator من جميع معاملات الطلب الموقّع مسبقًا للتأكد من عدم وجود أي شيء مريب.
ثم يرسل الطلب إلى الخادم الحقيقي `https://sts.amazonaws.com`، الذي يتحقق من توقيع HMAC الخاص بالعميل ويعيد معلومات عن المستخدم.
الآن بعد أن يعرف الخادم هوية AWS للعميل، يترجم هذه الهوية إلى مستخدم ومجموعات Kubernetes عبر تعيين ثابت بسيط.

هذه الآلية مستعارة مع بعض التعديلات من [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method).

## ما هو معرّف المجموعة (Cluster ID)؟
معرّف المجموعة في Authenticator هو معرّف فريد لكل مجموعة يمنع هجمات إعادة التشغيل (replay attacks) معينة.
تحديدًا، يمنع خادم Authenticator واحدًا (مثلًا في بيئة تطوير) من استخدام رمز عميل للمصادقة على خادم Authenticator آخر في مجموعة مختلفة.

يجب أن يكون معرّف المجموعة فريدًا لكل مجموعة، لكن لا يلزم أن يكون سرًا.
بعض الخيارات الجيدة هي:
 - معرّف عشوائي مثل الناتج عن `openssl rand 16 -hex`
 - اسم النطاق لخادم API الخاص بـ Kubernetes

تشرح [وثائق Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) هذا الهجوم أيضًا (انظر `X-Vault-AWS-IAM-Server-ID`).

## تحديد بيانات الاعتماد واستخدام ملفات تعريف AWS
يمكن تحديد بيانات الاعتماد لاستخدامها مع `aws-iam-authenticator` عبر أي من الطرق المتاحة في
[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials).
يتضمن ذلك تحديد بيانات اعتماد AWS باستخدام متغيرات البيئة أو عبر استخدام ملف بيانات اعتماد.

تدعم أداة `aws-iam-authenticator` [الملفات الشخصية المسماة](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) في AWS
عبر متغير البيئة `AWS_PROFILE`. على سبيل المثال، للمصادقة باستخدام بيانات الاعتماد المحددة في ملف التعريف _dev_، يمكن تصدير `AWS_PROFILE`
أو تحديده صراحةً (مثلًا: `AWS_PROFILE=dev kubectl get all`). إذا لم يتم تعيين `AWS_PROFILE`، يتم استخدام ملف التعريف _default_.

يمكن أيضًا تحديد `AWS_PROFILE` مباشرة في ملف kubeconfig
[كجزء من تدفق `exec`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration). على سبيل المثال، لتحديد
أن بيانات الاعتماد من ملف التعريف المسمى _dev_ يجب أن تُستخدم دائمًا بواسطة `aws-iam-authenticator`، يجب أن يتضمن ملف kubeconfig الخاص بك مفتاح `env`
يضبط ملف التعريف:```yaml
apiVersion: v1
clusters:
- cluster:
    server: ${server}
    certificate-authority-data: ${cert}
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws-iam-authenticator
      env:
      - name: "AWS_PROFILE"
        value: "dev"
      args:
        - "token"
        - "-i"
        - "mycluster"

هذه الطريقة تسمح باستخدام الملف الشخصي المناسب بشكل ضمني. لاحظ أن أي متغيرات بيئة يتم تعيينها كجزء من تدفق exec ستكون لها الأولوية على ما هو مضبوط مسبقًا في بيئتك.

ملاحظة لمستخدمي الاتحاد:

غالبًا ما يكون لدى مستخدمي AWS عبر الاتحاد سمة "ذات معنى" مُربوطة بالدور المفترض، مثل عنوان بريد إلكتروني، من خلال تكوين AWS للحساب. تحتوي هذه الجلسات المفترضة على أجزاء قليلة، وهي role id و caller-specified-role-name. افتراضيًا، عندما يستخدم مستخدم عبر الاتحاد خيار --role الخاص بـ aws-iam-authenticator لافتراض دور جديد، سيتم تحويل caller-specified-role-name إلى رمز عشوائي بينما ينتقل role id إلى الدور المفترض الجديد.

سيؤدي استخدام aws-iam-authenticator token ... --forward-session-name إلى تعيين سمة caller-specified-role-name الأصلية على جلسة STS المفترضة الجديدة. يمكن أن يكون هذا مفيدًا لمحاولة الربط سريعًا بين "من نفّذ الإجراء X على مجموعة K8".

يرجى ملاحظة أن هذا لا ينبغي اعتباره نهائيًا ويجب التحقق منه بالرجوع إلى role id (الذي يبقى ثابتًا) مع سجلات CloudTrail نظرًا لأنه يمكن للمستخدم تغيير ذلك من جانب العميل.

ترخيص API من خارج المجموعة

من الممكن إرسال طلبات إلى Kubernetes API من عميل خارج المجموعة، سواء كان ذلك باستخدام REST API الخام لـ Kubernetes أو عبر أحد عملاء Kubernetes المخصصين للغات برمجية معينة (مثلًا، Python). للقيام بذلك، يجب إنشاء رمز حامل (bearer token) يُضمّن مع الطلب إلى API. يتطلب هذا الرمز إلحاق السلسلة k8s-aws-v1. مع سلسلة مشفرة بـ base64 لطلب HTTP موقع مُرسل إلى واجهة برمجة تطبيقات الاستعلام STS GetCallerIdentity. يتم بعد ذلك إرساله في ترويسة Authorization الخاصة بالطلب. تجدر الإشارة إلى أن IAM Authenticator يستبعد صراحةً حشو base64 لتجنب أي أحرف =، مما يضمن سلسلة آمنة للاستخدام في عناوين URL. فيما يلي مثال بلغة Python يوضح كيفية إنشاء هذا الرمز:```python import base64 import boto3 import re from botocore.signers import RequestSigner

def get_bearer_token(cluster_id, region): STS_TOKEN_EXPIRES_IN = 60 session = boto3.session.Session()

client = session.client('sts', region_name=region)
service_id = client.meta.service_model.service_id

signer = RequestSigner(
    service_id,
    region,
    'sts',
    'v4',
    session.get_credentials(),
    session.events
)

params = {
    'method': 'GET',
    'url': 'https://sts.{}.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15'.format(region),
    'body': {},
    'headers': {
        'x-k8s-aws-id': cluster_id
    },
    'context': {}
}

signed_url = signer.generate_presigned_url(
    params,
    region_name=region,
    expires_in=STS_TOKEN_EXPIRES_IN,
    operation_name=''
)

base64_url = base64.urlsafe_b64encode(signed_url.encode('utf-8')).decode('utf-8')

# remove any base64 encoding padding:
return 'k8s-aws-v1.' + re.sub(r'=*', '', base64_url)

If making a HTTP request you would create the authorization headers as follows:

headers = {'Authorization': 'Bearer ' + get_bearer_token('my_cluster', 'us-east-1')}

## استكشاف الأخطاء وإصلاحها

إذا فشل عميلك مع خطأ مثل `could not get token: AccessDenied [...]`، يمكنك محاولة تولّي الدور مباشرةً باستخدام AWS CLI:```sh
# AWS CLI version of `aws-iam-authenticator token -r arn:aws:iam::ACCOUNT:role/ROLE`:
$ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE --role-session-name test

إذا فشل ذلك، فهناك بعض المشكلات المحتملة التي يجب التحقق منها:

• تأكد من أن بيانات اعتماد AWS الأساسية متوفرة في الصدفة لديك (يمكن أن يساعد aws sts get-caller-identity في استكشاف ذلك).

• تأكد من أن الدور الهدف يسمح بالوصول إلى حساب المصدر (في سياسة الثقة الخاصة بالدور).

• تأكد من أن المدير الرئيسي للمصدر (مستخدم/دور/مجموعة) لديه سياسة IAM تسمح بـ sts:AssumeRole للدور الهدف.

• تأكد من عدم وجود أي سياسات رفض صريحة مرتبطة بمستخدمك أو مجموعتك أو في AWS Organizations قد تمنع sts:AssumeRole.

• جرب محاكاة استدعاء sts:AssumeRole في محاكي السياسات.

تنسيق التكوين الكامل

يستخدم العميل والخادم نفس تنسيق التكوين. يمكنهما مشاركة نفس ملف التكوين تمامًا، حيث لا توجد أسرار مخزنة في التكوين.```yaml

a unique-per-cluster identifier to prevent replay attacks (see above)

clusterID: my-dev-cluster.example.com

default IAM role to assume for aws-iam-authenticator token

defaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin

server listener configuration

server:

localhost port where the server will serve the /authenticate endpoint

port: 21362 # (default)

state directory for generated TLS certificate and private keys

stateDir: /var/aws-iam-authenticator # (default)

output path where a generated webhook kubeconfig will be stored.

generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)

role to assume before querying EC2 API in order to discover metadata like EC2 private DNS Name

ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole

AWS Account IDs to scrub from server logs. (Defaults to empty list)

scrubbedAccounts:

• "111122223333"
• "222233334444"

each mapRoles entry maps an IAM role to a username and set of groups

Each username and group can optionally contain template parameters:

1) "{{AccountID}}" is the 12 digit AWS ID.

2) "{{SessionName}}" is the role session name, with @ characters

transliterated to - characters.

3) "{{SessionNameRaw}}" is the role session name, without character

transliteration (available in version >= 0.5).

mapRoles:

statically map arn:aws:iam::000000000000:role/KubernetesAdmin to cluster admin

• rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin username: kubernetes-admin groups:
  • system:masters

map EC2 instances in my "KubernetesNode" role to users like

"aws:000000000000:instance:i-0123456789abcdef0". Only use this if you

trust that the role can only be assumed by EC2 instances. If an IAM user

can assume this role directly (with sts:AssumeRole) they can control

SessionName.

• rolearn: arn:aws:iam::000000000000:role/KubernetesNode username: aws:{{AccountID}}:instance:{{SessionName}} groups:
  • system:bootstrappers
  • aws:instances

map nodes that should conform to the username "system:node:". This

requires the authenticator to query the EC2 API in order to discover the private

DNS of the EC2 instance originating the authentication request.

{{EC2PrivateDNSName}} is resolved by using the session name as an EC2 instance

ID and calling ec2:DescribeInstances. Note that if this role is assumed directly

by an IAM User (not via federation), the user can set the session name to any

instance ID, resolving another instance's private DNS and impersonating that node.

Optionally, you may specify a role that should be assumed before querying the EC2 API with the

key "server.ec2DescribeInstancesRoleARN" (see above).

• rolearn: arn:aws:iam::000000000000:role/KubernetesNode username: system:node:{{EC2PrivateDNSName}} groups:
  • system:nodes
  • system:bootstrappers

map federated users in my "KubernetesAdmin" role to users like

"admin:alice-example.com". The SessionName is an arbitrary role name

like an e-mail address passed by the identity provider. Note that if this

role is assumed directly by an IAM User (not via federation), the user

can control the SessionName.

• rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin username: admin:{{SessionName}} groups:
  • system:masters

map federated users in my "KubernetesOtherAdmin" role to users like

"alice-example.com". The SessionName is an arbitrary role name

like an e-mail address passed by the identity provider. Note that if this

role is assumed directly by an IAM User (not via federation), the user

can control the SessionName. Note that the "{{SessionName}}" macro is

quoted to ensure it is properly parsed as a string.

• rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin username: "{{SessionName}}" groups:
  • system:masters

If unalterable identification of an IAM User is desirable, you can map against

AccessKeyID.

• rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin username: "admin:{{AccessKeyID}}" groups:
  • system:masters

each mapUsers entry maps an IAM user to a static username and set of groups

mapUsers:

map user IAM user Alice in 000000000000 to user "alice" in group "system:masters"

• userarn: arn:aws:iam::000000000000:user/Alice username: alice groups:
  • system:masters

automatically map IAM ARN from these accounts to username.

NOTE: Always use quotes to avoid the account numbers being recognized as numbers

instead of strings by the yaml parser.

mapAccounts:

• "012345678901"
• "456789012345"

source mappings from this file (mapUsers, mapRoles, & mapAccounts)

backendMode:

• MountedFile

## التطوير

انظر إلى صفحة [التطوير](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/docs/development.md).

## المجتمع، النقاش، المساهمة، والدعم

تعرّف على كيفية التفاعل مع مجتمع Kubernetes من خلال [صفحة المجتمع](http://kubernetes.io/community/).

يمكنك التواصل مع القائمين على صيانة هذا المشروع عبر:

- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [القائمة البريدية](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)

### مدونة قواعد السلوك

تخضع المشاركة في مجتمع Kubernetes لـ [مدونة قواعد سلوك Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/code-of-conduct.md).