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.

KDC khusus cluster (KDC pada simpul utama)

Konfigurasi ini tersedia dengan Amazon EMR rilis 5.10.0 dan lebih tinggi.

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.

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 EC2 instance node utama yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.

• Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster 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.

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, prinsipal pengguna di domain Active Directory dapat mengakses cluster Kerberized menggunakan kinit kredensyal, tanpa file kunci pribadi. 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

• KDC eksternal — Node primer pada cluster yang berbeda

• KDC eksternal—KDC klaster di klaster yang berbeda dengan kepercayaan lintas ranah Direktori Aktif

KDC Eksternal—KDC MIT

Konfigurasi ini mengizinkan satu klaster EMR atau lebih untuk menggunakan utama didefinisikan dan dipelihara di server KDC MIT.

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.

• Node utama pada cluster Kerberized tidak memiliki beban kinerja yang terkait dengan pemeliharaan KDC.

Pertimbangan dan batasan

• Anda harus membuat pengguna Linux pada EC2 instance dari setiap node utama cluster Kerberized yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.

• Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster 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, silakan lihat KDC khusus cluster (KDC pada simpul utama) dan Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif.

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.

Pertimbangan dan batasan

• Anda harus membuat pengguna Linux pada EC2 instance dari setiap node utama cluster Kerberized yang sesuai dengan prinsip pengguna KDC, bersama dengan direktori HDFS untuk setiap pengguna.

• Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster 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. 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. Hal ini mengizinkan setiap klaster Amazon EMR yang menggunakan KDC eksternal untuk mengautentikasi kepala didefinisikan dan dipelihara di domain Direktori Aktif Microsoft.

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.

• Prinsipal pengguna di domain Active Directory dapat mengakses cluster Kerberized menggunakan kinit kredensyal, tanpa file kunci pribadi. 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.