Zephyrnet Logosu

Üretken Veri Zekası

büyük Veri

Amazon EMR'de yerel LDAP entegrasyonuyla kimlik doğrulamayı basitleştirin | Amazon Web Hizmetleri

Plato tarafından yeniden yayınlandı
Plato tarafından yeniden yayınlandı

Tarih:

Görüntüleme: 83

Birçok şirketin kimlik sağlayıcılarının (IdP'ler) içinde saklanan kurumsal kimlikleri vardır: Active Directory (Reklam) veya OpenLDAP. Daha önce müşterilerin kullandığı Amazon EMR'si AD etki alanları ile EMR kümesi Kerberos bölgesi arasında tek yönlü bir bölge güveni yapılandırarak kümelerini Active Directory ile entegre edebilirler. Daha fazla ayrıntı için bkz. Öğretici: Active Directory etki alanıyla alanlar arası güveni yapılandırma.

Bu kurulum, kurumsal kullanıcıların ve grupların EMR kümeleri içinde kullanılabilir hale getirilmesinde ve veri erişimlerini kontrol etmek için erişim kontrolü politikalarının tanımlanmasında (örneğin, Amazon EMR yerel Apache Ranger entegrasyonu).

Bu seçenek hâlâ mevcut olmasına rağmen Amazon EMR kullanıma sunuldu yerel LDAP kimlik doğrulaması desteğiOpenLDAP ve Active Directory ile entegrasyonu kolaylaştıran yeni bir güvenlik özelliği.

Bu özellik aşağıdakileri sağlar:

  • Desteklenen uygulamalara (HiveServer2, Trino, Presto ve Livy) yönelik otomatik güvenlik yapılandırması, Kerberos protokolünü ve harici kimlik doğrulama olarak LDAP'yi kullanır. Bu, küme uç noktalarına bağlanmak için artık kerberos kimlik doğrulamasını ayarlaması gerekmeyen, bunun yerine yalnızca bir LDAP kullanıcı adı ve parolası sağlayacak şekilde yapılandırılabilen harici araçlardan daha basit bir entegrasyona olanak tanır.
  • EMR kümelerinize SSH aracılığıyla kimlerin erişebileceğine ilişkin ayrıntılı erişim kontrolü (FGAC)
  • Yerel Amazon EMR Apache Ranger entegrasyonuyla birlikte kullanıldığında Hive Metastore veritabanı ve tablolarının üzerinde ayrıntılı yetkilendirme politikaları bulunur.

Bu yazıda, Amazon EMR LDAP kimlik doğrulamasının derinliklerine inerek kimlik doğrulama akışının nasıl çalıştığını, gerekli LDAP yapılandırmalarının nasıl alınacağını ve test edileceğini ve bir EMR kümesinin LDAP'nin düzgün şekilde entegre edildiğinin nasıl doğrulanacağını göstereceğiz.

Bu blogdaki bilgileri kullanma:

  • EMR kümelerini yöneten ekipler, doğru bilgileri istemek ve ön yapılandırma testlerini doğru şekilde gerçekleştirmek için LDAP IdP yöneticileriyle koordinasyonu geliştirebilir
  • EMR kümesi son kullanıcıları, önceki Kerberos tabanlı kimlik doğrulamayla karşılaştırıldığında harici araçlardan LDAP etkin EMR kümelerine bağlanmanın ne kadar kolay olduğunu anlayabilir

Amazon EMR LDAP entegrasyonu nasıl çalışır?

EMR çerçeveleri bağlamında kimlik doğrulamadan bahsederken iki seviyeyi ayırt edebiliriz:

  • Harici kimlik doğrulama – Kullanıcılar ve harici bileşenler tarafından kurulu çerçevelerle etkileşimde bulunmak için kullanılır
  • Dahili kimlik doğrulama – Dahili bileşenlerin iletişimlerini doğrulamak için çerçeveler içerisinde kullanılır

Bu yeni özellik sayesinde dahili çerçeve kimlik doğrulaması hala Kerberos üzerinden yönetiliyor ancak bu, diğer tarafta kimlik doğrulama için kullanıcı adı ve parola kullanan son kullanıcılar veya harici hizmetler için şeffaf.

Desteklenen EMR yüklü çerçeveler, bir dizi kullanıcı adı ve parola kimlik bilgileri verildiğinde bunları LDAP uç noktasına göre doğrulayan ve başarılı olması durumunda çerçevenin kullanımına olanak tanıyan LDAP tabanlı bir kimlik doğrulama yöntemi uygular.

Aşağıdaki şema kimlik doğrulama akışının nasıl çalıştığını özetlemektedir.

İş akışı aşağıdaki adımları içerir:

  1. Kullanıcı desteklenen uç noktalardan birine (HiveServer2, Trino/Presto Coordinator veya Hue WebUI gibi) bağlanır ve kurumsal kimlik bilgilerini (kullanıcı adı ve parola) sağlar.
  2. Bağlantı kurulan çerçeve, küme örnekleri içinde çalışan EMR Gizli Aracı hizmetini kullanarak kimlik doğrulamayı gerçekleştiren özel bir kimlik doğrulayıcı kullanır.
  3. EMR Gizli Aracısı hizmeti, sağlanan kimlik bilgilerini LDAP uç noktasına göre doğrular.
  4. Başarı durumunda aşağıdakiler meydana gelir:
    • Birincil düğüm içinde çalışan küme MIT anahtar dağıtım merkezinde (MIT KDC) belirli kullanıcı için bir Kerberos sorumlusu oluşturulur.
    • Kerberos ana tuş sekmesi, birincil düğümdeki kullanıcının ana dizininde oluşturulur.

Kimlik doğrulama tamamlandıktan sonra kullanıcı çerçeveyi kullanmaya başlayabilir.

Tüm küme örneklerinin içinde SSSD hizmeti, kullanıcıları ve grupları LDAP uç noktasından alacak ve bunları sistem kullanıcıları olarak kullanılabilir hale getirecek şekilde yapılandırılmıştır.

SSH ile bağlanırken kimlik doğrulama akışı biraz farklıdır ve aşağıdaki şemada özetlenmiştir.

İş akışı aşağıdaki adımları içerir:

  1. Bir kullanıcı, kurumsal kimlik bilgilerini (kullanıcı adı ve parola) sağlayarak SSH ile EMR birincil örneğine bağlanır.
  2. Bağlantı kurulan SSHD hizmeti, sağlanan kimlik bilgilerini doğrulamak için SSSD hizmetini kullanır.
  3. SSSD hizmeti, sağlanan kimlik bilgilerini LDAP uç noktasına göre doğrular. Başarı durumunda kullanıcı ilgili ana dizine ulaşır. Bu noktada kullanıcı farklı CLI'leri kullanabilir (beeline, trino-cli, presto-cli, curl) Hive, Trino/Presto veya Livy'ye erişmek için.
  4. Spark CLI'leri kullanmak için (spark-submit, pyspark, spark-shell), kullanıcının çağırması gerekir ldap-kinit komut dosyasını oluşturun ve istenen kullanıcı adını ve şifreyi sağlayın.
  5. Kimlik doğrulama, küme örnekleri içinde çalışan EMR Gizli Aracı hizmeti kullanılarak gerçekleştirilir.
  6. EMR Gizli Aracısı hizmeti, sağlanan kimlik bilgilerini LDAP uç noktasına göre doğrular.
  7. Başarı durumunda aşağıdakiler meydana gelir:
    • Birincil düğüm içinde çalışan MIT KDC kümesindeki belirli kullanıcı için bir Kerberos sorumlusu oluşturulur.
    • Kerberos ana tuş sekmesi, birincil düğümdeki kullanıcının ana dizininde oluşturulur.
    • Bir kerberos bileti alınır ve birincil düğümdeki kullanıcının Kerberos bileti önbelleğinde saklanır.

Sonra ldap-kinit komut dosyası tamamlandığında kullanıcı Spark CLI'leri kullanmaya başlayabilir.

Aşağıdaki bölümlerde gerekli LDAP ayar değerlerinin nasıl alınacağını gösteriyor ve EMR LDAP kimlik doğrulaması ile bir kümenin nasıl başlatılıp test edileceğini araştırıyoruz.

Uygun LDAP parametrelerini bulun

Amazon EMR için LDAP kimlik doğrulamasını yapılandırmanın ilk adımı, kümenizi ayarlamak için kullanılacak LDAP özelliklerini almaktır. Aşağıdaki bilgilere ihtiyacınız var:

  • LDAP sunucusu DNS adı
  • LDAP uç noktasıyla Güvenli LDAP (LDAPS) üzerinden etkileşimde bulunmak için kullanılacak PEM biçiminde bir sertifika
  • LDAP ağacında kullanıcıların aranacağı bir yol (veya dal) olan LDAP kullanıcı arama tabanı (yalnızca bu dala ait olan kullanıcılar alınacaktır)
  • LDAP ağacı üzerinde grupların aranacağı bir yol (veya dal) olan LDAP grupları arama tabanı (yalnızca bu dala ait olan gruplar alınacaktır)
  • LDAP sunucusu, LDAP sorgularını tetiklemek ve kullanıcı adı ve grup üyeliği gibi kullanıcı bilgilerini almak için kullanılacak bir hizmet kullanıcısının (genellikle bağlama kullanıcısı olarak adlandırılır) kullanıcı adı ve parolası olan kullanıcı kimlik bilgilerini bağlar.

Active Directory ile bir AD yöneticisi bu bilgiyi doğrudan Active Directory Users and Computers alet. Bu araçta bir kullanıcıyı seçtiğinizde ilgili nitelikleri görebilirsiniz (örneğin, distinguishedName). Aşağıdaki ekran görüntüsü bir örneği göstermektedir.

Ekran görüntüsünden şunu görebiliriz: distinguishedName kullanıcı için john CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=comBu, John'un en dardan en genişe doğru sıralanmış aşağıdaki arama tabanlarına ait olduğu anlamına gelir:

  • 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

Bir şirketin LDAP dizinindeki girişlerin miktarına bağlı olarak geniş bir arama tabanı kullanmak, uzun erişim sürelerine ve zaman aşımlarına yol açabilir. Gerekli tüm kullanıcıları dahil etmek için arama tabanını mümkün olduğunca dar olacak şekilde yapılandırmak iyi bir uygulamadır. Önceki örnekte, OU=users,OU=italy,OU=emr,DC=awsemr,DC=com EMR kümesine erişim sağlamak istediğiniz tüm kullanıcılar söz konusu Kuruluş Biriminin parçasıysa iyi bir arama tabanı olabilir.

Kullanıcı özniteliklerini almanın başka bir yolu da ldapsearch alet. Bu yöntemi Active Directory'nin yanı sıra OpenLDAP için de kullanabilirsiniz ve LDAP uç noktasıyla bağlantıyı test etmek son derece faydalıdır.

Aşağıda Active Directory ile bir örnek verilmiştir (OpenLDAP benzerdir).

LDAP uç noktası çözülebilir ve erişilebilir olmalıdır. Amazon Elastik Bilgi İşlem Bulutu (Amazon EC2) EMR kümesi örnekleri, 636 numaralı bağlantı noktasında TCP aracılığıyla. Testin, EMR kümesiyle aynı alt ağa ait olan ve EMR kümesi örnekleriyle ilişkilendirilmiş aynı EMR güvenlik grubuna sahip bir Amazon Linux 2 EC2 örneğinden çalıştırılması önerilir.

Bir EC2 bulut sunucusunu başlattıktan sonra nc aracı kullanın ve DNS çözümlemesini ve bağlantısını test edin. Bunu varsayarak DC1.awsemr.com LDAP uç noktasının DNS adıdır; aşağıdaki komutları çalıştırın:

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

DNS çözümlemesi düzgün çalışmıyorsa aşağıdakine benzer bir hata almanız gerekir:

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

Uç noktaya ulaşılamıyorsa aşağıdakine benzer bir hata almanız gerekir:

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

Her iki durumda da, sorunların giderilmesi ve çözülmesi için ağ ve DNS ekibinin sürece dahil olması gerekir.

Başarılı olması durumunda çıktı aşağıdaki gibi görünmelidir:

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.

Her şey işe yararsa teste devam edin ve openldap müşteriler aşağıdaki gibidir:

sudo yum install openldap-clients

O zaman koş ldapsearch LDAP uç noktasından kullanıcılar ve gruplar hakkında bilgi almaya yönelik komutlar. Aşağıdakiler örnektir ldapsearch komutları:

#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}"

Aşağıdaki parametreleri kullanıyoruz:

  • -x – Bu, basit kimlik doğrulamayı mümkün kılar.
  • -D – Bu, kullanıcının aramayı gerçekleştireceğini belirtir.
  • -w – Bu, kullanıcı şifresini gösterir.
  • -H – Bu, LDAP sunucusunun URL'sini gösterir.
  • -b – Bu temel aramadır.
  • LDAPTLS_CACERT – Bu, LDAPS uç noktası SSL PEM genel sertifikasını veya LDAPS uç noktası kök sertifika yetkilisi SSL PEM genel sertifikasını belirtir. Bu, bir AD veya OpenLDAP yönetici kullanıcısından edinilebilir.

Aşağıda önceki komutun örnek çıktısı verilmiştir:

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

Örnek çıktıdan da görebileceğimiz gibi, kullanıcı tuvalet seçkin isimle tanımlanır CN=john,OU=users,OU=italy,OU=emr,DC=awsemr,DC=com, Ve data-engineers kullanıcının ait olduğu grup (memberOf değer) ayırt edici adla tanımlanır CN=data-engineers,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com.

Çalıştırabiliriz ldapsearch daraltılmış bir arama tabanı kullanarak kullanıcı ve grup bilgilerini almak için sorgular:

#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})" "*"

Arama yaparken başka filtreler de uygulayabilirsiniz. LDAP filtrelerinin nasıl oluşturulacağı hakkında daha fazla bilgi için bkz. LDAP Filtreleri.

Koşarak ldapsearch komutlarını kullanarak LDAP bağlantısını ve LDAP özelliklerini test edebilir ve gerekli kurulumu belirleyebilirsiniz.

Çözümü test edin

LDAP uç noktasına bağlantının açık olduğunu ve LDAP yapılandırmalarının doğru olduğunu doğruladıktan sonra, EMR LDAP özellikli bir kümeyi başlatmak için ortamı ayarlamaya devam edin.

AWS Secret Manager gizli dizileri oluşturun

EMR güvenlik yapılandırmasını oluşturmadan önce iki tane oluşturmanız gerekir. AWS Gizli Yöneticisi sırlar. Bu kimlik bilgilerini LDAP uç noktasıyla etkileşim kurmak ve kullanıcı adı ve grup üyeliği gibi kullanıcı ayrıntılarını almak için kullanırsınız.

  1. Secrets Manager konsolunda, sırları Gezinti bölmesinde.
  2. Klinik Yeni bir sır saklayın.
  3. İçin Gizli tipseçin Diğer tür sır.
  4. belirten yeni bir gizli dizi oluşturun. binduser anahtar olarak ayırt edici isim ve binduser değer olarak şifre.
  5. LDAPS uç noktası SSL genel sertifikasını veya LDAPS kök sertifika yetkilisi genel sertifikasını düz metin olarak belirten ikinci bir gizli dizi oluşturun.
    Bu sertifika güvenilirdir ve EMR kümesi ile LDAPS uç noktası arasında güvenli bir iletişime olanak tanır.

EMR güvenlik yapılandırmasını oluşturun

EMR güvenlik yapılandırmasını oluşturmak için aşağıdaki adımları tamamlayın:

  1. Amazon EMR konsolunda şunu seçin: Güvenlik yapılandırmaları altında EC2'de EMR Gezinti bölmesinde.
  2. Klinik oluşturmak.
  3. İçin Güvenlik yapılandırma adı, isim girin.
  4. İçin Güvenlik yapılandırması kurulum seçenekleriseçin Özel ayarları seçin.
  5. İçin Şifrelemeseçin Aktarım sırasında şifrelemeyi açın.
  6. İçin Sertifika sağlayıcı türü¸ seç PEM.
  7. İçin PEM sertifikası konumunu seçin, şurada bulunan bir PEM paketini girin: Amazon Basit Depolama Hizmeti (Amazon S3) veya bir Java özel sertifika sağlayıcısı.
    LDAP kimlik doğrulama özelliğini kullanmak için aktarım sırasında şifrelemenin zorunlu olduğunu unutmayın. Aktarım sırasında şifreleme hakkında daha fazla bilgi için bkz. Aktarım halindeki verilerin Amazon EMR şifrelemesiyle şifrelenmesi için sertifikaların sağlanması.
  8. Klinik Sonraki.
  9. seç LDAP için Kimlik doğrulama protokolü.
  10. İçin LDAP sunucusu konumu, LDAPS uç noktasını girin (ldaps://<ldap_endpoint_DNS_name>).
  11. İçin LDAP SSL sertifikası, Secrets Manager'da oluşturduğunuz ikinci sırrı girin.
  12. İçin LDAP erişim filtresiLDAP kullanıcı arama tabanından alınan kullanıcıların bir alt kümesine erişimi kısıtlamak için uygulanan bir LDAP filtresi girin. Alanın boş bırakılması durumunda herhangi bir filtre uygulanmaz ve LDAP kullanıcı arama tabanına ait tüm kullanıcılar, kurumsal kimlik bilgileriyle EMR LDAP korumalı uç noktalara erişebilir. Örnek filtreler ve işlevleri aşağıda verilmiştir:
    • (nesneSınıfı=kişi) – Kullanıcıları bu özelliğe göre filtreleyin objectClass olarak ayarla person
    • (memberOf=CN=admins,OU=groups,OU=italy,OU=emr,DC=awsemr,DC=com) – Şuraya ait olan kullanıcıları filtreleyin: admins Grup
    • (|(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)) – Aşağıdakilerden birine ait olan kullanıcıları filtreleyin: data-engineers ya da admins grup (bu yazı için kullandığımız)
  13. İçin değerleri girin LDAP kullanıcı arama tabanı ve LDAP grup arama tabanı. İki arama tabanının satır içi filtreleri desteklemediğini unutmayın (örneğin aşağıdakiler desteklenmez): 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. seç SSH girişini aç. Bu yalnızca LDAP kullanıcılarınızın kurumsal kimlik bilgileriyle küme örnekleri içinde SSH kullanabilmesini istiyorsanız gereklidir. SSH girişi etkinleştirilirse LDAP erişim filtresi gerekir; aksi takdirde SSH kimlik doğrulaması başarısız olur.
  15. İçin LDAP sunucusu bağlama kimlik bilgileri, Secrets Manager'da oluşturduğunuz ilk sırrı girin.
  16. içinde Yetki bölümünde varsayılanları seçili tutun:
    • İçin Uygulamalar için IAM rolüseçin Örnek profili.
    • İçin İnce taneli erişim kontrol yöntemiseçin Hayır.
  17. Klinik Sonraki.
  18. Yapılandırma özetini inceleyin ve oluşturmak.

EMR kümesini başlatın

EMR kümesini şunu kullanarak başlatabilirsiniz: AWS Yönetim Konsolu, AWS Komut Satırı Arayüzü (AWS CLI) veya herhangi biri AWS SDK'sı.

EC2 kümesinde EMR'yi oluştururken aşağıdaki yapılandırmaları belirttiğinizden emin olun:

  • EMR versiyonu – Amazon EMR 6.12.0 veya üzerini kullanın.
  • Uygulamalar – Hadoop, Spark, Hive, Hue, Livy ve Presto/Trino'yu seçin.
  • Güvenlik yapılandırması – Önceki adımda oluşturduğunuz güvenlik yapılandırmasını belirtin.
  • EC2 anahtar çifti – Mevcut bir anahtar çiftini kullanın.
  • Ağ ve güvenlik grupları – EMR EC2 bulut sunucularının LDAPS uç noktasıyla etkileşime girmesine olanak tanıyan bir yapılandırma kullanın. İçinde Uygun LDAP parametrelerini bulun bölümünde geçerli bir kurulumu onaylamanız gerekir.

LDAP kimlik doğrulamasının çalıştığını doğrulayın

Küme çalışır duruma geldiğinde LDAP kimlik doğrulamasının düzgün çalışıp çalışmadığını kontrol edebilirsiniz.

If SSH'ye giriş bir parçası olarak etkinleştirildi LDAP kimlik doğrulaması içinde EMR GüvenlikYapılandırması, bir LDAP kullanıcısı belirleyip istendiğinde ilgili şifreyi sorarak kümenize SSH uygulayabilirsiniz:

ssh myldapuser@<emr_primary_node>

SSH girişi devre dışı bırakıldıysa küme oluşturma sırasında belirtilen EC2 anahtar çiftini kullanarak kümenin içinde SSH yapabilirsiniz:

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

İsterseniz birincil örneğe erişmenin alternatif bir yolu da şunu kullanmaktır: Oturum Yöneticisi, yeteneği AWS Sistem Yöneticisi. Daha fazla bilgi için bkz. AWS Systems Manager Session Manager ile Linux örneğinize bağlanın.

Birincil örneğin içindeyken, LDAP kullanıcılarının ve gruplarının düzgün bir şekilde alınıp alınmadığını aşağıdaki komutu kullanarak test edebilirsiniz: id emretmek. Aşağıda kullanıcının olup olmadığını kontrol etmek için örnek bir komut verilmiştir. john ilgili gruplarla düzgün bir şekilde alınır:

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

Daha sonra kimlik doğrulamayı kurulu farklı çerçevelerde test edebilirsiniz.

Öncelikle çerçevelerin genel sertifikasını alalım ve bunu bir güven deposunda saklayalım. Tüm çerçeveler aynı genel sertifikayı paylaşır (transit sırasında şifrelemeyi ayarlamak için kullandığımız sertifika), dolayısıyla onu almak için SSL korumalı uç noktalardan herhangi birini (Hive bağlantı noktası 10000, Presto/Trino bağlantı noktası 8446, Livy bağlantı noktası 8998) kullanabilirsiniz. . Sertifikayı HiveServer2 uç noktasından (bağlantı noktası 10000) alın:

#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

Daha sonra farklı çerçevelerle güvenli bir şekilde iletişim kurmak için bu güvenilir mağazayı kullanın.

HiveServer2 kimlik doğrulamasını test etmek için aşağıdaki kodu kullanın. 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 kullanıyorsanız, Presto kimlik doğrulamasını şu şekilde test edin: presto CLI (istendiğinde kullanıcı şifresini sağlayın):

#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 kullanıyorsanız, Trino kimlik doğrulamasını şu şekilde test edin: trino CLI (istendiğinde kullanıcı şifresini sağlayın):

#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

test Livy curl ile kimlik doğrulama:

#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: "]}

Spark komutlarını şununla test edin: 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()

Burada kimlik doğrulamayı küme içinden test ettiğimizi, ancak bağlantı ve DNS çözümlemesi doğru şekilde yapılandırıldığı sürece kümenin dışından bile Trino, Hive, Presto ve Livy ile etkileşim kurabileceğimizi unutmayın. Spark CLI'ler yalnızca kümenin içinden kullanılabilen tek CLI'lardır.

Hue kimlik doğrulamasını test etmek için aşağıdaki adımları tamamlayın:

  1. Barındırılan Hue web kullanıcı arayüzüne gidin http://<emr_primary_node>:8888/ ve bir LDAP kullanıcı adı ve parolası sağlayın.
  2. Hive ve Trino/Presto düzenleyicilerinde SQL sorgularını test edin.

Harici bir SQL aracıyla test etmek için (örneğin DBeaver Trino'ya bağlanmak için), aşağıdaki adımları tamamlayın. EMR birincil düğüm güvenlik grubunu, DBeaver IP'sinden istenen çerçeve uç noktası bağlantı noktasına (örneğin, HiveServer10000 için 2, Trino/Presto için 8446) TCP trafiğine izin verecek şekilde yapılandırdığınızdan ve DBeaver istemcisinde DNS çözümlemesini doğru şekilde yapılandırdığınızdan emin olun. EMR birincil düğüm ana bilgisayar adını doğru şekilde çözümlemek için makine.

  1. EMR kümenizin birincil örneğinden dosyaları bir S3 paketine kopyalayın truststore.jks (önceden oluşturulmuş) ve /usr/lib/trino/trino-jdbc/trino-jdbc-XXX-amzn-0.jar (versiyonu değiştir XXX EMR sürümüne bağlı olarak).
  2. DBeaver istemci makinenize indirin. truststore.jks ve trino-jdbc-XXX-amzn-0.jar dosyaları.
  3. DBeaver'ı açın ve seçin veritabanı, Daha sonra seçmek Sürücü Yöneticisi.
  4. Klinik yeni yeni bir sürücü oluşturmak için.
  5. Üzerinde Ayarlar sekmesinde aşağıdaki bilgileri sağlayın:
    • İçin sürücü Adı, girmek EMR Trino.
    • İçin Sınıf adı, girmek io.trino.jdbc.TrinoDriver.
    • İçin URL Şablonu, girmek jdbc:trino://{host}:{port}.
  6. Üzerinde Kütüphaneler sekmesinde aşağıdaki adımları tamamlayın:
    • Klinik Dosya Ekle.
    • Yerel dosya sisteminden Trino JDBC sürücüsü JAR dosyasını seçin (trino-jdbc-XXX-amzn-0.jar).
  7. Klinik OK sürücüyü oluşturmak için.
  8. Klinik veritabanı ve Yeni Veritabanı Bağlantısı.
  9. Üzerinde Ana sekmesinde aşağıdakileri belirtin:
    • İçin Şuna göre bağlan:seçin Ev Sahibi.
    • İçin Ev Sahibi, EMR birincil düğümüne girin.
    • İçin Liman, Trino bağlantı noktasını girin (varsayılan olarak 8446).
  10. Üzerinde Sürücü özellikleri sekmesinde aşağıdaki özellikleri ekleyin:
    • Ekle SSL ile True değer olarak.
    • Ekle SSLTrustStorePath ile truststore.jks değer olarak dosya konumu.
    • Ekle SSLTrustStorePassword ile truststore.jks değer olarak onu oluşturmak için kullandığınız şifre.
  11. Klinik Bitiş.
  12. Oluşturulan bağlantıyı seçin ve Sosyal medya simgesi.
  13. LDAP kullanıcı adınızı ve parolanızı girin ve ardından OK.

Her şey çalışıyorsa gezinme bölmesinde Trino kataloglarına, veritabanlarına ve tablolarına göz atabilmeniz gerekir. Sorguları çalıştırmak için şunu seçin: SQL Düzenleyici, Daha sonra seçmek SQL Düzenleyiciyi aç.

SQL Editörden tablolarınızı sorgulayabilirsiniz.

Sonraki adımlar

Yeni Amazon EMR LDAP kimlik doğrulama özelliği, kullanıcıların EMR yüklü çerçevelere erişme yöntemini basitleştirir. Kullanıcılar bir çerçeve kullanırken erişebilecekleri verileri yönetmek isteyebilirsiniz. Bu özel konu için LDAP kimlik doğrulamasını yerel EMR Apache Ranger entegrasyonuyla birlikte kullanabilirsiniz. Daha fazla bilgi için bkz. Amazon EMR'yi Apache Ranger ile entegre edin.

Temizlemek

Bu gönderiyi takiben oluşturduğunuz kaynakları kaldırmak ve ek maliyetlere maruz kalmamak için aşağıdaki temizleme eylemlerini tamamlayın. Bu yazı için AWS CLI'yi kullanarak temizlik yapıyoruz. Konsol aracılığıyla benzer eylemleri kullanarak da temizlik yapabilirsiniz.

  1. LDAP bağlantısını kontrol etmek için bir EC2 bulut sunucusu başlattıysanız ve artık buna ihtiyacınız yoksa aşağıdaki komutla bunu silin (örnek kimliğinizi belirtin): 
    aws ec2 terminate-instances 
--instance-ids i-XXXXXXXX 
--region <your-aws-region>

  2. DBeaver'ı test etmek için bir EC2 bulut sunucusu başlattıysanız ve artık ona ihtiyacınız yoksa, silmek için önceki komutu kullanabilirsiniz.
  3. EMR kümesini aşağıdaki komutla silin (EMR kümesi kimliğinizi belirtin): 
    aws emr terminate-clusters 
--cluster-ids j-XXXXXXXXXXXXX 
--region <your-aws-region>

    EMR kümesinin Fesih Koruması etkinleştirildi, öncekini çalıştırmadan önce terminate-clusters komutunu devre dışı bırakmanız gerekir. Bunu aşağıdaki komutla yapabilirsiniz (EMR küme kimliğinizi belirtin):

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

  4. EMR güvenlik yapılandırmasını aşağıdaki komutla silin: 
    aws emr delete-security-configuration 
--name <your-security-configuration> 
--region <your-aws-region>

  5. Secrets Manager sırlarını aşağıdaki komutlarla silin: 
    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>

Sonuç

Bu yazıda EC2 kümelerindeki EMR'de LDAP kimlik doğrulamasını nasıl yapılandırabileceğinizi ve test edebileceğinizi tartıştık. Gerekli LDAP ayarlarını nasıl alacağınızı, LDAP uç noktasıyla bağlantıyı nasıl test edeceğinizi, EMR güvenlik yapılandırmanızı nasıl yapılandıracağınızı ve LDAP kimlik doğrulamasının düzgün çalışıp çalışmadığını nasıl test edeceğinizi tartıştık. Bu gönderi aynı zamanda kimlik doğrulama akışının standart Active Directory bölgeler arası güven yapılandırmasıyla karşılaştırıldığında nasıl basitleştirildiğini de vurguladı. Bu özellik hakkında daha fazla bilgi edinmek için bkz. Amazon EMR ile kimlik doğrulama için Active Directory veya LDAP sunucularını kullanın.

Yazarlar Hakkında

Stefano Sandona AWS'de Kıdemli Büyük Veri Çözüm Mimarıdır. Verileri, dağıtılmış sistemleri ve güvenliği seviyor. Dünyanın dört bir yanındaki müşterilerin güvenli, ölçeklenebilir ve güvenilir büyük veri platformları tasarlamasına yardımcı oluyor.

Adnan Hemani AWS'de EMR ekibiyle birlikte çalışan bir Yazılım Geliştirme Mühendisidir. EMR kümeleri üzerinde çalışan uygulamaların güvenlik duruşuna odaklanıyor. Modern Büyük Veri uygulamalarıyla ve müşterilerin bunlarla nasıl etkileşim kurduğuyla ilgileniyor.

spot_img

En Son İstihbarat

spot_img

Telif Hakkı @ 2024 Plato Technologies Inc.