شعار زيفيرنت

ذكاء البيانات التوليدية

البيانات الكبيرة

تبسيط المصادقة من خلال تكامل LDAP الأصلي على Amazon EMR | خدمات الويب الأمازون

أعاد نشره أفلاطون
أعاد نشره أفلاطون

التاريخ:

المشاهدات: 83

لدى العديد من الشركات هويات مؤسسية مخزنة داخل موفري الهوية (IdPs). نشط الدليل (م) أو ب OpenLDAP. في السابق، كان العملاء يستخدمون أمازون EMR يمكنهم دمج مجموعاتهم مع Active Directory عن طريق تكوين ثقة مجال أحادية الاتجاه بين مجال AD الخاص بهم وعالم Kerberos لمجموعة EMR. لمزيد من التفاصيل، راجع البرنامج التعليمي: قم بتكوين الثقة عبر المجالات باستخدام مجال Active Directory.

لقد كان هذا الإعداد عامل تمكين رئيسيًا لإتاحة مستخدمي ومجموعات الشركات داخل مجموعات السجلات الطبية الإلكترونية وتحديد سياسات التحكم في الوصول للتحكم في الوصول إلى البيانات الخاصة بهم (على سبيل المثال، من خلال تكامل Amazon EMR الأصلي مع Apache Ranger).

على الرغم من أن هذا الخيار لا يزال متاحًا، فقد تم إصدار Amazon EMR دعم مصادقة LDAP الأصلية، وهي ميزة أمان جديدة تعمل على تبسيط التكامل مع OpenLDAP وActive Directory.

تتيح هذه الميزة ما يلي:

  • التكوين التلقائي للأمان للتطبيقات المدعومة (HiveServer2 وTrino وPresto وLivy) لاستخدام بروتوكول Kerberos تحت الغطاء وLDAP كمصادقة خارجية. يتيح ذلك تكاملًا أكثر وضوحًا من الأدوات الخارجية التي لم تعد بحاجة إلى إعداد مصادقة kerberos، للاتصال بنقاط نهاية المجموعة، ولكن بدلاً من ذلك، يمكن تهيئتها ببساطة لتوفير اسم مستخدم وكلمة مرور LDAP
  • التحكم الدقيق في الوصول (FGAC) بشأن من يمكنه الوصول إلى مجموعات EMR الخاصة بك من خلال SSH
  • سياسات الترخيص الدقيقة أعلى قاعدة بيانات وجداول Hive Metastore إذا تم استخدامها مع تكامل Amazon EMR Apache Ranger الأصلي.

في هذا المنشور، نتعمق في مصادقة Amazon EMR LDAP، ونوضح كيفية عمل تدفق المصادقة، وكيفية استرداد تكوينات LDAP المطلوبة واختبارها، وكيفية التأكد من دمج LDAP لمجموعة EMR بشكل صحيح.

باستخدام المعلومات الموجودة في هذه المدونة:

  • يمكن للفرق التي تدير مجموعات EMR تعزيز التنسيق مع مسؤولي LDAP IdP من أجل طلب المعلومات المناسبة وإجراء اختبارات ما قبل التكوين بشكل صحيح
  • يمكن للمستخدمين النهائيين لمجموعة EMR فهم مدى سهولة الاتصال من الأدوات الخارجية بمجموعات EMR التي تدعم LDAP مقارنة بالمصادقة السابقة المستندة إلى Kerberos

كيف يعمل تكامل Amazon EMR LDAP

عند الحديث عن المصادقة في سياق أطر السجلات الطبية الإلكترونية، يمكننا التمييز بين مستويين:

  • المصادقة الخارجية - يستخدم من قبل المستخدمين والمكونات الخارجية للتفاعل مع الأطر المثبتة
  • المصادقة الداخلية - يستخدم ضمن أطر توثيق اتصالات المكونات الداخلية

باستخدام هذه الميزة الجديدة، لا تزال مصادقة إطار العمل الداخلي تتم إدارتها من خلال Kerberos، ولكن هذا الأمر يتسم بالشفافية للمستخدمين النهائيين أو الخدمات الخارجية التي، على الجانب الآخر، تستخدم اسم مستخدم وكلمة مرور للمصادقة.

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

يلخص الرسم التخطيطي التالي كيفية عمل تدفق المصادقة.

