AWS IAM Authenticator for Kubernetes

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

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

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

لماذا أرغب في هذا؟

إذا كنت مسؤولًا تدير عنقود 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:

# 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. قبل تطبيقه، حدّث هذه القيم لتناسب عنقودك:

• استبدل قيم IAM ARN النائبة (arn:aws:iam::000000000000:...) في config.yaml.
• اضبط clusterID على قيمة فريدة لعنقودك.
• تحقق من أن قواعد جدولة DaemonSet تتطابق مع تسميات/taints عقد control-plane لديك.

ثم انشره:

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. عند تشغيل 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 في ملف التكوين الخاص به. راجع تنسيق التكوين الكامل أدناه للحصول على التفاصيل.

باستخدام العلامة --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

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

CRD (ألفا)

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

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

kubectl apply -f deploy/iamidentitymapping.yaml