aws-iam-authenticator

# AWS IAM Authenticator for Kubernetes

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

## جدول المحتويات

- [لماذا أرغب في هذا؟](#why-do-i-want-this)
- [كيف أستخدمه؟](#how-do-i-use-it)
- [الاستخدام مع Kops](#kops-usage)
- [كيف يعمل؟](#how-does-it-work)
- [ما هو معرّف العنقود (cluster ID)؟](#what-is-a-cluster-id)
- [تحديد بيانات الاعتماد واستخدام ملفات تعريف AWS](#specifying-credentials--using-aws-profiles)
- [تفويض API من خارج العنقود](#api-authorization-from-outside-a-cluster)
- [استكشاف الأخطاء وإصلاحها](#troubleshooting)
- [صيغة التكوين الكاملة](#full-configuration-format)
- [التطوير](#development)
- [المجتمع والنقاش والمساهمة والدعم](#community-discussion-contribution-and-support)

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

إذا كنت تبني مثبّتًا لـ Kubernetes على AWS، فإن AWS IAM Authenticator for Kubernetes يمكنه تبسيط عملية التهيئة الأولية (bootstrap).
لن تحتاج إلى تهريب بيانات اعتماد المسؤول الأولية الخاصة بك بشكل آمن خارج العنقود المُثبَّت حديثًا.
بدلًا من ذلك، يمكنك إنشاء دور `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. تشغيل الخادم
صُمم الخادم ليعمل على كل عقدة من عقد الـ master لديك كـ DaemonSet مع شبكة المضيف (host networking) حتى يتمكن من كشف منفذ localhost.

للاطلاع على نموذج لإعداد ConfigMap وDaemonSet، انظر [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
قبل تطبيقه، حدّث هذه القيم لتناسب عنقودك:
 - استبدل قيم IAM ARN النائبة (`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 على عقدة control-plane، سيقوم `aws-iam-authenticator server` بإنشاء webhook kubeconfig على المضيف في المسار `/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml` (أو المسار المُهيأ عبر `--generate-kubeconfig`).

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

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

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

### 3. تهيئة خادم API الخاص بك للتواصل مع الخادم
يتكامل Kubernetes API مع AWS IAM Authenticator for Kubernetes باستخدام [token authentication webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication).
عند تشغيل `aws-iam-authenticator server`، سيقوم بإنشاء ملف تهيئة webhook وحفظه على نظام ملفات المضيف.
ستحتاج إلى إضافة علامة إضافية واحدة إلى تهيئة خادم API الخاص بك:
```
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
```

في العديد من العناقيد، يعمل خادم API كـ static pod.
يمكنك إضافة العَلم إلى `/etc/kubernetes/manifests/kube-apiserver.yaml`.
تأكد من أن دليل المضيف `/etc/kubernetes/aws-iam-authenticator/` مُثبَّت (mounted) داخل pod خادم API الخاص بك.
قد تحتاج أيضًا إلى إعادة تشغيل خدمة kubelet على عقدة master الخاصة بك لالتقاط تعريف static pod المُحدَّث:
```
systemctl restart kubelet.service
```

### 4. إنشاء تعيينات دور/مستخدم IAM إلى مستخدم/مجموعة kubernetes
السلوك الافتراضي للخادم هو استقاء التعيينات حصريًا من حقلي
`mapUsers` و`mapRoles` في ملف التكوين الخاص به. راجع [تنسيق التكوين
الكامل](#full-configuration-format) أدناه للحصول على التفاصيل.

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

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

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

#### `MountedFile`
هذه هي الخلفية الافتراضية للتعيينات وهي كافية لمعظم المستخدمين. راجع
[تنسيق التكوين الكامل](#full-configuration-format) أدناه للحصول على التفاصيل.

#### `CRD` (ألفا)
تمثّل هذه الخلفية كل تعيين IAM كـ `IAMIdentityMapping` وهو [مورد مخصص
في
Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
يتيح لك هذا النهج صيانة التعيينات بطريقة أصلية في Kubernetes باستخدام
kubectl أو واجهة API. بالإضافة إلى ذلك، يمكن اكتشاف أخطاء الصياغة (مثل YAML
غير المتوافق) بسهولة أكبر ولن تؤثر على جميع التعيينات.

لإعداد CRD من نوع `IAMIdentityMapping` ستحتاج أولًا إلى `apply` لبيان
CRD:

```
kubectl apply -f deploy/iamidentitymapping.yaml
```

بعد نشر CRDs، يمكنك بعد ذلك إنشاء Custom Resources التي تمثّل هويات IAM الخاصة بك. انظر
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/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 من نوع `kube-system/aws-auth` بأسلوب EKS كخلفية (backend). يُتوقع أن تكون ConfigMap بنفس التنسيق تمامًا كما في عناقيد EKS:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. هذا مفيد إذا كنت تنتقل من EKS أو إليها وتريد الاحتفاظ بتعييناتك، أو إذا كنت تشغّل EKS بالإضافة إلى عنقود AWS آخر (أو عناقيد أخرى) وتريد الحصول على نفس التعيينات في كل منها.

#### `DynamicFile`
يمكن لملف محلي يُحدَّد بواسطة cfg.dynamicfilepath أن يعمل كخلفية (backend). يُتوقع أن يكون محتوى الملف بنفس التنسيق تمامًا كما في 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](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)):
```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) ويمرره إلى apiserver.
الرمز صالح لمدة 15 دقيقة (أقصر قيمة تسمح بها AWS) ويمكن إعادة استخدامه عدة مرات.

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

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

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

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

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

#### جانب الخادم (`aws-iam-authenticator server`)
يمر الرمز عبر خادم Kubernetes API وإلى نقطة النهاية `/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) معينة.
على وجه التحديد، يمنع خادم Authenticator واحد (مثلًا في بيئة تطوير) من استخدام رمز عميل للمصادقة إلى خادم Authenticator آخر في عنقود آخر.

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

تشرح [وثائق 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 عبر متغيرات البيئة أو باستخدام ملف بيانات الاعتماد.

تُدعم [ملفات التعريف المسماة](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) في AWS بواسطة `aws-iam-authenticator`
عبر متغير البيئة `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` ستكون لها
الأولوية على ما هو مضبوط بالفعل في بيئتك.

#### ملاحظة للمستخدمين الموحَّدين (federated):
غالبًا ما يكون لدى مستخدمي AWS الموحَّدين سمة "ذات معنى" مرتبطة بدورهم المفترض، مثل عنوان بريد إلكتروني، عبر إعدادات AWS الخاصة بالحساب.
تحتوي هذه الجلسات المفترضة على [بضعة أجزاء](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable)، وهي `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 من عميل خارج العنقود، سواء باستخدام
واجهة Kubernetes REST API المجردة أو من أحد عملاء Kubernetes الخاصين بلغة معينة
(مثل [Python](https://github.com/kubernetes-client/python)). للقيام بذلك، يجب عليك إنشاء رمز حامل (bearer token)
يُضمَّن مع الطلب إلى API. يتطلب هذا الرمز الحامل أن تُلحق السلسلة `k8s-aws-v1.` بسلسلة
مشفرة بـ base64 لطلب HTTP موقَّع إلى واجهة STS GetCallerIdentity Query API. ثم يُرسَل في
ترويسة `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 الأساسية لديك في shell الخاص بك (`aws sts get-caller-identity` يمكن أن يساعد في استكشاف الأخطاء وإصلاحها).

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

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

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

 - جرّب محاكاة استدعاء `sts:AssumeRole` في [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp).

## تنسيق التكوين الكامل
يمتلك العميل والخادم نفس تنسيق التكوين.
يمكنهما مشاركة نفس ملف التكوين بالضبط، نظرًا لعدم تخزين أي أسرار في التكوين.

```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 region for EC2 DescribeInstances and token verification. If unset, the region is looked
  # up from the EC2 Instance Metadata Service (IMDS) at startup. Also settable with `--region`.
  region: us-west-2

  # 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:<private-DNS>".  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"
```

---

[Read more](https://github.com/kubernetes-sigs/aws-iam-authenticator)