يتضمن سير العمل الخطوات التالية:

  1. يتصل المستخدم بإحدى نقاط النهاية المدعومة (مثل HiveServer2 أو Trino/Presto Coordinator أو Hue WebUI) ويقدم بيانات اعتماد الشركة الخاصة به (اسم المستخدم وكلمة المرور).
  2. يستخدم إطار العمل الذي تم الاتصال به مصدقًا مخصصًا يقوم بإجراء المصادقة باستخدام خدمة EMR Secret Agent التي تعمل داخل مثيلات المجموعة.
  3. تتحقق خدمة EMR Secret Agent من صحة بيانات الاعتماد المقدمة مقابل نقطة نهاية LDAP.
  4. وفي حالة النجاح يحدث ما يلي:
    • يتم إنشاء مبدأ Kerberos لمستخدم محدد في مركز توزيع مفاتيح MIT (MIT KDC) الذي يعمل داخل العقدة الأساسية.
    • يتم إنشاء علامة التبويب الرئيسية لـ Kerberos داخل الدليل الرئيسي للمستخدم على العقدة الأساسية.

بعد اكتمال المصادقة، يمكن للمستخدم البدء في استخدام الإطار.

داخل جميع مثيلات المجموعة، يتم تكوين خدمة SSSD لاسترداد المستخدمين والمجموعات من نقطة نهاية LDAP وإتاحتهم كمستخدمين للنظام.

يختلف تدفق المصادقة عند الاتصال بـ SSH قليلاً، ويتم تلخيصه في الرسم البياني التالي.

يتضمن سير العمل الخطوات التالية:

  1. يتصل المستخدم عبر SSH بالمثيل الأساسي لـ EMR، مما يوفر بيانات اعتماد الشركة (اسم المستخدم وكلمة المرور).
  2. تستخدم خدمة SSHD التي تم الاتصال بها خدمة SSSD للتحقق من صحة بيانات الاعتماد المقدمة.
  3. تتحقق خدمة SSSD من صحة بيانات الاعتماد المقدمة مقابل نقطة نهاية LDAP. في حالة النجاح، ينتقل المستخدم إلى الدليل الرئيسي ذي الصلة. في هذه المرحلة، يمكن للمستخدم استخدام واجهات سطر الأوامر المختلفة (beeline, trino-cli, presto-cli, curl) للوصول إلى Hive أو Trino/Presto أو Livy.
  4. لاستخدام Spark CLIs (spark-submit, pyspark, spark-shell)، يجب على المستخدم استدعاء ldap-kinit البرنامج النصي وتوفير اسم المستخدم وكلمة المرور المطلوبة.
  5. يتم إجراء المصادقة باستخدام خدمة EMR Secret Agent التي تعمل داخل مثيلات المجموعة.
  6. تتحقق خدمة EMR Secret Agent من صحة بيانات الاعتماد المقدمة مقابل نقطة نهاية LDAP.
  7. وفي حالة النجاح يحدث ما يلي:
    • يتم إنشاء مبدأ Kerberos للمستخدم المحدد في مجموعة MIT KDC التي تعمل داخل العقدة الأساسية.
    • يتم إنشاء علامة التبويب الرئيسية لـ Kerberos داخل الدليل الرئيسي للمستخدم على العقدة الأساسية.
    • يتم الحصول على تذكرة kerberos وتخزينها في ذاكرة التخزين المؤقت لتذكرة Kerberos للمستخدم على العقدة الأساسية.

بعد ldap-kinit عند اكتمال البرنامج النصي، يمكن للمستخدم البدء في استخدام Spark CLIs.

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

ابحث عن معلمات LDAP المناسبة

لتكوين مصادقة LDAP لـ Amazon EMR، تتمثل الخطوة الأولى في استرداد خصائص LDAP لاستخدامها في إعداد مجموعتك. أنت بحاجة إلى المعلومات التالية:

  • اسم DNS لخادم LDAP
  • شهادة بتنسيق PEM لاستخدامها للتفاعل عبر LDAP الآمن (LDAPS) مع نقطة نهاية LDAP
  • قاعدة بحث مستخدم LDAP، وهي عبارة عن مسار (أو فرع) على شجرة LDAP حيث يتم البحث عن المستخدمين (سيتم استرجاع المستخدمين المنتمين إلى هذا الفرع فقط)
  • قاعدة بحث مجموعات LDAP وهي عبارة عن مسار (أو فرع) على شجرة LDAP من أين يتم البحث عن المجموعات (سيتم استرجاع المجموعات التابعة لهذا الفرع فقط)
  • يقوم خادم LDAP بربط بيانات اعتماد المستخدم، وهي اسم المستخدم وكلمة المرور لمستخدم الخدمة (يُسمى عادةً مستخدم الربط) ليتم استخدامها لتشغيل استعلامات LDAP واسترداد معلومات المستخدم مثل اسم المستخدم وعضوية المجموعة.

