Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Autentikasi ke simpul klaster Amazon EMR
Klien SSH dapat menggunakan pasangan kunci Amazon EC2 untuk mengautentikasi ke instans klaster. Atau, dengan Amazon EMR rilis 5.10.0 dan yang lebih tinggi, Anda dapat mengonfigurasi Kerberos untuk mengautentikasi pengguna dan koneksi SSH ke node utama. Dan dengan Amazon EMR rilis 5.12.0 dan lebih tinggi, Anda dapat mengautentikasi dengan LDAP.
**Topics**
+ [Menggunakan key pair EC2 untuk kredensyal SSH untuk Amazon EMR](emr-plan-access-ssh.md)
+ [Gunakan Kerberos untuk otentikasi dengan Amazon EMR](emr-kerberos.md)
+ [Gunakan Active Directory atau server LDAP untuk otentikasi dengan Amazon EMR](ldap.md)
# Menggunakan key pair EC2 untuk kredensyal SSH untuk Amazon EMR
Simpul klaster Amazon EMR berjalan di instans Amazon EC2. Anda dapat connect ke simpul klaster dengan cara yang sama seperti Anda dapat connect ke instans Amazon EC2. Anda dapat menggunakan Amazon EC2 untuk menciptakan sebuah pasangan kunci baru, atau Anda dapat mengimpor sebuah pasangan kunci yang sudah ada. Ketika Anda membuat sebuah klaster, Anda dapat menentukan psangan kunci Amazon EC2 yang akan digunakan untuk koneksi SSH untuk semua instans klaster. Anda juga dapat membuat klaster tanpa psangan kunci. Hal ini biasanya dilakukan dengan klaster sementara yang mulai, menjalankan langkah-langkah, dan versi terbaru mengakhiri secara otomatis.
Klien SSH yang Anda gunakan connect ke klaster perlu menggunakan file kunci privat yang terkait dengan pasangan kunci ini. Ini adalah file .pem untuk klien SSH yang menggunakan Linux, Unix dan macOS. Anda harus mengatur izin sehingga hanya pemilik kunci yang memiliki izin untuk mengakses file. Ini adalah file .ppk untuk klien SSH menggunakan Windows, dan file .ppk biasanya dibuat dari file .pem.
+ Untuk informasi selengkapnya tentang membuat key pair Amazon EC2, lihat pasangan kunci [Amazon EC2 di Panduan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) Pengguna Amazon *EC2*.
+ *Untuk petunjuk tentang penggunaan Pu TTYgen untuk membuat file.ppk dari file.pem, lihat [Mengonversi kunci pribadi menggunakan Pu di](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#putty-private-key) Panduan Pengguna TTYgen Amazon EC2.*
+ Untuk informasi selengkapnya tentang menyetel izin file.pem dan cara menyambung ke simpul utama klaster EMR menggunakan metode yang berbeda - termasuk dari `ssh` Linux atau macOS, Putty dari Windows, atau dari sistem operasi apa pun yang didukung, lihat. AWS CLI [Connect ke node primer Amazon EMR cluster menggunakan SSH](emr-connect-master-node-ssh.md)
# Gunakan Kerberos untuk otentikasi dengan Amazon EMR
Amazon EMR merilis 5.10.0 dan dukungan yang lebih tinggi Kerberos. Kerberos adalah protokol otentikasi jaringan yang menggunakan kriptografi kunci rahasia untuk memberikan otentikasi yang kuat sehingga kata sandi atau kredensyal lainnya tidak dikirim melalui jaringan dalam format yang tidak terenkripsi.
Di Kerberos, layanan dan pengguna yang perlu mengautentikasi dikenal sebagai *utama*. Utama ada di *ranah* Kerberos. Di ranah, server Kerberos yang dikenal sebagai *pusat distribusi kunci (KDC)* menyediakan sarana bagi utama untuk mengautentikasi. KDC melakukan ini dengan mengeluarkan *tiket* untuk autentikasi. KDC mempertahankan basis data utama dari ranah, kata sandi mereka, dan informasi administratif lainnya tentang setiap utama. KDC juga dapat menerima kredensial autentikasi dari utama di ranah lain, yang dikenal sebagai *kepercayaan lintas ranah*. Selain itu, klaster EMR dapat menggunakan KDC eksternal untuk mengautentikasi utama.
Skenario umum untuk membangun kepercayaan lintas ranah atau menggunakan KDC eksternal adalah untuk mengautentikasi pengguna dari domain Direktori Aktif. Hal ini memungkinkan pengguna untuk mengakses kluster EMR dengan akun domain mereka ketika mereka menggunakan SSH untuk terhubung ke cluster atau bekerja dengan aplikasi data besar.
Ketika Anda menggunakan autentikasi Kerberos, Amazon EMR mengonfigurasi Kerberos untuk aplikasi, komponen, dan subsistem yang diinstal di klaster sehingga mereka saling beratutentikasi satu sama lain.
**penting**
Amazon EMR tidak mendukung AWS Directory Service for Microsoft Active Directory kepercayaan lintas alam atau sebagai KDC eksternal.
Sebelum Anda mengonfigurasi Kerberos menggunakan Amazon EMR, kami merekomendasikan Anda agar familiar dengan konsep Kerberos, layanan yang berjalan pada KDC, dan alat-alat untuk mengelola layanan Kerberos. Untuk informasi selengkapnya, lihat [Dokumentasi Kerberos MIT](http://web.mit.edu/kerberos/krb5-latest/doc/), yang diterbitkan oleh [Konsorsium Kerberos](http://kerberos.org/).
**Topics**
+ [Aplikasi yang didukung dengan Amazon EMR](emr-kerberos-principals.md)
+ [Opsi arsitektur Kerberos dengan Amazon EMR](emr-kerberos-options.md)
+ [Mengonfigurasi Kerberos di Amazon EMR](emr-kerberos-configure.md)
+ [Menggunakan SSH untuk terhubung ke cluster Kerberized dengan Amazon EMR](emr-kerberos-connect-ssh.md)
+ [Tutorial: Konfigurasikan KDC khusus cluster dengan Amazon EMR](emr-kerberos-cluster-kdc.md)
+ [Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif](emr-kerberos-cross-realm.md)
# Aplikasi yang didukung dengan Amazon EMR
Dalam klaster EMR, utama Kerberos adalah layanan aplikasi big data dan subsistem yang berjalan pada semua simpul klaster. Amazon EMR dapat mengonfigurasi aplikasi dan komponen yang tercantum di bawah ini untuk menggunakan Kerberos. Setiap aplikasi memiliki utama pengguna Kerberos yang terkait dengannya.
Amazon EMR tidak support kepercayaan lintas ranah dengan AWS Directory Service for Microsoft Active Directory.
Amazon EMR hanya mengonfigurasi fitur autentikasi Kerberos sumber daya terbuka untuk aplikasi dan komponen yang tercantum di bawah ini. Aplikasi lain yang diinstal bukan Kerberized, yang dapat mengakibatkan ketidakmampuan untuk berkomunikasi dengan komponen Kerberized dan menyebabkan kesalahan aplikasi. Aplikasi dan komponen yang bukan Kerberized tidak mengaktifkan autentikasi. Aplikasi dan komponen yang didukung dapat bervariasi untuk rilis EMR Amazon yang berbeda.
Antarmuka pengguna Livy adalah satu-satunya antarmuka pengguna web yang dihosting di cluster yang Kerberized.
+ **Hadoop MapReduce**
+ **Hbase**
+ **HCatalog**
+ **HDFS**
+ **Sarang**
+ Jangan mengaktifkan Hive dengan autentikasi LDAP. Hal ini dapat menyebabkan masalah komunikasi dengan YARN Kerberized.
+ **Rona**
+ Autentikasi pengguna Hue tidak diatur secara otomatis dan dapat dikonfigurasi menggunakan API konfigurasi.
+ Server Hue adalah Kerberized. Hue front-end (UI) tidak dikonfigurasi untuk autentikasi. Autentikasi LDAP dapat dikonfigurasi untuk UI Hue.
+ **Livy**
+ Peniruan identitas dengan cluster Kerberized didukung di Amazon EMR rilis 5.22.0 dan yang lebih tinggi.
+ **Oozie**
+ **Phoenix**
+ **Presto**
+ Presto mendukung otentikasi Kerberos di Amazon EMR rilis 6.9.0 dan lebih tinggi.
+ [Untuk menggunakan otentikasi Kerberos untuk Presto, Anda harus mengaktifkan enkripsi dalam transit.](emr-data-encryption-options.md#emr-encryption-intransit)
+ **Percikan**
+ **Tez**
+ **Trino**
+ Trino mendukung otentikasi Kerberos di Amazon EMR rilis 6.11.0 dan lebih tinggi.
+ [Untuk menggunakan otentikasi Kerberos untuk Trino, Anda harus mengaktifkan enkripsi dalam transit.](emr-data-encryption-options.md#emr-encryption-intransit)
+ **BENANG**
+ **Zeppelin**
+ Zeppelin hanya dikonfigurasi untuk menggunakan Kerberos dengan interpreter Spark. Zeppelin ini tidak dikonfigurasi untuk penerjemah lain.
+ Peniruan identitas pengguna tidak didukung untuk penerjemah Zeppelin Kerberized selain Spark.
+ **Penjaga kebun binatang**
+ Zookeeper klien tidak didukung.
# Opsi arsitektur Kerberos dengan Amazon EMR
Bila Anda menggunakan Kerberos dengan Amazon EMR, Anda dapat memilih dari arsitektur yang tercantum di bagian ini. Terlepas dari arsitektur yang Anda pilih, Anda mengonfigurasi Kerberos menggunakan langkah yang sama. Anda membuat konfigurasi keamanan, Anda menentukan konfigurasi keamanan dan opsi Kerberos spesifik klaster yang kompatibel, dan Anda membuat direktori HDFS untuk pengguna Linux di klaster yang sesuai dengan utama pengguna di KDC. Untuk penjelasan tentang opsi konfigurasi dan konfigurasi contoh untuk setiap arsitektur, lihat [Mengonfigurasi Kerberos di Amazon EMR](emr-kerberos-configure.md).
## KDC khusus cluster (KDC pada simpul utama)
Konfigurasi ini tersedia dengan Amazon EMR rilis 5.10.0 dan lebih tinggi.
![\[Amazon EMRklaster architecture with master node, core nodes, and task node within a Kerberos realm.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-cluster-dedicated-kdc.png)
**Keuntungan**
+ Amazon EMR memiliki kepemilikan penuh KDC.
+ KDC pada klaster EMR independen dari implementasi KDC terpusat seperti Direktori Aktif Microsoft atau AWS Managed Microsoft AD.
+ Dampak performa minimal karena KDC mengelola autentikasi hanya untuk simpul lokal di klaster.
+ Opsional, klaster Kerberized lainnya dapat referensi KDC sebagai KDC eksternal. Untuk informasi selengkapnya, lihat [KDC eksternal — Node primer pada cluster yang berbeda](#emr-kerberos-extkdc-cluster-summary).
**Pertimbangan dan batasan**
+ Klaster kerberized tidak dapat mengautentikasi satu sama lain, sehingga aplikasi tidak dapat beroperasi. Jika klaster aplikasi perlu untuk beroperasi, Anda harus membuat kepercayaan lintas ranah antara klaster, atau mengatur satu klaster sebagai KDC eksternal untuk klaster lainnya. Jika kepercayaan lintas alam didirikan, KDCs pasti memiliki alam Kerberos yang berbeda.
+ Anda harus membuat pengguna Linux pada instance EC2 dari node utama yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.
+ Utama harus menggunakan file kunci privat EC2 dan kredensial `kinit` untuk connect ke klaster menggunakan SSH.
## Kepercayaan lintas ranah
Di konfigurasi ini, utama (biasanya pengguna) dari ranah Kerberos yang berbeda mengautentikasi komponen aplikasi pada klaster EMR Kerberized, yang memiliki KDC sendiri. KDC pada simpul utama membangun hubungan kepercayaan dengan KDC lain menggunakan *prinsip lintas alam* yang ada di keduanya. KDCs Nama utama dan kata sandi cocok di setiap KDC. Kepercayaan lintas ranah yang paling umum dengan implementasi Direktori Aktif, seperti yang ditunjukkan di diagram berikut. Kepercayaan lintas ranah dengan KDC MIT eksternal atau KDC di klaster Amazon EMR lain juga didukung.
![\[Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-cross-realm-trust.png)
**Keuntungan**
+ Klaster EMR di mana KDC diinstal mempertahankan kepemilikan penuh KDC.
+ Dengan Direktori Aktif, Amazon EMR secara otomatis membuat pengguna Linux yang sesuai dengan utama pengguna dari KDC. Anda masih harus membuat direktori HDFS untuk setiap pengguna. Selain itu, utama pengguna di domain Direktori Aktif dapat mengakses klaster Kerberized menggunakan kredensial `kinit`, tanpa file kunci privat EC2. Ini menghilangkan kebutuhan untuk berbagi file kunci privat di antara pengguna klaster.
+ Karena setiap klaster KDC mengelola autentikasi untuk simpul di klaster, efek latensi jaringan dan pengolahan overhead untuk sejumlah besar simpul di klaster diminimalkan.
**Pertimbangan dan batasan**
+ Jika Anda membangun kepercayaan dengan bidang Direktori Aktif, Anda harus memberikan nama pengguna dan kata sandi Direktori Aktif dengan izin untuk menggabungkan utama untuk domain ketika Anda membuat klaster.
+ Kepercayaan lintas ranah tidak dapat dibuat antara ranah Kerberos dengan nama yang sama.
+ Kepercayaan lintas ranah harus ditetapkan secara eksplisit. Misalnya, jika klaster A dan klaster B keduanya membuat kepercayaan lintas ranah dengan KDC, mereka tidak secara inheren percaya satu sama lain dan aplikasi mereka tidak dapat mengautentikasi satu sama lain untuk beroperasi.
+ KDCs harus dijaga secara independen dan terkoordinasi sehingga kredensyal prinsipal pengguna cocok dengan tepat.
## KDC eksternal
Konfigurasi dengan KDC eksternal didukung dengan Amazon EMR 5.20.0 dan versi terbaru.
+ [KDC Eksternal—KDC MIT](#emr-kerberos-extkdc-mit-summary)
+ [KDC eksternal — Node primer pada cluster yang berbeda](#emr-kerberos-extkdc-cluster-summary)
+ [KDC eksternal—KDC klaster di klaster yang berbeda dengan kepercayaan lintas ranah Direktori Aktif](#emr-kerberos-extkdc-ad-trust-summary)
### KDC Eksternal—KDC MIT
Konfigurasi ini mengizinkan satu klaster EMR atau lebih untuk menggunakan utama didefinisikan dan dipelihara di server KDC MIT.
![\[Amazon EMRklaster architecture with Kerberos realm, showing master, core, and task nodes.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-external-kdc.png)
**Keuntungan**
+ Utama pengelola dikonsolidasikan di satu KDC.
+ Beberapa klaster dapat menggunakan KDC yang sama di ranah Kerberos yang sama. Untuk informasi selengkapnya, lihat [Persyaratan untuk menggunakan beberapa cluster dengan KDC yang sama](#emr-kerberos-multi-kdc).
+ Node utama pada cluster Kerberized tidak memiliki beban kinerja yang terkait dengan pemeliharaan KDC.
**Pertimbangan dan batasan**
+ Anda harus membuat pengguna Linux pada instance EC2 dari setiap node utama cluster Kerberized yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.
+ Utama pengguna harus menggunakan file kunci privat EC2 dan kredensial `kinit` untuk connect ke klaster Kerberized menggunakan SSH.
+ Setiap simpul di klaster EMR Kerberized harus memiliki rute jaringan ke KDC.
+ Setiap simpul di klaster Kerberized menempatkan beban autentikasi pada KDC eksternal, sehingga konfigurasi KDC mempengaruhi performa klaster. Bila Anda mengonfigurasi perangkat keras server KDC, pertimbangkan jumlah maksimum simpul Amazon EMR yang akan didukung secara bersamaan.
+ Klaster performa tergantung pada latensi jaringan antara simpul di klaster Kerberized dan KDC.
+ Pemecahan masalah bisa lebih sulit karena saling ketergantungan.
### KDC eksternal — Node primer pada cluster yang berbeda
Konfigurasi ini hampir identik dengan implementasi MIT KDC eksternal di atas, kecuali bahwa KDC berada di simpul utama cluster EMR. Untuk informasi selengkapnya, lihat [KDC khusus cluster (KDC pada simpul utama)](#emr-kerberos-localkdc-summary) dan [Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif](emr-kerberos-cross-realm.md).
![\[Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-external-cluster-kdc.png)
**Keuntungan**
+ Utama pengelola dikonsolidasikan di satu KDC.
+ Beberapa klaster dapat menggunakan KDC yang sama di ranah Kerberos yang sama. Untuk informasi selengkapnya, lihat [Persyaratan untuk menggunakan beberapa cluster dengan KDC yang sama](#emr-kerberos-multi-kdc).
**Pertimbangan dan batasan**
+ Anda harus membuat pengguna Linux pada instance EC2 dari setiap node utama cluster Kerberized yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.
+ Utama pengguna harus menggunakan file kunci privat EC2 dan kredensial `kinit` untuk connect ke klaster Kerberized menggunakan SSH.
+ Setiap simpul di setiap klaster EMR harus memiliki rute jaringan ke KDC.
+ Setiap simpul Amazon EMR di grup Kerberized menempatkan beban autentikasi pada KDC eksternal, sehingga konfigurasi KDC mempengaruhi performa klaster. Bila Anda mengonfigurasi perangkat keras server KDC, pertimbangkan jumlah maksimum simpul Amazon EMR yang akan didukung secara bersamaan.
+ Klaster performa tergantung pada latensi jaringan antara simpul di klaster dan KDC.
+ Pemecahan masalah bisa lebih sulit karena saling ketergantungan.
### KDC eksternal—KDC klaster di klaster yang berbeda dengan kepercayaan lintas ranah Direktori Aktif
Di konfigurasi ini, Anda pertama kali membuat sebuah klaster dengan KDC khusus klaster yang memiliki satu arah lintas ranah kepercayaan dengan Direktori Aktif. Untuk tutorial detail, lihat [Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif](emr-kerberos-cross-realm.md). Anda kemudian meluncurkan klaster tambahan, referensi KDC klaster yang memiliki kepercayaan sebagai KDC eksternal. Misalnya, lihat [KDC klaster eksternal dengan kepercayaan lintas ranah Direktori Aktif](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust). Hal ini mengizinkan setiap klaster Amazon EMR yang menggunakan KDC eksternal untuk mengautentikasi kepala didefinisikan dan dipelihara di domain Direktori Aktif Microsoft.
![\[Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-external-ad-trust-kdc.png)
**Keuntungan**
+ Utama pengelola dikonsolidasikan di domain Direktori Aktif.
+ Amazon EMR bergabung dengan ranah Direktori Aktif, yang menghilangkan kebutuhan untuk membuat pengguna Linux yang sesuai dengan pengguna Direktori Aktif. Anda masih harus membuat direktori HDFS untuk setiap pengguna.
+ Beberapa klaster dapat menggunakan KDC yang sama di ranah Kerberos yang sama. Untuk informasi selengkapnya, lihat [Persyaratan untuk menggunakan beberapa cluster dengan KDC yang sama](#emr-kerberos-multi-kdc).
+ Utama pengguna di domain Direktori Aktif dapat mengakses klaster Kerberized menggunakan kredensial `kinit`, tanpa file kunci privat EC2. Ini menghilangkan kebutuhan untuk berbagi file kunci privat di antara pengguna klaster.
+ Hanya satu simpul utama EMR Amazon yang memiliki beban untuk mempertahankan KDC, dan hanya cluster itu yang harus dibuat dengan kredensyal Direktori Aktif untuk kepercayaan lintas alam antara KDC dan Direktori Aktif.
**Pertimbangan dan batasan**
+ Setiap simpul di setiap klaster EMR harus memiliki rute jaringan ke KDC dan pengendali domain Direktori Aktif.
+ Setiap simpul Amazon EMR menempatkan beban autentikasi pada KDC eksternal, sehingga konfigurasi KDC mempengaruhi performa klaster. Bila Anda mengonfigurasi perangkat keras server KDC, pertimbangkan jumlah maksimum simpul Amazon EMR yang akan didukung secara bersamaan.
+ Klaster performa tergantung pada latensi jaringan antara simpul di klaster dan server KDC.
+ Pemecahan masalah bisa lebih sulit karena saling ketergantungan.
## Persyaratan untuk menggunakan beberapa cluster dengan KDC yang sama
Beberapa klaster dapat menggunakan KDC yang sama di ranah Kerberos yang sama. Namun, jika cluster berjalan secara bersamaan, maka cluster mungkin gagal jika mereka menggunakan nama ServicePrincipal Kerberos yang bertentangan.
Jika Anda memiliki beberapa cluster bersamaan dengan KDC eksternal yang sama, maka pastikan bahwa cluster menggunakan alam Kerberos yang berbeda. Jika cluster harus menggunakan ranah Kerberos yang sama, maka pastikan bahwa cluster berada dalam subnet yang berbeda, dan rentang CIDR mereka tidak tumpang tindih.
# Mengonfigurasi Kerberos di Amazon EMR
Bagian ini menyediakan detail konfigurasi dan instans untuk menyiapkan Kerberos dengan arsitektur umum. Terlepas dari arsitektur yang Anda pilih, dasar-dasar konfigurasinya sama dan dilakukan di tiga langkah. Jika Anda menggunakan KDC eksternal atau mengatur kepercayaan lintas ranah, Anda harus memastikan bahwa setiap simpul di sebuah klaster memiliki rute jaringan ke KDC eksternal, termasuk konfigurasi grup keamanan yang berlaku untuk mengizinkan lalu lintas Kerberos inbound dan outbound.
## Langkah 1: Membuat konfigurasi keamanan dengan properti Kerberos
Konfigurasi keamanan menentukan detail tentang KDC Kerberos, dan mengizinkan konfigurasi Kerberos untuk digunakan kembali setiap kali Anda membuat sebuah klaster. Anda dapat membuat konfigurasi keamanan menggunakan konsol Amazon EMR, EMR API AWS CLI, atau EMR. Konfigurasi keamanan juga dapat berisi opsi keamanan lainnya, seperti enkripsi. Untuk informasi lebih lanjut tentang membuat konfigurasi keamanan dan menentukan konfigurasi keamanan ketika Anda membuat sebuah klaster, lihat [Gunakan konfigurasi keamanan untuk mengatur keamanan klaster Amazon EMR](emr-security-configurations.md). Untuk informasi tentang properti Kerberos di konfigurasi keamanan, lihat [Pengaturan Kerberos untuk konfigurasi keamanan](emr-kerberos-configure-settings.md#emr-kerberos-security-configuration).
## Langkah 2: Membuat sebuah klaster dan menentukan atribut Kerberos khusus klaster
Ketika Anda membuat sebuah klaster, Anda menentukan konfigurasi keamanan Kerberos bersama dengan pilihan Kerberos khusus klaster. Ketika Anda menggunakan konsol Amazon EMR, hanya opsi Kerberos yang kompatibel dengan konfigurasi keamanan tertentu yang tersedia. Saat Anda menggunakan API EMR Amazon AWS CLI atau Amazon, pastikan Anda menentukan opsi Kerberos yang kompatibel dengan konfigurasi keamanan yang ditentukan. Misalnya, jika Anda menetapkan kata sandi utama untuk kepercayaan lintas ranah ketika Anda membuat sebuah klaster menggunakan CLI, dan konfigurasi keamanan yang ditentukan tidak dikonfigurasi dengan lintas ranah kepercayaan parameter, maka kesalahan akan terjadi. Untuk informasi selengkapnya, lihat [Pengaturan Kerberos untuk klaster](emr-kerberos-configure-settings.md#emr-kerberos-cluster-configuration).
## Langkah 3: Konfigurasikan simpul utama cluster
Tergantung pada persyaratan arsitektur dan implementasi Anda, tambahan set up pada klaster mungkin diperlukan. Anda dapat melakukan ini setelah Anda membuatnya atau menggunakan langkah-langkah atau tindakan bootstrap selama proses pembuatan.
Untuk setiap pengguna yang diautentikasi KerberOS yang terhubung ke cluster menggunakan SSH, Anda harus memastikan bahwa akun Linux dibuat yang sesuai dengan pengguna Kerberos. Jika prinsipal pengguna disediakan oleh pengontrol domain Active Directory, baik sebagai KDC eksternal atau melalui kepercayaan lintas alam, Amazon EMR membuat akun Linux secara otomatis. Jika Direktori Aktif tidak digunakan, Anda harus membuat utama untuk setiap pengguna yang sesuai dengan pengguna Linux mereka. Untuk informasi selengkapnya, lihat [Mengkonfigurasi cluster EMR Amazon untuk pengguna HDFS yang diautentikasi KerberOS dan koneksi SSH](emr-kerberos-configuration-users.md).
Setiap pengguna juga harus memiliki direktori pengguna HDFS yang mereka miliki, yang harus Anda buat. Selain itu, SSH harus dikonfigurasi dengan GSSAPI yang diaktifkan untuk mengizinkan koneksi dari pengguna terautentikasi Kerberos. GSSAPI harus diaktifkan pada node utama, dan aplikasi SSH klien harus dikonfigurasi untuk menggunakan GSSAPI. Untuk informasi selengkapnya, lihat [Mengkonfigurasi cluster EMR Amazon untuk pengguna HDFS yang diautentikasi KerberOS dan koneksi SSH](emr-kerberos-configuration-users.md).
# Pengaturan konfigurasi keamanan dan klaster untuk Kerberos di Amazon EMR
Ketika Anda membuat sebuah klaster Kerberized, Anda menentukan konfigurasi keamanan bersama-sama dengan atribut Kerberos yang khusus untuk klaster. Anda tidak dapat menentukan satu set tanpa yang lain, atau akan terjadi kesalahan.
Topik ini menyediakan parameter konfigurasi gambaran umum yang tersedia untuk Kerberos ketika Anda membuat konfigurasi keamanan dan sebuah klaster. Selain itu, contoh CLI untuk membuat konfigurasi keamanan yang kompatibel dan klaster disediakan untuk arsitektur umum.
## Pengaturan Kerberos untuk konfigurasi keamanan
Anda dapat membuat konfigurasi keamanan yang menentukan atribut Kerberos menggunakan konsol EMR Amazon, API EMR, AWS CLI atau EMR API. Konfigurasi keamanan juga dapat berisi opsi keamanan lainnya, seperti enkripsi. Untuk informasi selengkapnya, lihat [Buat konfigurasi keamanan dengan konsol EMR Amazon atau dengan AWS CLI](emr-create-security-configuration.md).
Gunakan referensi berikut untuk memahami pengaturan konfigurasi keamanan yang tersedia untuk arsitektur Kerberos yang Anda pilih. Pengaturan konsol Amazon EMR ditampilkan. Untuk opsi CLI yang sesuai, lihat [Menentukan pengaturan Kerberos menggunakan AWS CLI](emr-create-security-configuration.md#emr-kerberos-cli-parameters) atau [Contoh konfigurasi](emr-kerberos-config-examples.md).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/emr-kerberos-configure-settings.html)
## Pengaturan Kerberos untuk klaster
Anda dapat menentukan setelan Kerberos saat membuat klaster menggunakan konsol EMR Amazon, API EMR, AWS CLI atau EMR.
Gunakan referensi berikut untuk memahami pengaturan konfigurasi klaster yang tersedia untuk arsitektur Kerberos yang Anda pilih. Pengaturan konsol Amazon EMR ditampilkan. Untuk opsi CLI yang sesuai, lihat [Contoh konfigurasi](emr-kerberos-config-examples.md).
| Parameter | Deskripsi |
| --- | --- |
| Ranah | Nama ranah Kerberos untuk klaster. Konvensi Kerberos adalah untuk mengatur ini agar sama dengan nama domain, tetapi dengan huruf besar. Misalnya, untuk domain `ec2.internal`, menggunakan `EC2.INTERNAL` sebagai nama ranah. |
| Kata sandi admin KDC | Kata sandi yang digunakan di klaster untuk `kadmin` atau `kadmin.local`. Ini adalah antarmuka baris perintah untuk sistem administrasi Kerberos V5, yang mempertahankan Kerberos utama, kebijakan kata sandi, dan keytabs untuk klaster. |
| Kepercayaan lintas ranah kata sandi utama (opsional) | Diperlukan saat membangun kepercayaan lintas ranah. Kata sandi utama lintas ranah, yang harus identik di seluruh ranah. Menggunakan kata sandi yang kuat. |
| Pengguna gabungan domain Direktori Aktif (opsional) | Diperlukan saat menggunakan Direktori Aktif di kepercayaan lintas ranah. Ini adalah nama log in pengguna akun Direktori Aktif dengan izin untuk bergabung dengan komputer ke domain. Amazon EMR menggunakan identitas ini untuk bergabung dengan klaster ke domain. Untuk informasi selengkapnya, lihat [Langkah 3: Tambahkan akun ke domain untuk EMR Cluster](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
| Kata sandi gabungan domain Direktori Aktif (opsional) | Kata sandi untuk pengguna gabungan domain Direktori Aktif Untuk informasi selengkapnya, lihat [Langkah 3: Tambahkan akun ke domain untuk EMR Cluster](emr-kerberos-cross-realm.md#emr-kerberos-ad-users). |
# Contoh konfigurasi
Contoh berikut menunjukkan konfigurasi keamanan dan konfigurasi cluster untuk skenario umum. AWS CLI perintah ditampilkan untuk singkatnya.
## KDC Lokal
Perintah berikut membuat cluster dengan KDC khusus cluster yang berjalan pada node utama. Konfigurasi tambahan pada klaster diperlukan. Untuk informasi selengkapnya, lihat [Mengkonfigurasi cluster EMR Amazon untuk pengguna HDFS yang diautentikasi KerberOS dan koneksi SSH](emr-kerberos-configuration-users.md).
**Buat Konfigurasi Keamanan**
```
aws emr create-security-configuration --name LocalKDCSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc",\
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24 }}}}'
```
**Buat Cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole \
--security-configuration LocalKDCSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyPassword
```
## KDC khusus klaster dengan kepercayaan lintas ranah Direktori Aktif
Perintah berikut membuat cluster dengan KDC khusus cluster yang berjalan pada node utama dengan kepercayaan lintas-ranah ke domain Active Directory. Konfigurasi tambahan pada klaster dan Direktori Aktif diperlukan. Untuk informasi selengkapnya, lihat [Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif](emr-kerberos-cross-realm.md).
**Buat Konfigurasi Keamanan**
```
aws emr create-security-configuration --name LocalKDCWithADTrustSecurityConfig \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ClusterDedicatedKdc", \
"ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24, \
"CrossRealmTrustConfiguration": {"Realm":"AD.DOMAIN.COM", \
"Domain":"ad.domain.com", "AdminServer":"ad.domain.com", \
"KdcServer":"ad.domain.com"}}}}}'
```
**Buat Cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration KDCWithADTrustSecurityConfig \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=MyClusterKDCAdminPassword,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPassword
```
## KDC eksternal pada klaster yang berbeda
Perintah berikut membuat cluster yang mereferensikan KDC khusus cluster pada node utama dari cluster yang berbeda untuk mengautentikasi prinsipal. Konfigurasi tambahan pada klaster diperlukan. Untuk informasi selengkapnya, lihat [Mengkonfigurasi cluster EMR Amazon untuk pengguna HDFS yang diautentikasi KerberOS dan koneksi SSH](emr-kerberos-configuration-users.md).
**Buat Konfigurasi Keamanan**
```
aws emr create-security-configuration --name ExtKDCOnDifferentCluster \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSOfKDCMaster:749", \
"KdcServer": "MasterDNSOfKDCMaster:88"}}}}'
```
**Buat Cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge \
--applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCOnDifferentCluster \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword
```
## KDC klaster eksternal dengan kepercayaan lintas ranah Direktori Aktif
Perintah berikut membuat klaster tanpa KDC. Cluster mereferensikan KDC khusus cluster yang berjalan pada node utama cluster lain untuk mengautentikasi prinsipal. KDC yang memiliki kepercayaan lintas ranah dengan pengendali domain Direktori Aktif. Konfigurasi tambahan pada node utama dengan KDC diperlukan. Untuk informasi selengkapnya, lihat [Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif](emr-kerberos-cross-realm.md).
**Buat Konfigurasi Keamanan**
```
aws emr create-security-configuration --name ExtKDCWithADIntegration \
--security-configuration '{"AuthenticationConfiguration": \
{"KerberosConfiguration": {"Provider": "ExternalKdc", \
"ExternalKdcConfiguration": {"KdcServerType": "Single", \
"AdminServer": "MasterDNSofClusterKDC:749", \
"KdcServer": "MasterDNSofClusterKDC.com:88", \
"AdIntegrationConfiguration": {"AdRealm":"AD.DOMAIN.COM", \
"AdDomain":"ad.domain.com", \
"AdServer":"ad.domain.com"}}}}}'
```
**Buat Cluster**
```
aws emr create-cluster --release-label emr-7.12.0 \
--instance-count 3 --instance-type m5.xlarge --applications Name=Hadoop Name=Hive \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2Key \
--service-role EMR_DefaultRole --security-configuration ExtKDCWithADIntegration \
--kerberos-attributes Realm=EC2.INTERNAL,KdcAdminPassword=KDCOnMasterPassword,\
ADDomainJoinUser=MyPrivilegedADUserName,ADDomainJoinPassword=PasswordForADDomainJoinUser
```
# Mengkonfigurasi cluster EMR Amazon untuk pengguna HDFS yang diautentikasi KerberOS dan koneksi SSH
Amazon EMR membuat klien pengguna terautentikasi Kerberos untuk aplikasi yang berjalan di klaster misalnya, pengguna `hadoop`, pengguna `spark`, dan lainnya. Anda juga dapat menambahkan pengguna yang terautentikasi agar klaster memproses menggunakan Kerberos. Pengguna terautentikasi kemudian dapat connect ke klaster dengan kredensial Kerberos mereka dan bekerja dengan aplikasi. Bagi pengguna yang ingin mengautentikasi ke klaster, konfigurasi berikut diperlukan:
+ Akun Linux yang cocok dengan prinsipal Kerberos di KDC harus ada di cluster. Amazon EMR melakukan ini secara otomatis di arsitektur yang mengintegrasikan dengan Direktori Aktif.
+ Anda harus membuat direktori pengguna HDFS pada node utama untuk setiap pengguna, dan memberikan izin pengguna ke direktori.
+ Anda harus mengkonfigurasi layanan SSH sehingga GSSAPI diaktifkan pada node utama. Selain itu, pengguna harus memiliki klien SSH dengan GSSAPI diaktifkan.
## Menambahkan pengguna Linux dan prinsipal Kerberos ke node utama
Jika Anda tidak menggunakan Active Directory, Anda harus membuat akun Linux pada node utama cluster dan menambahkan prinsipal untuk pengguna Linux ini ke KDC. Ini termasuk prinsipal di KDC untuk simpul utama. Selain prinsipal pengguna, KDC yang berjalan pada node primer membutuhkan prinsipal untuk host lokal.
Ketika arsitektur Anda termasuk integrasi Direktori Aktif, pengguna Linux dan utama di KDC lokal, jika berlaku, dibuat secara otomatis. Anda bisa melewati langkah ini. Untuk informasi selengkapnya, lihat [Kepercayaan lintas ranah](emr-kerberos-options.md#emr-kerberos-crossrealm-summary) dan [KDC eksternal—KDC klaster di klaster yang berbeda dengan kepercayaan lintas ranah Direktori Aktif](emr-kerberos-options.md#emr-kerberos-extkdc-ad-trust-summary).
**penting**
KDC, bersama dengan database prinsipal, hilang ketika node utama berakhir karena node utama menggunakan penyimpanan sementara. Jika Anda membuat pengguna untuk koneksi SSH, kami merekomendasikan Anda membuat kepercayaan lintas ranah dengan KDC eksternal yang dikonfigurasi untuk ketersediaan tinggi. Atau, jika Anda membuat pengguna untuk koneksi SSH menggunakan akun Linux, otomatiskan proses pembuatan akun menggunakan tindakan dan skrip bootstrap sehingga dapat diulang saat Anda membuat cluster baru.
Mengirimkan langkah ke klaster setelah Anda membuatnya atau ketika Anda membuat klaster adalah cara termudah untuk menambahkan pengguna dan utama KDC. Atau, Anda dapat terhubung ke node utama menggunakan EC2 key pair sebagai `hadoop` pengguna default untuk menjalankan perintah. Untuk informasi selengkapnya, lihat [Connect ke node primer Amazon EMR cluster menggunakan SSH](emr-connect-master-node-ssh.md).
Contoh berikut mengirimkan script bash `configureCluster.sh` untuk sebuah klaster yang sudah ada, mereferensikan ID klaster. Script disimpan ke Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,\
Args=["s3://amzn-s3-demo-bucket/configureCluster.sh"]
```
Contoh berikut menunjukkan isi dari script `configureCluster.sh`. Script juga menangani membuat direktori pengguna HDFS dan mengaktifkan GSSAPI untuk SSH, yang dibahas di bagian berikut.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([lijuan]=pwd1 [marymajor]=pwd2 [richardroe]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create a principal for each user in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add hdfs directory for each user
hdfs dfs -mkdir /user/$name
#Change owner of each user's hdfs directory to that user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
## Menambahkan direktori HDFS pengguna
Untuk memungkinkan pengguna Anda masuk ke cluster untuk menjalankan pekerjaan Hadoop, Anda harus menambahkan direktori pengguna HDFS untuk akun Linux mereka, dan memberikan setiap pengguna kepemilikan direktori mereka.
Mengirimkan langkah ke klaster setelah Anda membuat atau ketika Anda membuat klaster adalah cara termudah untuk membuat direktori HDFS. Atau, Anda dapat terhubung ke node utama menggunakan EC2 key pair sebagai `hadoop` pengguna default untuk menjalankan perintah. Untuk informasi selengkapnya, lihat [Connect ke node primer Amazon EMR cluster menggunakan SSH](emr-connect-master-node-ssh.md).
Contoh berikut mengirimkan script bash `AddHDFSUsers.sh` untuk sebuah klaster yang sudah ada, mereferensikan ID klaster. Script disimpan ke Amazon S3.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Contoh berikut menunjukkan isi dari script `AddHDFSUsers.sh`.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD, or Linux users created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
## Mengaktifkan GSSAPI untuk SSH
Agar pengguna yang diautentikasi KerberOS dapat terhubung ke node utama menggunakan SSH, layanan SSH harus mengaktifkan otentikasi GSSAPI. Untuk mengaktifkan GSSAPI, jalankan perintah berikut dari baris perintah node utama atau gunakan langkah untuk menjalankannya sebagai skrip. Setelah mengonfigurasi ulang SSH, Anda harus me-restart layanan.
```
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
# Menggunakan SSH untuk terhubung ke cluster Kerberized dengan Amazon EMR
Bagian ini menunjukkan langkah-langkah bagi pengguna yang diautentikasi KerberOS untuk terhubung ke simpul utama cluster EMR.
Setiap komputer yang digunakan untuk koneksi SSH harus menginstal klien SSH dan aplikasi klien Kerberos. Komputer Linux kemungkinan besar ikut memasukkan ini secara default. Misalnya, OpenSSH diinstal pada kebanyakan sistem operasi Linux, Unix, dan macOS. Anda dapat memeriksa klien SSH dengan mengetik **ssh** di baris perintah. Jika komputer Anda tidak mengenali perintah, instal klien SSH untuk terhubung ke node utama. Proyek OpenSSH menyediakan implementasi gratis rangkaian lengkap alat SSH. Untuk informasi selengkapnya, lihat situs web [OpenSSH](http://www.openssh.org/). Pengguna Windows dapat menggunakan aplikasi seperti [PuTTY T](http://www.chiark.greenend.org.uk/~sgtatham/putty/) sebagai klien SSH.
Untuk informasi selengkapnya tentang koneksi SSH, lihat [Connect ke kluster EMR Amazon](emr-connect-master-node.md).
SSH menggunakan GSSAPI untuk mengautentikasi klien Kerberos, dan Anda harus mengaktifkan otentikasi GSSAPI untuk layanan SSH pada node utama cluster. Untuk informasi selengkapnya, lihat [Mengaktifkan GSSAPI untuk SSH](emr-kerberos-configuration-users.md#emr-kerberos-ssh-config). Klien SSH juga harus menggunakan GSSAPI.
Dalam contoh berikut, untuk *MasterPublicDNS* gunakan nilai yang muncul untuk **Master DNS publik** pada tab **Ringkasan** panel detail klaster—misalnya,. *ec2-11-222-33-44.compute-1.amazonaws.com*
## Prasyarat untuk krb5.conf (Bukan Direktori Aktif)
Saat menggunakan konfigurasi tanpa integrasi Active Directory, selain klien SSH dan aplikasi klien Kerberos, setiap komputer klien harus memiliki salinan `/etc/krb5.conf` file yang cocok dengan `/etc/krb5.conf` file pada node primer cluster.
**Untuk menyalin file krb5.conf**
1. Gunakan SSH untuk terhubung ke node utama menggunakan key pair EC2 dan `hadoop` pengguna default—misalnya,. `hadoop@MasterPublicDNS` Untuk petunjuk mendetail, lihat [Connect ke kluster EMR Amazon](emr-connect-master-node.md).
1. Dari simpul utama, salin isi `/etc/krb5.conf` file. Untuk informasi selengkapnya, lihat [Connect ke kluster EMR Amazon](emr-connect-master-node.md).
1. Pada setiap komputer klien yang akan connect ke klaster, buat file `/etc/krb5.conf` identik berdasarkan salinan yang Anda buat pada langkah sebelumnya.
## Menggunakan kinit dan SSH
Setiap kali pengguna connect dari komputer klien menggunakan kredensial Kerberos, pengguna harus terlebih dahulu memperbaharui tiket Kerberos untuk pengguna mereka pada komputer klien. Selain itu, klien SSH harus dikonfigurasi untuk menggunakan autentikasi GSSAPI.
**Untuk menggunakan SSH agar connect ke klaster EMR Kerberized**
1. Gunakan `kinit` untuk memperbarui tiket Kerberos seperti yang ditunjukkan di contoh berikut
```
kinit user1
```
1. Gunakan klien `ssh` bersama dengan utama yang Anda buat di KDC khusus klaster atau nama pengguna Direktori Aktif. Pastikan bahwa autentikasi GSSAPI diaktifkan seperti yang ditunjukkan di contoh berikut.
**Contoh: Pengguna Linux**
Opsi `-K ` menentukan autentikasi GSSAPI.
```
ssh -K user1@MasterPublicDNS
```
**Contoh: Pengguna Windows (PutTY)**
Pastikan bahwa opsi autentikasi GSSAPI untuk sesi diaktifkan seperti yang ditunjukkan:
![\[PuTTY Configuration window showing GSSAPI authentication options and library preferences.\]](http://docs.aws.amazon.com/id_id/emr/latest/ManagementGuide/images/kerb-gssapi-putty.png)
# Tutorial: Konfigurasikan KDC khusus cluster dengan Amazon EMR
Topik ini memandu Anda melalui pembuatan cluster dengan *pusat distribusi kunci khusus cluster (KDC)*, menambahkan akun Linux secara manual ke semua node cluster, menambahkan prinsip Kerberos ke KDC pada node utama, dan memastikan bahwa komputer klien memiliki klien Kerberos diinstal.
Untuk informasi lebih lanjut tentang support Amazon EMR untuk Kerberos dan KDC, serta tautan ke Dokumentasi MIT Kerberos, lihat [Gunakan Kerberos untuk otentikasi dengan Amazon EMR](emr-kerberos.md).
## Langkah 1: Buat klaster Kerberized
1. Buat konfigurasi keamanan yang mengaktifkan Kerberos. Contoh berikut menunjukkan `create-security-configuration` perintah menggunakan AWS CLI yang menentukan konfigurasi keamanan sebagai struktur JSON inline. Anda juga dapat membuat referensi pada file yang disimpan secara lokal.
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{"AuthenticationConfiguration": {"KerberosConfiguration":
{"Provider": "ClusterDedicatedKdc", "ClusterDedicatedKdcConfiguration": {"TicketLifetimeInHours": 24}}}}'
```
1. Buat sebuah klaster yang membuat referensi pada konfigurasi keamanan, menetapkan atribut Kerberos untuk klaster, dan menambahkan akun Linux menggunakan tindakan bootstrap. Contoh berikut menunjukkan perintah `create-cluster ` menggunakan AWS CLI. Perintah referensi konfigurasi keamanan yang Anda buat di atas, `MyKerberosConfig`. Itu juga membuat referensi script sederhana, `createlinuxusers.sh`, sebagai tindakan bootstrap, yang Anda buat dan unggah ke Amazon S3 sebelum membuat klaster.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-7.12.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair \
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd \
--bootstrap-actions Path=s3://amzn-s3-demo-bucket/createlinuxusers.sh
```
Kode berikut menunjukkan isi `createlinuxusers.sh` skrip, yang menambahkan user1, user2, dan user3 ke setiap node di cluster. Pada langkah berikutnya, Anda menambahkan pengguna ini sebagai utama KDC.
```
#!/bin/bash
sudo adduser user1
sudo adduser user2
sudo adduser user3
```
## Langkah 2: Menambahkan utama ke KDC, membuat direktori pengguna HDFS, dan mengonfigurasi SSH
KDC yang berjalan pada node primer membutuhkan prinsipal yang ditambahkan untuk host lokal dan untuk setiap pengguna yang Anda buat di cluster. Anda juga dapat membuat direktori HDFS untuk setiap pengguna jika mereka perlu untuk connect ke klaster dan menjalankan Tugas Hadoop. Demikian pula, konfigurasi layanan SSH untuk mengaktifkan autentikasi GSSAPI, yang diperlukan untuk Kerberos. Setelah Anda mengaktifkan GSSAPI, restart layanan SSH.
Cara termudah untuk menyelesaikan tugas-tugas ini adalah kirim langkah ke klaster. Contoh berikut kirim ke script bash `configurekdc.sh` untuk klaster yang Anda buat pada langkah sebelumnya, mereferensikan ID klasternya. Script disimpan ke Amazon S3. Atau, Anda dapat terhubung ke node utama menggunakan key pair EC2 untuk menjalankan perintah atau mengirimkan langkah selama pembuatan cluster.
```
aws emr add-steps --cluster-id --steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,Jar=s3://myregion.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/configurekdc.sh"]
```
Kode berikut menunjukkan isi `configurekdc.sh` skrip.
```
#!/bin/bash
#Add a principal to the KDC for the primary node, using the primary node's returned host name
sudo kadmin.local -q "ktadd -k /etc/krb5.keytab host/`hostname -f`"
#Declare an associative array of user names and passwords to add
declare -A arr
arr=([user1]=pwd1 [user2]=pwd2 [user3]=pwd3)
for i in ${!arr[@]}; do
#Assign plain language variables for clarity
name=${i}
password=${arr[${i}]}
# Create principal for sshuser in the primary node and require a new password on first logon
sudo kadmin.local -q "addprinc -pw $password +needchange $name"
#Add user hdfs directory
hdfs dfs -mkdir /user/$name
#Change owner of user's hdfs directory to user
hdfs dfs -chown $name:$name /user/$name
done
# Enable GSSAPI authentication for SSH and restart SSH service
sudo sed -i 's/^.*GSSAPIAuthentication.*$/GSSAPIAuthentication yes/' /etc/ssh/sshd_config
sudo sed -i 's/^.*GSSAPICleanupCredentials.*$/GSSAPICleanupCredentials yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd
```
Pengguna yang Anda tambahkan sekarang dapat connect ke klaster menggunakan SSH. Untuk informasi selengkapnya, lihat [Menggunakan SSH untuk terhubung ke cluster Kerberized dengan Amazon EMR](emr-kerberos-connect-ssh.md).
# Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif
Ketika Anda mengatur kepercayaan lintas ranah, Anda mengizinkan utama (biasanya pengguna) dari ranah Kerberos yang berbeda untuk mengautentikasi komponen aplikasi pada klaster EMR. *Pusat distribusi kunci khusus cluster (KDC)* membangun hubungan kepercayaan dengan KDC lain menggunakan prinsip *lintas alam* yang ada di keduanya. KDCs Nama utama dan kata sandi sangat cocok.
Kepercayaan lintas ranah mengharuskan KDC dapat mencapai satu sama lain melalui jaringan dan menyelesaikan nama domain masing-masing. Langkah-langkah untuk membangun hubungan kepercayaan lintas ranah dengan pengendali domain Microsoft AD berjalan sebagai instans EC2 disediakan di bawah ini, bersama dengan pengaturan jaringan contoh yang menyediakan konektivitas dan resolusi nama domain yang diperlukan. Setiap pengaturan jaringan yang memungkinkan lalu lintas jaringan yang KDCs diperlukan antara dapat diterima.
Opsional, setelah Anda membuat kepercayaan lintas ranah dengan Direktori Aktif menggunakan KDC pada satu klaster, Anda dapat membuat klaster lain menggunakan konfigurasi keamanan yang berbeda untuk referensi KDC pada klaster pertama sebagai KDC eksternal. Untuk konfigurasi keamanan dan pengaturan klaster contoh, lihat [KDC klaster eksternal dengan kepercayaan lintas ranah Direktori Aktif](emr-kerberos-config-examples.md#emr-kerberos-example-extkdc-ad-trust).
Untuk informasi lebih lanjut tentang support Amazon EMR untuk Kerberos dan KDC, serta tautan ke Dokumentasi MIT Kerberos, lihat [Gunakan Kerberos untuk otentikasi dengan Amazon EMR](emr-kerberos.md).
**penting**
Amazon EMR tidak mendukung kepercayaan lintas alam dengan. AWS Directory Service for Microsoft Active Directory
[Langkah 1: Mengatur VPC dan subnet](#emr-kerberos-ad-network)
[Langkah 2: Peluncuran dan menginstal pengendali domain Direktori Aktif](#emr-kerberos-ad-dc)
[Langkah 3: Tambahkan akun ke domain untuk EMR Cluster](#emr-kerberos-ad-users)
[Langkah 4: Konfigurasi kepercayaan masuk pada pengendali domain Direktori Aktif](#emr-kerberos-ad-configure-trust)
[Langkah 5: Gunakan opsi DHCP yang ditetapkan untuk menentukan pengendali domain Direktori Aktif sebagai server DNS VPC](#emr-kerberos-ad-DHCP)
[Langkah 6: Meluncurkan klaster EMR Kerberized](#emr-kerberos-ad-cluster)
[Langkah 7: Buat pengguna HDFS dan atur izin pada cluster untuk akun Active Directory](#emr-kerberos-ad-hadoopuser)
## Langkah 1: Mengatur VPC dan subnet
Langkah-langkah berikut menunjukkan menciptakan VPC dan subnet sehingga KDC klaster khusus dapat mencapai pengendali domain Direktori Aktif dan menyelesaikan nama domain. Di langkah-langkah ini, resolusi nama domain disediakan oleh referensi pengendali domain Direktori Aktif sebagai server nama domain di DHCP pilihan ditetapkan. Untuk informasi selengkapnya, lihat [Langkah 5: Gunakan opsi DHCP yang ditetapkan untuk menentukan pengendali domain Direktori Aktif sebagai server DNS VPC](#emr-kerberos-ad-DHCP).
Pengendali domain KDC dan Direktori Aktif harus mampu menyelesaikan nama domain satu sama lain. Hal ini memungkinkan Amazon EMR untuk bergabung dengan komputer ke domain dan secara otomatis mengkonfigurasi akun Linux yang sesuai dan parameter SSH pada instance cluster.
Jika Amazon EMR tidak dapat menyelesaikan nama domain, Anda dapat membuat referensi pada kepercayaan menggunakan alamat IP pengendali domain Direktori Aktif. Namun, Anda harus menambahkan akun Linux secara manual, menambahkan prinsip yang sesuai ke KDC khusus cluster, dan mengkonfigurasi SSH.
**Untuk mengatur VPC dan subnet**
1. Buat Amazon VPC dengan subnet publik tunggal Untuk informasi selengkapnya, lihat [Langkah 1: Buat VPC](https://docs.aws.amazon.com/AmazonVPC/latest/GettingStartedGuide/getting-started-ipv4.html#getting-started-create-vpc) di *Panduan Memulai Amazon VPC*.
**penting**
Saat Anda menggunakan pengontrol domain Microsoft Active Directory, pilih blok CIDR untuk cluster EMR sehingga IPv4 semua alamat kurang dari sembilan karakter panjangnya (misalnya, 10.0.0.0/16). Ini karena nama DNS komputer cluster digunakan ketika komputer bergabung dengan direktori Active Directory. AWS menetapkan [nama host DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-hostnames) berdasarkan IPv4 alamat sedemikian rupa sehingga alamat IP yang lebih panjang dapat menghasilkan nama DNS lebih dari 15 karakter. Direktori Aktif memiliki batas 15 karakter untuk mendaftar dan bergabung dengan nama komputer, dan memotong nama yang lebih panjang, yang dapat menyebabkan kesalahan tak terduga.
1. Menghapus opsi default DHCP yang ditetapkan untuk VPC. Untuk informasi selengkapnya, lihat [Mengubah VPC untuk menggunakan opsi tidak menggunakan DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCP_Use_No_Options). Kemudian, Anda menambahkan yang baru yang menentukan pengendali domain Direktori Aktif sebagai server DNS.
1. Mengonfirmasi bahwa support DNS diaktifkan untuk VPC, yaitu Hostnames DNS dan Resolusi DNS keduanya diaktifkan. Mereka diaktifkan secara default. Untuk informasi selengkapnya, lihat [Memperbarui support DNS untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating).
1. Mengonfirmasi bahwa VPC Anda memiliki gateway internet terlampir, yang merupakan default. Untuk informasi selengkapnya, lihat [Membuat dan melampirkan gateway internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Attach_Gateway).
**catatan**
Gateway internet digunakan di contoh ini karena Anda membuat pengendali domain baru untuk VPC. Gateway internet mungkin tidak diperlukan untuk aplikasi Anda. Satu-satunya persyaratan adalah bahwa KDC khusus klaster dapat mengakses pengendali domain Direktori Aktif.
1. Membuat tabel rute kustom, menambahkan rute yang menargetkan Gateway Internet, dan versi terbaru melampirkannya ke subnet Anda. Untuk informasi selengkapnya, lihat [Buat tabel rute kustom](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#Add_IGW_Routing).
1. Ketika Anda meluncurkan instans EC2 untuk pengontrol domain, itu harus memiliki IPv4 alamat publik statis agar Anda dapat terhubung dengannya menggunakan RDP. Cara termudah untuk melakukannya adalah dengan mengonfigurasi subnet Anda untuk menetapkan alamat publik secara otomatis. IPv4 Ini bukan pengaturan default ketika subnet dibuat. Untuk informasi selengkapnya, lihat [Memodifikasi atribut IPv4 pengalamatan publik subnet Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html#subnet-public-ip). Opsional, Anda dapat menetapkan alamat saat Anda meluncurkan instans tersebut. Untuk informasi selengkapnya, lihat [Menetapkan IPv4 alamat publik selama peluncuran instance](https://docs.aws.amazon.com/vpc/latest/userguide/using-instance-addressing.html#public-ip-addresses).
1. Setelah selesai, catat VPC dan subnet Anda. IDs Anda menggunakannya nanti ketika Anda meluncurkan pengendali domain Direktori Aktif dan klaster.
## Langkah 2: Peluncuran dan menginstal pengendali domain Direktori Aktif
1. Peluncuran instans EC2 berdasarkan Microsoft Windows Server 2016 Base AMI. Kami merekomendasikan m4.xlarge atau tipe instans yang lebih baik. Untuk informasi selengkapnya, lihat [Meluncurkan AWS Marketplace instance](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/launch-marketplace-console.html) di *Panduan Pengguna Amazon EC2*.
1. Membuat catatan ID grup dari grup keamanan yang terkait dengan instans EC2. Anda membutuhkannya untuk [Langkah 6: Meluncurkan klaster EMR Kerberized](#emr-kerberos-ad-cluster). Kami menggunakan*sg-012xrlmdomain345*. Atau, Anda dapat menentukan grup keamanan yang berbeda untuk klaster EMR dan instans ini yang mengizinkan lalu lintas antara mereka. Untuk informasi selengkapnya, lihat [Grup Keamanan Amazon EC2 untuk instans Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html) di *Panduan Pengguna Amazon EC2*.
1. Connect ke instans EC2 menggunakan RDP. Untuk informasi selengkapnya, lihat [Menyambungkan ke instans Windows Anda](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/connecting_to_windows_instance.html) di *Panduan Pengguna Amazon EC2*.
1. Mulai **Pengelola Server** untuk menginstal dan mengonfigurasi peran Layanan domain Direktori Aktif di server. Promosikan server ke pengendali domain dan tugaskan nama domain (contoh yang kita gunakan di sini adalah `ad.domain.com`). Membuat catatan nama domain karena Anda memerlukannya nanti ketika Anda membuat konfigurasi keamanan EMR dan klaster. Jika Anda baru dalam hal menyiapkan Direktori Aktif, Anda dapat mengikuti petunjuk di [Cara mengatur Direktori Aktif (AD) di Windows Server 2016](https://ittutorials.net/microsoft/windows-server-2016/setting-up-active-directory-ad-in-windows-server-2016/).
Instans me-restart setelah Anda selesai.
## Langkah 3: Tambahkan akun ke domain untuk EMR Cluster
RDP ke pengontrol domain Active Directory untuk membuat akun di Pengguna Direktori Aktif dan Komputer untuk setiap pengguna cluster. Untuk informasi selengkapnya, lihat [Membuat Akun Pengguna di Pengguna Direktori Aktif dan Komputer](https://technet.microsoft.com/en-us/library/dd894463(v=ws.10).aspx) di situs *Microsoft Learn*. Catat setiap **Nama logon pengguna** pengguna. Anda akan memerlukan ini ketika Anda mengonfigurasi klaster.
Selain itu, buat akun dengan hak istimewa yang cukup untuk bergabung dengan komputer ke domain. Anda menentukan akun ini ketika Anda membuat sebuah klaster. Amazon EMR menggunakannya untuk menggabungkan instans klaster untuk domain. Anda menentukan akun ini dan kata sandinya di [Langkah 6: Meluncurkan klaster EMR Kerberized](#emr-kerberos-ad-cluster). Untuk mendelegasikan hak istimewa bergabung komputer ke akun, kami sarankan Anda membuat grup dengan hak istimewa bergabung dan kemudian menetapkan pengguna ke grup. Untuk instruksi, lihat [Mendelegasikan hak istimwwa bergabung direktori](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_join_privileges.html) di *AWS Directory Service Panduan Administrasi*.
## Langkah 4: Konfigurasi kepercayaan masuk pada pengendali domain Direktori Aktif
Perintah contoh di bawah ini membuat kepercayaan di Direktori Aktif, yang merupakan satu arah, masuk, non-transitif, kepercayaan ranah dengan KDC khusus klaster. Contoh yang kita gunakan untuk ranah klaster adalah `EC2.INTERNAL`. Ganti *KDC-FQDN* dengan nama **DNS Publik** yang terdaftar untuk simpul utama Amazon EMR yang menghosting KDC. Parameter `passwordt` menentukan **kata sandi utama lintas ranah**, yang Anda tentukan bersama dengan **ranah** klaster saat Anda membuat klaster. Nama ranah berasal dari nama domain default di `us-east-1` untuk klaster. `Domain` adalah domain Direktori Aktif di mana Anda menciptakan kepercayaan, yang merupakan kasus yang lebih kecil oleh konvensi. Contoh menggunakan `ad.domain.com`
Buka prompt perintah Windows dengan hak istimewa administrator dan ketik perintah berikut untuk membuat hubungan kepercayaan pada pengendali domain Direktori Aktif:
```
C:\Users\Administrator> ksetup /addkdc EC2.INTERNAL KDC-FQDN
C:\Users\Administrator> netdom trust EC2.INTERNAL /Domain:ad.domain.com /add /realm /passwordt:MyVeryStrongPassword
C:\Users\Administrator> ksetup /SetEncTypeAttr EC2.INTERNAL AES256-CTS-HMAC-SHA1-96
```
## Langkah 5: Gunakan opsi DHCP yang ditetapkan untuk menentukan pengendali domain Direktori Aktif sebagai server DNS VPC
Sekarang bahwa pengendali domain Direktori Aktif dikonfigurasi, Anda harus mengonfigurasi VPC untuk menggunakannya sebagai server nama domain untuk resolusi nama di VPC Anda. Untuk melakukannya, lampirkan set opsi DHCP. Tentukan **Nama domain** sebagai nama domain klaster Anda - misalnya, `ec2.internal` jika klaster Anda berada di us-east-1 atau `region.compute.internal` untuk wilayah lain. Untuk **server nama Domain**, Anda harus menentukan alamat IP pengontrol domain Active Directory (yang harus dapat dijangkau dari cluster) sebagai entri pertama, diikuti oleh **AmazonProvidedDNS (misalnya ***xx.xx.xx.xx*, AmazonProvided** DNS**). Untuk informasi selengkapnya, lihat [Mengganti set opsi DHCP](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html#DHCPOptions).
## Langkah 6: Meluncurkan klaster EMR Kerberized
1. Di Amazon EMR, buat konfigurasi keamanan yang menentukan pengendali domain Direktori Aktif yang Anda buat di langkah-langkah sebelumnya. Perintah contoh ditunjukkan di bawah ini. Ganti domain, `ad.domain.com`, dengan nama domain yang Anda tentukan di [Langkah 2: Peluncuran dan menginstal pengendali domain Direktori Aktif](#emr-kerberos-ad-dc).
```
aws emr create-security-configuration --name MyKerberosConfig \
--security-configuration '{
"AuthenticationConfiguration": {
"KerberosConfiguration": {
"Provider": "ClusterDedicatedKdc",
"ClusterDedicatedKdcConfiguration": {
"TicketLifetimeInHours": 24,
"CrossRealmTrustConfiguration": {
"Realm": "AD.DOMAIN.COM",
"Domain": "ad.domain.com",
"AdminServer": "ad.domain.com",
"KdcServer": "ad.domain.com"
}
}
}
}
}'
```
1. Buat klaster dengan atribut berikut:
+ Gunakan opsi `--security-configuration` untuk menentukan konfigurasi keamanan yang Anda buat. Kami gunakan *MyKerberosConfig* dalam contoh.
+ Gunakan properti `SubnetId` dari `--ec2-attributes option` untuk menentukan subnet yang Anda buat di [Langkah 1: Mengatur VPC dan subnet](#emr-kerberos-ad-network). Kami gunakan *step1-subnet* dalam contoh.
+ Gunakan `AdditionalMasterSecurityGroups` dan `AdditionalSlaveSecurityGroups` `--ec2-attributes` opsi untuk menentukan bahwa grup keamanan yang terkait dengan pengontrol domain AD dari [Langkah 2: Peluncuran dan menginstal pengendali domain Direktori Aktif](#emr-kerberos-ad-dc) dikaitkan dengan simpul utama klaster serta node inti dan tugas. Kami gunakan *sg-012xrlmdomain345* dalam contoh.
Gunakan `--kerberos-attributes` untuk menentukan atribut Kerberos khusus klaster berikut:
+ Ranah untuk klaster yang Anda tentukan ketika Anda mengatur pengendali domain Direktori Aktif.
+ Kata sandi utama kepercayaan lintas ranah yang Anda tentukan sebagai `passwordt` di [Langkah 4: Konfigurasi kepercayaan masuk pada pengendali domain Direktori Aktif](#emr-kerberos-ad-configure-trust).
+ `KdcAdminPassword`, yang dapat Anda gunakan untuk mengelola KDC khusus klaster.
+ Nama logon dan kata sandi pengguna akun Direktori Aktif dengan hak istimewa gabungan komputer yang Anda buat di [Langkah 3: Tambahkan akun ke domain untuk EMR Cluster](#emr-kerberos-ad-users).
Contoh berikut meluncurkan klaster Kerberized.
```
aws emr create-cluster --name "MyKerberosCluster" \
--release-label emr-5.10.0 \
--instance-type m5.xlarge \
--instance-count 3 \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,KeyName=MyEC2KeyPair,\
SubnetId=step1-subnet, AdditionalMasterSecurityGroups=sg-012xrlmdomain345,
AdditionalSlaveSecurityGroups=sg-012xrlmdomain345\
--service-role EMR_DefaultRole \
--security-configuration MyKerberosConfig \
--applications Name=Hadoop Name=Hive Name=Oozie Name=Hue Name=HCatalog Name=Spark \
--kerberos-attributes Realm=EC2.INTERNAL,\
KdcAdminPassword=MyClusterKDCAdminPwd,\
ADDomainJoinUser=ADUserLogonName,ADDomainJoinPassword=ADUserPassword,\
CrossRealmTrustPrincipalPassword=MatchADTrustPwd
```
## Langkah 7: Buat pengguna HDFS dan atur izin pada cluster untuk akun Active Directory
Saat menyiapkan hubungan kepercayaan dengan Active Directory, Amazon EMR membuat pengguna Linux di cluster untuk setiap akun Active Directory. Misalnya, nama logon pengguna `LiJuan` di Active Directory memiliki akun Linux. `lijuan` Nama pengguna Direktori Aktif dapat berisi huruf besar, tetapi Linux tidak menerima casing Direktori Aktif.
Untuk memungkinkan pengguna Anda masuk ke cluster untuk menjalankan pekerjaan Hadoop, Anda harus menambahkan direktori pengguna HDFS untuk akun Linux mereka, dan memberikan setiap pengguna kepemilikan direktori mereka. Untuk melakukannya, kami merekomendasikan Anda menjalankan script yang disimpan ke Amazon S3 sebagai langkah klaster. Atau, Anda dapat menjalankan perintah dalam skrip di bawah ini dari baris perintah pada node utama. Gunakan key pair EC2 yang Anda tentukan ketika Anda membuat cluster untuk terhubung ke node utama melalui SSH sebagai pengguna Hadoop. Untuk informasi selengkapnya, lihat [Menggunakan key pair EC2 untuk kredensyal SSH untuk Amazon EMR](emr-plan-access-ssh.md).
Jalankan perintah berikut untuk menambahkan langkah ke cluster yang menjalankan skrip,*AddHDFSUsers.sh*.
```
aws emr add-steps --cluster-id \
--steps Type=CUSTOM_JAR,Name=CustomJAR,ActionOnFailure=CONTINUE,\
Jar=s3://region.elasticmapreduce/libs/script-runner/script-runner.jar,Args=["s3://amzn-s3-demo-bucket/AddHDFSUsers.sh"]
```
Isi file *AddHDFSUsers.sh* adalah sebagai berikut.
```
#!/bin/bash
# AddHDFSUsers.sh script
# Initialize an array of user names from AD or Linux users and KDC principals created manually on the cluster
ADUSERS=("lijuan" "marymajor" "richardroe" "myusername")
# For each user listed, create an HDFS user directory
# and change ownership to the user
for username in ${ADUSERS[@]}; do
hdfs dfs -mkdir /user/$username
hdfs dfs -chown $username:$username /user/$username
done
```
### Grup Direktori Aktif dipetakan ke grup Hadoop
Amazon EMR menggunakan System Security Services Daemon (SSD) untuk memetakan grup Direktori Aktif untuk grup Hadoop. Untuk mengonfirmasi pemetaan grup, setelah Anda masuk ke node utama seperti yang dijelaskan[Menggunakan SSH untuk terhubung ke cluster Kerberized dengan Amazon EMR](emr-kerberos-connect-ssh.md), Anda dapat menggunakan `hdfs groups` perintah untuk mengonfirmasi bahwa grup Active Directory yang menjadi milik akun Active Directory Anda telah dipetakan ke grup Hadoop untuk pengguna Hadoop yang sesuai di cluster. Anda juga dapat memeriksa pemetaan grup pengguna lain dengan menentukan satu nama pengguna atau lebih dengan perintah, misalnya `hdfs groups lijuan`. Untuk informasi selengkapnya, lihat [grup](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html#groups) di [Panduan Perintah HDFS Apache](https://hadoop.apache.org/docs/r2.7.1/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html).
# Gunakan Active Directory atau server LDAP untuk otentikasi dengan Amazon EMR
Dengan Amazon EMR merilis 6.12.0 dan yang lebih tinggi, Anda dapat menggunakan protokol LDAP over SSL (LDAPS) untuk meluncurkan cluster yang terintegrasi secara native dengan server identitas perusahaan Anda. LDAP (Lightweight Directory Access Protocol) adalah protokol aplikasi terbuka dan netral vendor yang mengakses dan memelihara data. LDAP umumnya digunakan untuk otentikasi pengguna terhadap server identitas perusahaan yang di-host pada aplikasi seperti Active Directory (AD) dan OpenLDAP. Dengan integrasi asli ini, Anda dapat menggunakan server LDAP Anda untuk mengautentikasi pengguna di Amazon EMR.
Sorotan integrasi Amazon EMR LDAP meliputi:
+ Amazon EMR mengonfigurasi aplikasi yang didukung untuk mengautentikasi dengan otentikasi LDAP atas nama Anda.
+ Amazon EMR mengonfigurasi dan memelihara keamanan untuk aplikasi yang didukung dengan protokol Kerberos. Anda tidak perlu memasukkan perintah atau skrip apa pun.
+ Anda mendapatkan kontrol akses halus (FGAC) melalui otorisasi Apache Ranger untuk database dan tabel Hive Metastore. Untuk informasi selengkapnya, lihat [Mengintegrasikan Amazon EMR dengan Apache Ranger](emr-ranger.md).
+ Ketika Anda memerlukan kredensyal LDAP untuk mengakses kluster, Anda mendapatkan kontrol akses halus (FGAC) atas siapa yang dapat mengakses kluster EMR Anda melalui SSH.
Halaman-halaman berikut memberikan gambaran konseptual, prasyarat, dan langkah-langkah untuk meluncurkan cluster EMR dengan integrasi Amazon EMR LDAP.
**Topics**
+ [Ikhtisar LDAP dengan Amazon EMR](ldap-overview.md)
+ [Komponen LDAP untuk Amazon EMR](ldap-components.md)
+ [Dukungan aplikasi dan pertimbangan dengan LDAP untuk Amazon EMR](ldap-considerations.md)
+ [Konfigurasikan dan luncurkan cluster EMR dengan LDAP](ldap-setup.md)
+ [Contoh menggunakan LDAP dengan Amazon EMR](ldap-examples.md)
# Ikhtisar LDAP dengan Amazon EMR
Lightweight Directory Access Protocol (LDAP) adalah protokol perangkat lunak yang digunakan administrator jaringan untuk mengelola dan mengontrol akses ke data dengan mengautentikasi pengguna dalam jaringan perusahaan. Protokol LDAP menyimpan informasi dalam hierarkis, struktur direktori pohon. Untuk informasi lebih lanjut, lihat [Konsep LDAP Dasar](https://ldap.com/basic-ldap-concepts/) di *LDAP.com*.
Dalam jaringan perusahaan, banyak aplikasi mungkin menggunakan protokol LDAP untuk mengautentikasi pengguna. Dengan integrasi Amazon EMR LDAP, kluster EMR secara native dapat menggunakan protokol LDAP yang sama dengan konfigurasi keamanan tambahan.
**Ada dua implementasi utama protokol LDAP yang didukung Amazon EMR: **Active Directory** dan OpenLDAP.** Sementara implementasi lain dimungkinkan, sebagian besar sesuai dengan protokol otentikasi yang sama seperti Active Directory atau OpenLDAP.
## Direktori Aktif (AD)
Active Directory (AD) adalah layanan direktori dari Microsoft untuk jaringan domain Windows. AD disertakan pada sebagian besar sistem operasi Windows Server, dan dapat berkomunikasi dengan klien melalui protokol LDAP dan LDAPS. Untuk autentikasi, Amazon EMR mencoba mengikat pengguna dengan instans AD Anda dengan Nama Utama Pengguna (UPN) sebagai nama dan kata sandi yang dibedakan. UPN menggunakan format `username@domain_name` standar.
## OpenLDAP
OpenLDAP adalah implementasi open source gratis dari protokol LDAP. Untuk otentikasi, Amazon EMR mencoba mengikat pengguna dengan instans OpenLDAP Anda dengan nama domain yang memenuhi syarat (FQDN) sebagai nama dan kata sandi yang dibedakan. FQDN menggunakan format standar. `username_attribute=username,LDAP_user_search_base` Umumnya, `username_attribute` nilainya`uid`, dan `LDAP_user_search_base` nilainya berisi atribut pohon yang mengarah ke pengguna. Misalnya, `ou=People,dc=example,dc=com`.
Implementasi gratis dan open-source lainnya dari protokol LDAP biasanya mengikuti FQDN yang serupa dengan OpenLDAP untuk nama-nama terkemuka penggunanya.
# Komponen LDAP untuk Amazon EMR
Anda dapat menggunakan server LDAP Anda untuk mengautentikasi dengan Amazon EMR dan aplikasi apa pun yang langsung digunakan pengguna pada cluster EMR melalui komponen-komponen berikut.
**Agen Rahasia**
*Agen Rahasia* adalah proses on-cluster yang mengautentikasi semua permintaan pengguna. Agen Rahasia membuat pengguna mengikat ke server LDAP Anda atas nama aplikasi yang didukung pada cluster EMR. Agen Rahasia berjalan sebagai `emrsecretagent` pengguna, dan menulis log ke `/emr/secretagent/log` direktori. Log ini memberikan rincian tentang status permintaan otentikasi setiap pengguna dan kesalahan apa pun yang mungkin muncul selama otentikasi pengguna.
**Layanan Keamanan Sistem Daemon (SSSD)**
*SSSD* adalah daemon yang berjalan pada setiap node dari cluster EMR berkemampuan LDAP. SSSD membuat dan mengelola pengguna UNIX untuk menyinkronkan identitas perusahaan jarak jauh Anda ke setiap node. Aplikasi berbasis benang seperti Hive dan Spark mengharuskan pengguna UNIX lokal ada di setiap node yang menjalankan kueri untuk pengguna.
# Dukungan aplikasi dan pertimbangan dengan LDAP untuk Amazon EMR
Topik ini mencantumkan aplikasi yang didukung, fitur yang didukung, dan fitur yang tidak didukung.
## Aplikasi yang didukung dengan LDAP untuk Amazon EMR
**penting**
Aplikasi yang tercantum di halaman ini adalah satu-satunya aplikasi yang didukung Amazon EMR untuk LDAP. Untuk memastikan keamanan klaster, Anda hanya dapat menyertakan aplikasi yang kompatibel dengan LDAP saat membuat klaster EMR dengan LDAP diaktifkan. Jika Anda mencoba menginstal aplikasi lain yang tidak didukung, Amazon EMR akan menolak permintaan Anda untuk klaster baru.
Amazon EMR merilis 6.12 dan lebih tinggi mendukung integrasi LDAP dengan aplikasi berikut:
+ Apache Livy
+ Apache Sarang melalui HiveServer 2 () HS2
+ Trino
+ Presto
+ Hue
Anda juga dapat menginstal aplikasi berikut pada cluster EMR dan mengonfigurasinya untuk memenuhi kebutuhan keamanan Anda:
+ Apache Spark
+ Apache Hadoop
## Fitur yang didukung dengan LDAP untuk Amazon EMR
Anda dapat menggunakan fitur EMR Amazon berikut dengan integrasi LDAP:
**catatan**
Untuk menjaga kredensyal LDAP tetap aman, Anda harus menggunakan enkripsi dalam transit untuk mengamankan aliran data di dalam dan di luar klaster. Untuk informasi selengkapnya tentang enkripsi dalam perjalanan, lihat[Enkripsi data saat istirahat dan dalam perjalanan dengan Amazon EMR](emr-data-encryption.md).
+ Enkripsi dalam perjalanan (wajib) dan saat istirahat
+ Grup klaster, armada instans, dan instans Spot
+ Konfigurasi ulang aplikasi pada klaster berjalan
+ Server-side encryption (SSE) EMRFS
## Fitur yang tidak didukung
Pertimbangkan batasan berikut saat Anda menggunakan integrasi Amazon EMR LDAP:
+ Amazon EMR menonaktifkan langkah-langkah untuk cluster dengan LDAP diaktifkan.
+ Amazon EMR tidak mendukung peran runtime dan AWS Lake Formation integrasi untuk cluster dengan LDAP diaktifkan.
+ Amazon EMR tidak mendukung LDAP dengan StartTLS.
+ Amazon EMR tidak mendukung mode ketersediaan tinggi (cluster dengan beberapa node utama) untuk cluster dengan LDAP diaktifkan.
+ Anda tidak dapat memutar kredensyal atau sertifikat bind untuk klaster dengan LDAP diaktifkan. Jika salah satu bidang tersebut diputar, sebaiknya Anda memulai klaster baru dengan kredensyal atau sertifikat bind yang diperbarui.
+ Anda harus menggunakan basis pencarian yang tepat dengan LDAP. Basis pencarian pengguna dan grup LDAP tidak mendukung filter pencarian LDAP.
# Konfigurasikan dan luncurkan cluster EMR dengan LDAP
Bagian ini mencakup cara mengkonfigurasi Amazon EMR untuk digunakan dengan otentikasi LDAP.
**Topics**
+ [Tambahkan AWS Secrets Manager izin ke peran instans EMR Amazon](ldap-setup-asm.md)
+ [Buat konfigurasi keamanan Amazon EMR untuk integrasi LDAP](ldap-setup-security.md)
+ [Luncurkan cluster EMR yang mengautentikasi dengan LDAP](ldap-setup-launch.md)
# Tambahkan AWS Secrets Manager izin ke peran instans EMR Amazon
Amazon EMR menggunakan peran layanan IAM untuk melakukan tindakan atas nama Anda untuk menyediakan dan mengelola klaster. Peran layanan untuk instans EC2 cluster, juga disebut profil *instans EC2 untuk Amazon EMR*, adalah jenis peran layanan khusus yang diberikan Amazon EMR ke setiap instans EC2 dalam klaster saat diluncurkan.
Untuk menentukan izin kluster EMR agar berinteraksi dengan data Amazon S3 dan layanan AWS lainnya, tentukan profil instans Amazon EC2 kustom, bukan saat Anda meluncurkan klaster. `EMR_EC2_DefaultRole` Untuk informasi selengkapnya, lihat [Peran layanan untuk instans EC2 klaster (profil instans EC2)](emr-iam-role-for-ec2.md) dan [Sesuaikan peran IAM dengan Amazon EMR](emr-iam-roles-custom.md).
Tambahkan pernyataan berikut ke profil instans EC2 default untuk memungkinkan Amazon EMR menandai sesi dan mengakses yang menyimpan sertifikat AWS Secrets Manager LDAP.
```
{
"Sid": "AllowAssumeOfRolesAndTagging",
"Effect": "Allow",
"Action": ["sts:TagSession", "sts:AssumeRole"],
"Resource": [
"arn:aws:iam::111122223333:role/LDAP_DATA_ACCESS_ROLE_NAME",
"arn:aws:iam::111122223333:role/LDAP_USER_ACCESS_ROLE_NAME"
]
},
{
"Sid": "AllowSecretsRetrieval",
"Effect": "Allow",
"Action": "secretsmanager:GetSecretValue",
"Resource": [
"arn:aws:secretsmanager:us-east-1:111122223333:secret:LDAP_SECRET_NAME*",
"arn:aws:secretsmanager:us-east-1:111122223333:secret:ADMIN_LDAP_SECRET_NAME*"
]
}
```
**catatan**
Permintaan klaster Anda akan gagal jika Anda lupa `*` karakter wildcard di akhir nama rahasia saat Anda menetapkan izin Secrets Manager. Wildcard mewakili versi rahasia.
Anda juga harus membatasi cakupan AWS Secrets Manager kebijakan hanya pada sertifikat yang dibutuhkan klaster Anda untuk menyediakan instance.
# Buat konfigurasi keamanan Amazon EMR untuk integrasi LDAP
Sebelum Anda dapat meluncurkan kluster EMR dengan integrasi LDAP, gunakan langkah-langkah [Buat konfigurasi keamanan dengan konsol EMR Amazon atau dengan AWS CLI](emr-create-security-configuration.md) untuk membuat konfigurasi keamanan Amazon EMR untuk klaster. Selesaikan konfigurasi berikut di `LDAPConfiguration` blok di bawah`AuthenticationConfiguration`, atau di bidang yang sesuai di bagian Konfigurasi **Keamanan konsol** EMR Amazon:
**`EnableLDAPAuthentication`**
Opsi konsol: **Protokol otentikasi:** LDAP
Untuk menggunakan integrasi LDAP, setel opsi ini ke `true` atau pilih sebagai protokol otentikasi Anda saat Anda membuat klaster di konsol. Secara default, `EnableLDAPAuthentication` adalah `true` saat Anda membuat konfigurasi keamanan di konsol EMR Amazon.
**`LDAPServerURL`**
Opsi konsol: Lokasi **server LDAP**
Lokasi server LDAP termasuk awalan:. `ldaps://location_of_server`
**`BindCertificateARN`**
Opsi konsol: Sertifikat **SSL LDAP**
AWS Secrets Manager ARN yang berisi sertifikat untuk menandatangani sertifikat SSL yang digunakan server LDAP. Jika server LDAP Anda ditandatangani oleh Public Certificate Authority (CA), Anda dapat memberikan AWS Secrets Manager ARN dengan file kosong. Untuk informasi selengkapnya tentang cara menyimpan sertifikat di Secrets Manager, lihat[Simpan sertifikat TLS di AWS Secrets Manager](emr-ranger-tls-certificates.md).
**`BindCredentialsARN`**
Opsi konsol: **Server LDAP mengikat kredensyal**
AWS Secrets Manager ARN yang berisi pengguna admin LDAP mengikat kredensyal. Kredensyal disimpan sebagai objek JSON. Hanya ada satu pasangan kunci-nilai dalam rahasia ini; kunci dalam pasangan adalah nama pengguna, dan nilainya adalah kata sandi. Misalnya, `{"uid=admin,cn=People,dc=example,dc=com": "AdminPassword1"}`. Ini adalah bidang opsional kecuali Anda mengaktifkan login SSH untuk cluster EMR Anda. Dalam banyak konfigurasi, instance Active Directory memerlukan kredensyal bind untuk memungkinkan SSSD menyinkronkan pengguna.
**`LDAPAccessFilter`**
Opsi konsol: Filter **akses LDAP**
Menentukan subset objek dalam server LDAP Anda yang dapat mengautentikasi. Misalnya, jika semua yang ingin Anda berikan akses ke semua pengguna dengan kelas `posixAccount` objek di server LDAP Anda, tentukan filter akses sebagai`(objectClass=posixAccount)`.
**`LDAPUserSearchBase`**
Opsi konsol: **Basis pencarian pengguna LDAP**
Basis pencarian yang dimiliki pengguna Anda di dalam server LDAP Anda. Misalnya, `cn=People,dc=example,dc=com`.
**`LDAPGroupSearchBase`**
Opsi konsol: **Basis pencarian grup LDAP**
Basis pencarian yang dimiliki grup Anda di dalam server LDAP Anda. Misalnya, `cn=Groups,dc=example,dc=com`.
**`EnableSSHLogin`**
Opsi konsol: **Login SSH**
Menentukan apakah atau tidak untuk mengizinkan otentikasi password dengan kredensyal LDAP. Kami tidak menyarankan Anda mengaktifkan opsi ini. Pasangan kunci adalah rute yang lebih aman untuk memungkinkan akses ke cluster EMR. Bidang ini opsional dan default ke. `false`
**`LDAPServerType`**
Opsi konsol: Jenis **server LDAP**
Menentukan jenis server LDAP yang terhubung dengan Amazon EMR. Opsi yang didukung adalah Active Directory dan OpenLDAP. Jenis server LDAP lainnya mungkin berfungsi, tetapi Amazon EMR tidak secara resmi mendukung jenis server lainnya. Untuk informasi selengkapnya, lihat [Komponen LDAP untuk Amazon EMR](ldap-components.md).
**`ActiveDirectoryConfigurations`**
Sub-blok yang diperlukan untuk konfigurasi keamanan yang menggunakan jenis server Active Directory.
**`ADDomain`**
Opsi konsol: **Domain Direktori Aktif**
Nama domain yang digunakan untuk membuat User Principal Name (UPN) untuk otentikasi pengguna dengan konfigurasi keamanan yang menggunakan jenis server Active Directory.
## Pertimbangan untuk konfigurasi keamanan dengan LDAP dan Amazon EMR
+ Untuk membuat konfigurasi keamanan dengan integrasi Amazon EMR LDAP, Anda harus menggunakan enkripsi dalam perjalanan. Untuk informasi tentang enkripsi dalam perjalanan, lihat[Enkripsi data saat istirahat dan dalam perjalanan dengan Amazon EMR](emr-data-encryption.md).
+ Anda tidak dapat menentukan konfigurasi Kerberos dalam konfigurasi keamanan yang sama. Amazon EMR menyediakan KDC thar didedikasikan untuk secara otomatis, dan mengelola kata sandi admin untuk KDC ini. Pengguna tidak dapat mengakses kata sandi admin ini.
+ Anda tidak dapat menentukan peran runtime IAM dan AWS Lake Formation dalam konfigurasi keamanan yang sama.
+ `LDAPServerURL`Harus memiliki `ldaps://` protokol dalam nilainya.
+ Tidak `LDAPAccessFilter` bisa kosong.
## Gunakan LDAP dengan integrasi Apache Ranger untuk Amazon EMR
Dengan integrasi LDAP untuk Amazon EMR, Anda dapat lebih berintegrasi dengan Apache Ranger. Saat Anda menarik pengguna LDAP Anda ke Ranger, Anda kemudian dapat mengaitkan pengguna tersebut dengan server kebijakan Apache Ranger untuk diintegrasikan dengan Amazon EMR dan aplikasi lainnya. Untuk melakukan ini, tentukan `RangerConfiguration` bidang `AuthorizationConfiguration` dalam konfigurasi keamanan yang Anda gunakan dengan klaster LDAP Anda. Untuk informasi selengkapnya tentang cara mengatur konfigurasi keamanan, lihat[Buat konfigurasi keamanan EMR](emr-ranger-security-config.md).
Saat Anda menggunakan LDAP dengan Amazon EMR, Anda tidak perlu menyediakan `KerberosConfiguration` integrasi EMR Amazon untuk Apache Ranger.
# Luncurkan cluster EMR yang mengautentikasi dengan LDAP
Gunakan langkah-langkah berikut untuk meluncurkan cluster EMR dengan LDAP atau Active Directory.
1. Siapkan lingkungan Anda:
+ Pastikan node pada cluster EMR Anda dapat berkomunikasi dengan Amazon S3 dan. AWS Secrets Manager Untuk informasi selengkapnya tentang cara mengubah peran profil instans EC2 Anda untuk berkomunikasi dengan layanan ini, lihat[Tambahkan AWS Secrets Manager izin ke peran instans EMR Amazon](ldap-setup-asm.md).
+ Jika Anda berencana untuk menjalankan klaster EMR Anda di subnet pribadi, Anda harus menggunakan dan titik akhir AWS PrivateLink Amazon VPC, atau menggunakan transalasi alamat jaringan (NAT) untuk mengonfigurasi VPC agar berkomunikasi dengan S3 dan Secrets Manager. Untuk informasi selengkapnya, lihat [AWS PrivateLink dan titik akhir VPC](https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-services-overview.html) dan [instans NAT di Panduan Memulai](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html) *VPC Amazon*.
+ Pastikan ada konektivitas jaringan antara cluster EMR Anda dan server LDAP. Cluster EMR Anda harus mengakses server LDAP Anda melalui jaringan. Node utama, inti, dan tugas untuk cluster berkomunikasi dengan server LDAP untuk menyinkronkan data pengguna. Jika server LDAP Anda berjalan di Amazon EC2, perbarui grup keamanan EC2 untuk menerima lalu lintas dari kluster EMR. Untuk informasi selengkapnya, lihat [Tambahkan AWS Secrets Manager izin ke peran instans EMR Amazon](ldap-setup-asm.md).
1. Buat konfigurasi keamanan EMR Amazon untuk integrasi LDAP. Untuk informasi selengkapnya, lihat [Buat konfigurasi keamanan Amazon EMR untuk integrasi LDAP](ldap-setup-security.md).
1. Sekarang setelah Anda menyiapkan, gunakan langkah-langkah [Meluncurkan klaster Amazon EMR](emr-gs.md#emr-getting-started-launch-sample-cluster) untuk meluncurkan klaster Anda dengan konfigurasi berikut:
+ Pilih Amazon EMR rilis 6.12 atau lebih tinggi. Kami menyarankan Anda menggunakan rilis EMR Amazon terbaru.
+ Hanya tentukan atau pilih aplikasi untuk klaster Anda yang mendukung LDAP. Untuk daftar aplikasi yang didukung LDAP dengan Amazon EMR, lihat. [Dukungan aplikasi dan pertimbangan dengan LDAP untuk Amazon EMR](ldap-considerations.md)
+ Terapkan konfigurasi keamanan yang Anda buat di langkah sebelumnya.
# Contoh menggunakan LDAP dengan Amazon EMR
Setelah Anda [menyediakan kluster EMR yang menggunakan integrasi LDAP](ldap-setup-launch.md), Anda dapat memberikan kredensyal LDAP Anda ke [aplikasi apa pun yang didukung](ldap-considerations.md#ldap-considerations-apps) melalui mekanisme autentikasi nama pengguna dan kata sandi bawaannya. Halaman ini menunjukkan beberapa contoh.
## Menggunakan otentikasi LDAP dengan Apache Hive
**Example - Sarang Apache**
Contoh perintah berikut memulai sesi Apache Hive melalui HiveServer 2 dan Beeline:
```
beeline -u "jdbc:hive2://$HOSTNAME:10000/default;ssl=true;sslTrustStore=$TRUSTSTORE_PATH;trustStorePassword=$TRUSTSTORE_PASS" -n LDAP_USERNAME -p LDAP_PASSWORD
```
## Menggunakan otentikasi LDAP dengan Apache Livy
**Example - Apache Livy**
Contoh perintah berikut memulai sesi Livy melalui cURL. Ganti `ENCODED-KEYPAIR` dengan string yang dikodekan Base64 untuk. `username:password`
```
curl -X POST --data '{"proxyUser":"LDAP_USERNAME","kind": "pyspark"}' -H "Content-Type: application/json" -H "Authorization: Basic ENCODED-KEYPAIR" DNS_OF_PRIMARY_NODE:8998/sessions
```
## Menggunakan otentikasi LDAP dengan Presto
**Example - Presto**
Contoh perintah berikut memulai sesi Presto melalui CLI Presto:
```
presto-cli --user "LDAP_USERNAME" --password --catalog hive
```
Setelah Anda menjalankan perintah ini, masukkan kata sandi LDAP pada prompt.
## Menggunakan otentikasi LDAP dengan Trino
**Example - Trino**
Contoh perintah berikut memulai sesi Trino melalui Trino CLI:
```
trino-cli --user "LDAP_USERNAME" --password --catalog hive
```
Setelah Anda menjalankan perintah ini, masukkan kata sandi LDAP pada prompt.
## Menggunakan otentikasi LDAP dengan Hue
Anda dapat mengakses Hue UI melalui terowongan SSH yang Anda buat di cluster, atau Anda dapat mengatur server proxy untuk menyiarkan koneksi ke Hue secara publik. Karena Hue tidak berjalan dalam mode HTTPS secara default, kami menyarankan Anda menggunakan lapisan enkripsi tambahan untuk memastikan bahwa komunikasi antara klien dan UI Hue dienkripsi dengan HTTPS. Ini mengurangi kemungkinan Anda secara tidak sengaja mengekspos kredensyal pengguna dalam teks biasa.
Untuk menggunakan UI Hue, buka UI Hue di browser Anda dan masukkan kata sandi nama pengguna LDAP Anda untuk masuk. Jika kredensialnya benar, Hue mencatat Anda dan menggunakan identitas Anda untuk mengautentikasi Anda dengan semua aplikasi yang didukung.
## Menggunakan SSH untuk otentikasi kata sandi dan tiket Kerberos untuk aplikasi lain
**penting**
Kami tidak menyarankan Anda menggunakan otentikasi kata sandi ke SSH ke dalam cluster EMR.
Anda dapat menggunakan kredensyal LDAP Anda ke SSH ke cluster EMR. Untuk melakukan ini, atur `EnableSSHLogin` konfigurasi ke `true` dalam konfigurasi keamanan Amazon EMR yang Anda gunakan untuk memulai cluster. Kemudian, gunakan perintah berikut untuk SSH ke cluster setelah diluncurkan:
```
ssh username@EMR_PRIMARY_DNS_NAME
```
Setelah Anda menjalankan perintah ini, masukkan kata sandi LDAP pada prompt.
Amazon EMR menyertakan skrip on-cluster yang memungkinkan pengguna membuat file dan tiket keytab Kerberos untuk digunakan dengan aplikasi yang didukung yang tidak menerima kredensyal LDAP secara langsung. Beberapa aplikasi ini termasuk`spark-submit`, Spark SQL, dan. PySpark
Jalankan `ldap-kinit` dan ikuti petunjuknya. Jika otentikasi berhasil, file tab Kerberos muncul di direktori home Anda dengan tiket Kerberos yang valid. Gunakan tiket Kerberos untuk menjalankan aplikasi seperti yang Anda lakukan di lingkungan Kerberized apa pun.