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/master/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 غير المحاذى) بسهولة أكبر ولن تؤثر على جميع التعيينات.