باستخدام Active Directory، يمكن لمسؤول AD استرداد هذه المعلومات مباشرة من Active Directory Users and Computers أداة. عندما تختار مستخدمًا في هذه الأداة، يمكنك رؤية السمات ذات الصلة (على سبيل المثال، distinguishedName). تظهر لقطة الشاشة التالية مثالا.

من لقطة الشاشة، يمكننا أن نرى أن distinguishedName للمستخدم جون هو CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=comمما يعني أن جون ينتمي إلى قواعد البحث التالية، مرتبة من الأضيق إلى الأوسع:

  • OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
  • OU=italy,OU=emr,DC=awsemr,DC=com
  • OU=emr,DC=awsemr,DC=com
  • DC=awsemr,DC=com

اعتمادًا على كمية الإدخالات داخل دليل LDAP الخاص بالشركة، قد يؤدي استخدام قاعدة بحث واسعة إلى فترات استرجاع طويلة ومهلات طويلة. من الممارسات الجيدة تكوين قاعدة البحث لتكون ضيقة قدر الإمكان لتشمل جميع المستخدمين المطلوبين. في المثال السابق، OU=users,OU=italy,OU=emr,DC=awsemr,DC=com قد تكون قاعدة بحث جيدة إذا كان جميع المستخدمين الذين تريد منحهم حق الوصول إلى مجموعة السجلات الطبية الإلكترونية (EMR) جزءًا من تلك الوحدة التنظيمية.

هناك طريقة أخرى لاسترداد سمات المستخدم وهي استخدام ملف ldapsearch أداة. يمكنك استخدام هذه الطريقة لـ Active Directory بالإضافة إلى OpenLDAP، ومن المفيد للغاية اختبار الاتصال بنقطة نهاية LDAP.

ما يلي هو مثال على Active Directory (OpenLDAP مشابه).

يجب أن تكون نقطة نهاية LDAP قابلة للحل ويمكن الوصول إليها عن طريق الأمازون الحوسبة المرنة السحابية (Amazon EC2) مثيلات مجموعة EMR عبر TCP على المنفذ 636. يُقترح تشغيل الاختبار من مثيل Amazon Linux 2 EC2 الذي ينتمي إلى نفس الشبكة الفرعية مثل مجموعة EMR وله نفس مجموعة أمان EMR المرتبطة بمثيلات مجموعة EMR.

بعد تشغيل مثيل EC2، قم بتثبيت nc أداة واختبار دقة DNS والاتصال. افترض أن DC1.awsemr.com هو اسم DNS لنقطة نهاية LDAP، قم بتشغيل الأوامر التالية:

sudo yum install nc
nc -vz DC1.awsemr.com 636

إذا كان تحليل DNS لا يعمل بشكل صحيح، فمن المفترض أن تتلقى رسالة خطأ مثل ما يلي:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Could not resolve hostname "DC1.awsemr.com": Name or service not known. QUITTING.

إذا لم يكن من الممكن الوصول إلى نقطة النهاية، فيجب أن تتلقى خطأً كما يلي:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connection timed out.

في أي من هاتين الحالتين، يجب مشاركة فريق الشبكات وDNS لاستكشاف المشكلات وحلها.

في حالة النجاح، يجب أن يبدو الإخراج كما يلي:

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.1.235:636.
Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds.

إذا كان كل شيء يعمل، تابع الاختبار وقم بتثبيت البرنامج openldap العملاء على النحو التالي:

sudo yum install openldap-clients

ثم اركض ldapsearch أوامر لاسترداد معلومات حول المستخدمين والمجموعات من نقطة نهاية LDAP. فيما يلي عينة ldapsearch أوامر:

#Customize these 6 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_TO_SEARCH=john
FILTER=(sAMAccountName=${USER_TO_SEARCH})
INFO_TO_SEARCH="*"

