يستخدم العديد من عملائنا أمازون EMR لأن منصة البيانات الضخمة الخاصة بهم بحاجة إلى التكامل مع Microsoft Active Directory (AD) الحالي لمصادقة المستخدم. يتطلب هذا التكامل برنامج Kerberos daemon الخاص بـ Amazon EMR لإنشاء اتصال موثوق به مع مجال AD ، والذي يتضمن الكثير من القطع المتحركة ويمكن أن يكون من الصعب الحصول عليه بالشكل الصحيح.

يصف هذا المنشور ما تعنيه الثقة أحادية الاتجاه مع Active Directory ، وكيف تعمل الأوامر المستخدمة في إعدادها. نصف كيف تختلف أسماء DNS ، وعوالم Kerberos ، ونطاقات AD ، وعواقب ذلك على تكوين أمان Amazon EMR وإعدادات الثقة أحادية الاتجاه العنقودية. نناقش أيضًا كيف لا يمكنك استخدام AWS مُدارة بواسطة Microsoft AD بالنسبة إلى ثقة مركز توزيع مفتاح Amazon EMR (KDC) ، ويجب إما استخدام خادم AD موجود أو جديد.

لقد أصدرت AWS بالفعل وثائق ومنشورات مدونة تغطي بعضًا من هذه المنطقة ، ويهدف هذا المنشور إلى استكمالها بدلاً من استبدالها. على هذا النحو ، نوصي بقراءة ما يلي قبل المتابعة:

هل هذه هي الهندسة المعمارية المناسبة لك؟

هناك العديد من الخيارات لمصادقة Amazon EMR باستخدام Kerberos ، وسيعتمد اختيار الأسلوب الصحيح على حالة الاستخدام الخاصة بك. لمزيد من المعلومات ، يرجى الرجوع إلى خيارات هندسة Kerberos. في هذا المنشور ، نغطي الحالة التي يكون فيها المستخدمون موجودون بالفعل في مجال AD الخاص بك ، وتريد استخدام هذه الهويات لتفويض الإجراءات في Amazon EMR. إذا لم يكن لديك بالفعل AD ، أو كنت ترغب في توسيع نطاق غير موجود في عالم Kerberos ، فسيكون أحد الخيارات الأخرى مناسبًا بشكل أفضل. لا تقم بعمل لنفسك أكثر مما يجب عليك!

الاتصال بـ Active Directory

هناك هدفان عند ربط Amazon EMR بـ AD:

• أنشئ علاقة ثقة أحادية الاتجاه من Kerberos إلى AD بحيث يمكن للمستخدمين العاملين في Amazon EMR استخدام بيانات اعتماد AD الخاصة بهم للوصول إلى الخدمات. يتطلب ذلك إمكانية الوصول إلى المنافذ 88 و 464 (لـ Kerberos) و 139 (لـ LDAP) من مجموعة EMR.
• قم بتوصيل كتلة EMR بـ AD بحيث يمكن تسجيل الخوادم المكونة لمجموعة EMR في مجال AD. يتطلب ذلك مستخدمًا تم تكوينه في مجال AD بامتيازات كافية لإجراء تلك التسجيلات — التي يطلق عليها عادةً ربط المستخدم.

أنواع الدليل النشط

تعني مجموعة المتطلبات السابقة أن خادم AD هو الوحيد الذي يمكنه تحقيق الأهداف. لا يمكنك استخدام AWS Managed Microsoft AD ولا Microsoft Azure AD. هذا يترك خيارين كأفضل ممارسة.

أولاً ، يمكنك توصيل Amazon EMR مباشرةً بخادم AD موجود (سواء محليًا أو في السحابة) ، كما هو موضح في الرسم التخطيطي التالي.

بدلاً من ذلك ، يمكنك إنشاء خادم AD جديد على الأمازون الحوسبة المرنة السحابية (Amazon EC2) ، أضفه إلى مجموعة AD الحالية للشركة ، واجعل Amazon EMR يتصل بخادم AD الجديد المستند إلى مجموعة النظراء (كما هو موضح في الرسم التخطيطي التالي).

المجالات مقابل العوالم

من الأهمية بمكان فهم المصطلحات التي تنطبق على أي تقنية لتجنب الالتباس.