#Search user
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${SEARCH_BASE}" "${FILTER}" "${INFO_TO_SEARCH}"

نستخدم المعلمات التالية:

  • -x - وهذا يتيح المصادقة البسيطة.
  • -D - يشير هذا إلى قيام المستخدم بإجراء البحث.
  • -w – يشير هذا إلى كلمة مرور المستخدم.
  • -H - يشير هذا إلى عنوان URL لخادم LDAP.
  • -b – هذا هو البحث الأساسي.
  • LDAPTLS_CACERT - يشير هذا إلى الشهادة العامة لنقطة نهاية LDAPS SSL PEM أو الشهادة العامة SSL PEM لسلطة شهادات جذر نقطة نهاية LDAPS. يمكن الحصول على هذا من مستخدم مسؤول AD أو OpenLDAP.

فيما يلي نموذج لإخراج الأمر السابق:

filter: (sAMAccountName=john)
requesting: *
dn: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: john
givenName: john
distinguishedName: CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
instanceType: 4
whenCreated: 20230804094021.0Z
whenChanged: 20230804094021.0Z
displayName: john
uSNCreated: 262459
memberOf: CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
uSNChanged: 262466
name: john
objectGUID:: gTxn8qYvy0SVL+mYAAbb8Q==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 133356156212864439
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAIKyNe7Dn3azp7Sh+rgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: john
sAMAccountType: 805306368
userPrincipalName: john@awsemr.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=awsemr,DC=com
dSCorePropagationData: 20230804094021.0Z
dSCorePropagationData: 16010101000000.0Z

كما يمكننا أن نرى من إخراج العينة، المستخدم جون يتم التعرف عليه بالاسم المميز CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com، و data-engineers المجموعة التي ينتمي إليها المستخدم (memberOf القيمة) يتم تعريفها بالاسم المميز CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

يمكننا تشغيل لدينا ldapsearch استعلامات لاسترداد معلومات المستخدم والمجموعة باستخدام قاعدة بحث ضيقة:

#Customize these 9 variables
LDAPS_CERTIFICATE=/path/to/ldaps_cert.pem
LDAPS_ENDPOINT=DC1.awsemr.com
BINDUSER="CN=binduser,CN=Users,DC=awsemr,DC=com"
BINDUSER_PASSWORD=binduserpassword
SEARCH_BASE=DC=awsemr,DC=com
USER_SEARCH_BASE=OU=users,OU=italy,OU=emr,DC=awsemr,DC=com
GROUPS_SEARCH_BASE=OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com
USER_TO_SEARCH=john
GROUP_TO_SEARCH=data-engineers

#Search User
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${USER_SEARCH_BASE}" "(sAMAccountName=${USER_TO_SEARCH})" "*"

#Search Group
LDAPTLS_CACERT=${LDAPS_CERTIFICATE} ldapsearch -LLL -x -H ldaps://${LDAPS_ENDPOINT} -v -D "${BINDUSER}" -w "${BINDUSER_PASSWORD}" -b "${GROUPS_SEARCH_BASE}" "(sAMAccountName=${GROUP_TO_SEARCH})" "*"

يمكنك أيضًا تطبيق مرشحات أخرى أثناء البحث. لمزيد من المعلومات حول كيفية إنشاء عوامل تصفية LDAP، راجع مرشحات LDAP.

عن طريق الركض ldapsearch الأوامر، يمكنك اختبار اتصال LDAP وخصائص LDAP، وتحديد الإعداد المطلوب.

اختبر المحلول

بعد التحقق من أن الاتصال بنقطة نهاية LDAP مفتوح وأن تكوينات LDAP صحيحة، تابع إعداد البيئة لتشغيل مجموعة EMR LDAP الممكنة.

قم بإنشاء أسرار AWS Secret Manager

قبل إنشاء تكوين أمان EMR، يتعين عليك إنشاء اثنين مدير AWS السري أسرار. يمكنك استخدام بيانات الاعتماد هذه للتفاعل مع نقطة نهاية LDAP واسترداد تفاصيل المستخدم مثل اسم المستخدم وعضوية المجموعة.

  1. في وحدة تحكم مدير الأسرار ، اختر أسرار في جزء التنقل.
  2. اختار قم بتخزين سر جديد.
  3. في حالة النوع السري، حدد نوع آخر من السر.
  4. قم بإنشاء سر جديد يحدد binduser الاسم المميز كالمفتاح و binduser كلمة المرور كقيمة.
  5. أنشئ سرًا ثانيًا يحدد بنص عادي شهادة SSL العامة لنقطة نهاية LDAPS أو الشهادة العامة لمرجع شهادة جذر LDAPS.
    هذه الشهادة موثوقة، مما يسمح بالاتصال الآمن بين مجموعة EMR ونقطة نهاية LDAPS.