Active Directory يدير المجالات، والتي تحتوي على العديد من الكيانات المسجلة مثل المستخدمين وأجهزة الكمبيوتر. عادةً ما تكون مكتوبة بأحرف صغيرة (على سبيل المثال ، corp.mycompany.com) وتبدو مشابهة جدًا لمجالات الإنترنت. لا يتعين عليهم بالضرورة حل عنوان IP ، لكنهم يفعلون ذلك عادةً.

يستخدم Kerberos العوالم لمفهوم مشابه ، ويشار إلى الكيانات المسجلة باسم مدراء. عادةً ما تتم كتابة العوالم بأحرف كبيرة ، وغالبًا ما تستخدم أسلوب تسمية يشبه مجال الإنترنت باستثناء الحالة (على سبيل المثال ، EMR.MYCOMPANY.COM). لا يحتاجون إلى حل عنوان IP وعادةً لا يفعلون ذلك.

عند تكوين المجال لعنصر Kerberos التابع لمجموعة EMR ، يكون الاسم عشوائيًا تمامًا. إنه بمثابة مساحة اسم للمبادئ المحددة بداخله ، ولكن ليس من الضروري أن يتطابق مع أسماء المجال الخاصة بالطبعات الموجودة في مجموعة EMR الخاصة بك. على سبيل المثال ، إذا كانت أسماء DNS الخاصة لأجهزة EC2 الخاصة بك تستخدم الافتراضي ec2.internal المجال ، لا يجب أن يكون اسم عالم EMR ec2.internal; يمكن ان تكون mykerberosrealm أو أي شيء تحبه.

ربط المستخدم

يجب إنشاء مستخدم ملزم في Active Directory مع الإذن بتسجيل ("ربط") أجهزة كمبيوتر EMR في مجال AD. تسجل Amazon EMR هذه أجهزة الكمبيوتر ضمن CN=Computers.

مبادئ Kerberos التي أنشأتها Amazon EMR للاستخدام مع مكونات Hadoop محلية تمامًا لتثبيت Amazon EMR Kerberos - فهي غير مسجلة في مجال AD.

DNS

يجب أن يكون برنامج EMR Kerberos الخفي قادرًا على حل اسم DNS لخادم AD الخاص بك لتأسيس الثقة بينهما. إذا تمت إدارة مجالات DNS هذه في خوادم DNS الخاصة بشركتك ، فأنت بحاجة الأمازون الطريق 53 معيد التوجيه إلى خوادم DNS الخاصة بشركتك لـ Amazon EMR لحلها. نظرًا لأن الثقة أحادية الاتجاه فقط ، لا يحتاج خادم AD إلى أن يكون قادرًا على حل أسماء DNS الداخلية لعقد مجموعة EMR.

بناء الثقة

الثقة التي تحتاج إلى تأسيسها من Amazon EMR إلى AD يجب أن تكون في اتجاه واحد فقط (تثق Amazon EMR بميزة AD) ، وليس ثنائية الاتجاه (يثق كل منهما في الآخر). لتأسيس الثقة أحادية الاتجاه ، استخدم ksetup و netdom الأدوات المساعدة في سطر الأوامر لجهاز AD. سمة نوع التشفير الموصى بها (SetEncTypeAttr) للمجال هو تشفير AES-256. تستخدم التعليمات البرمجية التالية مثال مجال EMR Kerberos EMR.MYCOMPANY.COM والمجال م corp.mycompany.com:

C:UsersAdministrator> ksetup /addkdc EMR.MYCOMPANY.COM
C:UsersAdministrator> netdom trust EMR.MYCOMPANY.COM /Domain:corp.mycompany.com /add /realm /passwordt:MyVeryStrongPassword
C:UsersAdministrator> ksetup /SetEncTypeAttr EMR.MYCOMPANY.COM AES256-CTS-HMAC-SHA1-96

في الاول ksetup الأمر ، فأنت لست بحاجة إلى توفير اسم المجال المؤهل بالكامل للكتلة KDC كوسيطة أخيرة. هذا مطلوب فقط من أجل ثقة ثنائية الاتجاه ، وهو اختياري في ثقة أحادية الاتجاه.

تكوين أمان Amazon EMR

قبل أن تبدأ مجموعة EMR ، يجب عليك إنشاء تكوين أمان يحتوي على تفاصيل خادم AD والمجال الذي تتصل به. تُظهر لقطة الشاشة التالية مثالاً على هذا التكوين.

هذه الحقول حساسة لحالة الأحرف ، لذا تأكد من إدخال كل شيء بشكل صحيح. لاحظ أن المجال والمجال في هذا التكوين يشيران إلى خادم AD وليس إلى مجموعة EMR! نظرًا لأن AD يمكن أن يعمل كخادم Kerberos بالإضافة إلى Active Directory ، فقد تم تكوين كلا الحقلين هنا. في كلتا الحالتين ، ومع ذلك ، فإنهم يشيرون إلى خادم AD وليس مجال Kerberos لمجموعة EMR.

خيارات أمان Amazon EMR عند بدء مجموعة

عند بدء تشغيل مجموعة EMR ، يمكنك تكوين خيارات الأمان كما هو موضح في لقطة الشاشة التالية.

هنا تستخدم تكوين الأمان الذي أنشأته للتو ، وتحدد تفاصيل مجال EMR Kerberos بالإضافة إلى المعلمات اللازمة لتأسيس الثقة مع مجال AD في تكوين الأمان. أنت تقدم معلومات للحقول التالية:

• المملكة - إن عالم Kerberos الذي تحدده متروك لك تمامًا ، ولكن يجب أن يكون هو نفسه الذي استخدمته عند إنشاء الثقة على جهاز AD.
• كلمة مرور مسؤول KDC - لا يتم استخدام هذا في أي مكان آخر في تكوين المجموعة ، لذا يمكنك تعيينه على شيء فريد وآمن خصيصًا لهذه المجموعة. إنها مطلوبة فقط لأية إدارة مستقبلية لمركز توزيع المفاتيح المخصص للمجموعة.
• عبر العالم الثقة كلمة السر الرئيسية - هذه هي كلمة المرور التي قمت بتعيينها باستخدام ملف netdom أمر.
• Active Directory المجال الانضمام للمستخدم –هذا هو مستخدم الربط الذي أنشأه مشرف AD.
• Active Directory المجال الانضمام كلمة المرور - هذه هي كلمة المرور الخاصة بمستخدم الربط من AD.

تنظيف

عند الانتهاء من اختبار هذا الحل ، تذكر تنظيف الموارد. إذا استخدمت قوالب CloudFormation لإنشاء الموارد ، فاستخدم وحدة تحكم AWS CloudFormation لحذف الحزمة. بدلاً من ذلك ، يمكنك استخدام ملف واجهة سطر الأوامر AWS (AWS CLI) أو SDK. للحصول على تعليمات ، راجع حذف مكدس. يؤدي حذف المكدس أيضًا إلى حذف الموارد التي تم إنشاؤها بواسطة هذا المكدس.

إذا لم يتم حذف أحد مكدساتك ، فتأكد من عدم وجود تبعيات على الموارد التي تم إنشاؤها بواسطة هذا المكدس. على سبيل المثال ، إذا قمت بنشر Amazon VPC باستخدام AWS CloudFormation ثم قمت بنشر وحدة تحكم مجال في VPC باستخدام مكدس CloudFormation مختلف ، يجب عليك أولاً حذف مكدس وحدة تحكم المجال قبل أن تتمكن من حذف مكدس VPC.

وفي الختام

ترشدك الخطوات الواردة في هذا المنشور خلال إنشاء الثقة بين خدمة Kerberos التابعة لـ Amazon EMR ومجال Active Directory. نأمل أن يكون هذا قد أدى إلى إزالة الغموض عن العملية وتسهيل إنشاء مجموعات EMR آمنة ومتكاملة مع AD في المستقبل.

حول المؤلف

أناندكومار كاليابيرومال هو مهندس بيانات أول مع Professional Services SDT ، حيث يركز على مساعدة العملاء في Hadoop وترحيل بحيرة البيانات. يعيش مع عائلته المتنامية في دالاس.

بهارات كومار بوجارابو هو مهندس بيانات في AWS Professional Services ولديه خبرة في تقنيات البيانات الضخمة. إنه متحمس لمساعدة العملاء على بناء حلول فعالة وقوية تعتمد على البيانات وإدراك إمكانات البيانات والتحليلات الخاصة بهم. مجالات اهتماماته هي الأطر مفتوحة المصدر والأتمتة وهندسة البيانات. في أوقات فراغه ، يحب قضاء الوقت مع العائلة ولعب التنس والسفر.

أوليفر مين كان مهندس بيانات أول في فريق التسليم المشترك للخدمات المهنية الكندية ، حيث ساعد العملاء في ترحيل بياناتهم ومهام سير العمل إلى AWS. يعيش في تورنتو مع أسرته والعديد من الدراجات الهوائية.