قم بإنشاء تكوين أمان EMR

أكمل الخطوات التالية لإنشاء تكوين أمان السجلات الطبية الإلكترونية:

  1. في وحدة تحكم Amazon EMR ، اختر تكوينات الأمان مع EMR على EC2 في جزء التنقل.
  2. اختار إنشاء.
  3. في حالة اسم تكوين الأمان، إدخال اسم.
  4. في حالة خيارات إعداد تكوين الأمان، حدد اختر الإعدادات المخصصة.
  5. في حالة التشفير، حدد قم بتشغيل التشفير أثناء النقل.
  6. في حالة نوع موفر الشهادةتحديد بيم.
  7. في حالة اختر موقع شهادة PEM، أدخل إما حزمة PEM الموجودة في خدمة تخزين أمازون البسيطة (Amazon S3) أو موفر شهادات Java المخصصة.
    لاحظ أن التشفير أثناء النقل إلزامي لاستخدام ميزة مصادقة LDAP. لمزيد من المعلومات حول التشفير أثناء النقل، راجع توفير شهادات لتشفير البيانات أثناء النقل باستخدام تشفير Amazon EMR.
  8. اختار التالى.
  9. أختار LDAP For بروتوكول المصادقة.
  10. في حالة موقع خادم LDAP، أدخل نقطة نهاية LDAPS (ldaps://<ldap_endpoint_DNS_name>).
  11. في حالة شهادة LDAP SSL، أدخل السر الثاني الذي قمت بإنشائه في Secrets Manager.
  12. في حالة مرشح وصول LDAP، أدخل عامل تصفية LDAP الذي تم تطبيقه لتقييد الوصول إلى مجموعة فرعية من المستخدمين الذين تم استردادهم من قاعدة بحث مستخدمي LDAP. إذا تم ترك الحقل فارغًا، فلن يتم تطبيق أي عوامل تصفية ويمكن لجميع المستخدمين الذين ينتمون إلى قاعدة بحث مستخدم LDAP الوصول إلى نقاط النهاية المحمية بواسطة EMR LDAP باستخدام بيانات اعتماد الشركة الخاصة بهم. فيما يلي أمثلة على المرشحات ووظائفها:
    • (فئة الكائن = شخص) – تصفية المستخدمين بالسمة objectClass جلس مثل person
    • (عضو = CN = المشرفين، OU = المجموعات، OU = إيطاليا، OU = emr، DC = awsemr، DC = com) – تصفية المستخدمين الذين ينتمون إلى admins رأس التجميع
    • (|( memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)( memberof=CN=admins,OU=groups,OU=italy,OU=emr, DC = أوسمر، DC = كوم)) – تصفية المستخدمين الذين ينتمون إما إلى data-engineers أو ال admins المجموعة (التي نستخدمها لهذا المنشور)
  13. أدخل قيمًا لـ قاعدة بحث مستخدم LDAP و قاعدة بحث مجموعة LDAP. لاحظ أن قاعدتي البحث لا تدعمان عوامل التصفية المضمنة (على سبيل المثال، ما يلي غير مدعوم: OU=users,OU=italy,OU=emr,DC=awsemr,DC=com?subtree?(|(memberof=CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com)(memberof=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com))).
  14. أختار قم بتشغيل تسجيل الدخول SSH. يعد هذا مطلوبًا فقط إذا كنت تريد أن يتمكن مستخدمو LDAP من استخدام SSH داخل مثيلات المجموعة باستخدام بيانات اعتماد الشركة الخاصة بهم. إذا تم تمكين تسجيل الدخول إلى SSH، فستكون هناك حاجة إلى مرشح وصول LDAP، وإلا ستفشل مصادقة SSH.
  15. في حالة ربط خادم LDAP بيانات الاعتماد، أدخل السر الأول الذي قمت بإنشائه في Secrets Manager.
  16. في مجلة ترخيص القسم، احتفظ بالإعدادات الافتراضية المحددة:
    • في حالة دور IAM للتطبيقات، حدد ملف تعريف المثيل.
    • في حالة طريقة التحكم في الوصول الدقيقة، حدد بدون اضاءة.
  17. اختار التالى.
  18. قم بمراجعة ملخص التكوين ثم اختر إنشاء.

قم بتشغيل مجموعة السجلات الطبية الإلكترونية

يمكنك تشغيل مجموعة EMR باستخدام وحدة تحكم إدارة AWSأطلقت حملة واجهة سطر الأوامر AWS (AWS CLI)، أو أي أوس SDK.

عندما تقوم بإنشاء EMR على مجموعة EC2، تأكد من تحديد التكوينات التالية:

  • إصدار EMR – استخدم Amazon EMR 6.12.0 أو أعلى.
  • التطبيقات - حدد Hadoop وSpark وHive وHue وLivy وPresto/Trino.
  • تكوين الأمان – حدد تكوين الأمان الذي قمت بإنشائه في الخطوة السابقة.
  • زوج المفاتيح EC2 - استخدم زوج المفاتيح الموجود.
  • مجموعات الشبكة والأمن - استخدم تكوينًا يسمح لمثيلات EMR EC2 بالتفاعل مع نقطة نهاية LDAPS. في ال ابحث عن معلمات LDAP المناسبة القسم، يجب أن تكون قد قمت بتأكيد إعداد صالح.

تأكد من أن مصادقة LDAP تعمل

عندما يتم تشغيل المجموعة، يمكنك التحقق من أن مصادقة LDAP تعمل بشكل صحيح.

If تسجيل الدخول SSH تم تمكينه كجزء من مصادقة LDAP داخل تكوين أمان EMR، يمكنك SSH في مجموعتك عن طريق تحديد مستخدم LDAP، والمطالبة بكلمة المرور ذات الصلة عند الطلب:

ssh myldapuser@<emr_primary_node>

إذا تم تعطيل تسجيل الدخول إلى SSH، فيمكنك SSH داخل المجموعة باستخدام زوج مفاتيح EC2 المحدد أثناء إنشاء المجموعة:

ssh -i mykeypair.pem ec2-user@<emr_primary_node>

هناك طريقة بديلة للوصول إلى المثيل الأساسي، إذا كنت تفضل ذلك، وهي استخدام مدير الدورة، قدرة مدير أنظمة AWS. لمزيد من المعلومات ، يرجى الرجوع إلى اتصل بمثيل Linux الخاص بك باستخدام AWS Systems Manager Session Manager.

عندما تكون داخل المثيل الأساسي، يمكنك اختبار ما إذا كان يتم استرداد مستخدمي ومجموعات LDAP بشكل صحيح باستخدام id يأمر. فيما يلي نموذج أمر للتحقق مما إذا كان المستخدم john يتم استرجاعها بشكل صحيح مع المجموعات ذات الصلة:

[ec2-user@ip-10-0-2-237 ~]# id john
uid=941601122(john) gid=941600513(users-group) groups=941600513(users-group),941601123(data-engineers)

يمكنك بعد ذلك اختبار المصادقة على الأطر المثبتة المختلفة.

أولاً، لنسترجع الشهادة العامة لإطارات العمل ونخزنها داخل مخزن موثوق به. تشترك جميع الإطارات في نفس الشهادة العامة (التي استخدمناها لإعداد التشفير أثناء النقل)، لذا يمكنك استخدام أي من نقاط النهاية المحمية بواسطة SSL (منفذ Hive 10000، منفذ Presto/Trino 8446، منفذ Livy 8998) لاستردادها . احصل على الشهادة من نقطة نهاية HiveServer2 (المنفذ 10000):

#Export Hive Server 2 public SSL certificate to a PEM file
openssl s_client -showcerts -connect $(hostname -f):10000 </dev/null 2>/dev/null|openssl x509 -outform PEM > certificate.pem

#Import the PEM certificate inside a truststore
echo "yes" | keytool -import -alias hive_cert -file certificate.pem -storetype JKS -keystore truststore.jks -storepass myStrongPassword

ثم استخدم مخزن الثقة هذا للتواصل بشكل آمن مع أطر العمل المختلفة.

استخدم الكود التالي لاختبار مصادقة HiveServer2 باستخدام beeline:

#Use the truststore to connect to the Hive Server 2
beeline -u "jdbc:hive2://$(hostname -f):10000/default;ssl=true;sslTrustStore=truststore.jks;trustStorePassword=myStrongPassword" -n john -p johnPassword

إذا كنت تستخدم Presto، فاختبر مصادقة Presto باستخدام presto CLI (توفير كلمة مرور المستخدم عند الطلب):

#Use the truststore to connect to the Presto coordinator
presto-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

إذا كنت تستخدم Trino، فاختبر مصادقة Trino باستخدام ملف trino CLI (توفير كلمة مرور المستخدم عند الطلب):

#Use the truststore to connect to the Trino coordinator
trino-cli 
--user john 
--password 
--catalog hive 
--server https://$(hostname -f):8446 
--truststore-path truststore.jks 
--truststore-password myStrongPassword

اختبار Livy المصادقة مع الضفيرة:

#Trust the PEM certificte to connect to the Livy server

#Start session
curl --cacert certificate.pem -X POST 
-u "john:johnPassword" 
--data '{"kind": "spark"}' 
-H "Content-Type: application/json" 
https://$(hostname -f):8998/sessions 
-c cookies.txt

#Example of output
#{"id":0,"name":null,"appId":null,"owner":"john","proxyUser":"john","state":"starting","kind":"spark","appInfo":{"driverLogUrl":null,"sparkUiUrl":null},"log":["stdout: ","nstderr: ","nYARN Diagnostics: "]}

اختبار أوامر سبارك مع pyspark:

#SSH inside the primary instance with the specific user
ssh john@<emr-primary-node>
#Or impersonate the user
sudo su - john

#Create a keytab and obtain a kerberos ticket running the ldap-kinit tool
$ ldap-kinit
Username: john
Password: 

#Output
{"message":"ok","contents":{"username":"john","expirationTime":"2023-09-14T15:24:06.303Z[UTC]"}}

#Check the kerberos ticket has been created
$ klist

# Test spark CLIs
$ pyspark

>>> spark.sql("show databases").show()
>>> quit()

لاحظ أننا قمنا هنا باختبار المصادقة من داخل المجموعة، ولكن يمكننا التفاعل مع Trino وHive وPresto وLivy حتى من خارج المجموعة بقدر ما يتم تكوين الاتصال ودقة DNS بشكل صحيح. تعد Spark CLIs هي الوحيدة التي يمكن استخدامها فقط من داخل المجموعة.

لاختبار مصادقة Hue، أكمل الخطوات التالية:

  1. انتقل إلى واجهة مستخدم الويب Hue المستضافة على http://<emr_primary_node>:8888/ وقم بتوفير اسم مستخدم وكلمة مرور LDAP.
  2. اختبار استعلامات SQL داخل محرري Hive وTrino/Presto.

للاختبار باستخدام أداة SQL خارجية (مثل DBeaver الاتصال بـ Trino)، أكمل الخطوات التالية. تأكد من تكوين مجموعة أمان العقدة الأساسية EMR بحيث تسمح بحركة مرور TCP من DBeaver IP إلى منفذ نقطة نهاية إطار العمل المطلوب (على سبيل المثال، 10000 لـ HiveServer2، 8446 لـ Trino/Presto) ولتكوين دقة DNS بشكل صحيح على عميل DBeaver الجهاز لحل اسم مضيف عقدة EMR الأساسية بشكل صحيح.

  1. من المثيل الأساسي لمجموعة EMR، انسخ الملفات إلى حاوية S3 truststore.jks (تم إنشاؤه مسبقًا) و /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (تغيير الإصدار XXX اعتمادًا على إصدار EMR).
  2. قم بتنزيل ملف truststore.jks و trino-jdbc-XXX-amzn-0.jar الملفات.
  3. افتح DBeaver واختر قاعدة البيانات، ثم اختر مدير سائق.
  4. اختار جديد لإنشاء برنامج تشغيل جديد.
  5. على الإعدادات علامة التبويب، قم بتوفير المعلومات التالية:
    • في حالة اسم سائق، أدخل EMR Trino.
    • في حالة اسم الفصل، أدخل io.trino.jdbc.TrinoDriver.
    • في حالة قالب عنوان URL، أدخل jdbc:trino://{host}:{port}.
  6. على المكتبات علامة التبويب، أكمل الخطوات التالية:
    • اختار إضافة ملف.
    • اختر ملف JAR لبرنامج تشغيل Trino JDBC من نظام الملفات المحلي (trino-jdbc-XXX-amzn-0.jar).
  7. اختار OK لإنشاء برنامج التشغيل.
  8. اختار قاعدة البيانات و اتصال قاعدة بيانات جديد.
  9. على الرئيسية علامة التبويب، حدد ما يلي:
    • في حالة الاتصال عن طريق، حدد مضيف.
    • في حالة مضيف، أدخل عقدة EMR الأساسية.
    • في حالة ميناء، أدخل منفذ Trino (8446 افتراضيًا).
  10. على خصائص السائق علامة التبويب، أضف الخصائص التالية:
    • أضف SSL مع True كقيمة.
    • أضف SSLTrustStorePath مع الالجائزة truststore.jks موقع الملف كقيمة.
    • أضف SSLTrustStorePassword مع الالجائزة truststore.jks كلمة المرور التي استخدمتها لإنشائها كقيمة.
  11. اختار نهاية.
  12. اختر الاتصال الذي تم إنشاؤه واختر التواصل الرمز.
  13. أدخل اسم المستخدم وكلمة المرور الخاصين بـ LDAP، ثم اختر OK.

إذا كان كل شيء يعمل، فيجب أن تكون قادرًا على تصفح كتالوجات Trino وقواعد البيانات والجداول في جزء التنقل. لتشغيل الاستعلامات، اختر محرر SQL، ثم اختر افتح محرر SQL.

من محرر SQL، يمكنك الاستعلام عن الجداول الخاصة بك.

الخطوات التالية

تعمل ميزة مصادقة Amazon EMR LDAP الجديدة على تبسيط الطريقة التي يمكن للمستخدمين من خلالها الوصول إلى أطر عمل EMR المثبتة. عندما يستخدم المستخدمون إطار عمل، قد ترغب في التحكم في البيانات التي يمكنهم الوصول إليها. بالنسبة لهذا الموضوع المحدد، يمكنك استخدام مصادقة LDAP مع تكامل EMR Apache Ranger الأصلي. لمزيد من المعلومات، راجع دمج Amazon EMR مع Apache Ranger.

تنظيف

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

  1. إذا قمت بتشغيل مثيل EC2 للتحقق من اتصال LDAP ولم تعد بحاجة إليه، فاحذفه باستخدام الأمر التالي (حدد معرف المثيل الخاص بك): 
    aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>

  2. إذا قمت بتشغيل مثيل EC2 لاختبار DBeaver ولم تعد بحاجة إليه، فيمكنك استخدام الأمر السابق لحذفه.
  3. احذف مجموعة EMR باستخدام الأمر التالي (حدد معرف مجموعة EMR الخاص بك): 
    aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>

    لاحظ أنه إذا كانت مجموعة EMR بها حماية الإنهاء تمكين، قبل تشغيل السابق terminate-clusters الأمر، يجب عليك تعطيله. يمكنك القيام بذلك باستخدام الأمر التالي (حدد معرف مجموعة EMR الخاص بك):

    aws emr modify-cluster-attributes 
--cluster-ids j-XXXXXXXXXXXXX 
--no-termination-protected 
--region eu-west-1

  4. احذف تكوين أمان EMR باستخدام الأمر التالي: 
    aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

  5. احذف أسرار Secrets Manager بالأوامر التالية: 
    aws secretsmanager delete-secret 
--secret-id <first-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

aws secretsmanager delete-secret 
--secret-id <second-secret-name> 
--force-delete-without-recovery 
--region <your-aws-region>

وفي الختام

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

حول المؤلف

ستيفانو ساندونا هو أحد كبار مهندسي حلول البيانات الضخمة في AWS. يحب البيانات والأنظمة الموزعة والأمن. إنه يساعد العملاء في جميع أنحاء العالم على تصميم منصات بيانات ضخمة آمنة وقابلة للتطوير وموثوقة.

عدنان الهماني هو مهندس تطوير برمجيات في AWS ويعمل مع فريق EMR. وهو يركز على الوضع الأمني ​​للتطبيقات التي تعمل على مجموعات السجلات الطبية الإلكترونية. وهو مهتم بتطبيقات البيانات الضخمة الحديثة وكيفية تفاعل العملاء معها.

بقعة_صورة

أحدث المعلومات الاستخباراتية

بقعة_صورة

حقوق النشر @ 2024 Plato Technologies Inc.