Pilihan arsitektur Kerberos - Amazon EMR

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pilihan arsitektur Kerberos

Saat Anda menggunakan Kerberos dengan AmazonEMR, 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 khusus kluster yang kompatibel saat membuat klaster, dan Anda membuat HDFS direktori untuk pengguna Linux di cluster yang cocok dengan prinsip pengguna di. KDC Untuk penjelasan tentang opsi konfigurasi dan konfigurasi contoh untuk setiap arsitektur, lihat Mengonfigurasi Kerberos di Amazon EMR.

Cluster-dedicated KDC (KDCpada simpul utama)

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

Amazon EMRklaster architecture with master node, core nodes, and task node within a Kerberos realm.
Keuntungan
  • Amazon EMR memiliki kepemilikan penuh atasKDC.

  • KDCPada EMR cluster independen dari KDC implementasi terpusat seperti Microsoft Active Directory atau AWS Managed Microsoft AD.

  • Dampak kinerja minimal karena KDC mengelola otentikasi hanya untuk node lokal di dalam cluster.

  • Secara opsional, cluster Kerberized lainnya dapat merujuk sebagai eksternal. KDC KDC Untuk informasi selengkapnya, lihat Eksternal KDC —node primer pada cluster yang berbeda.

Pertimbangan dan batasan
  • Klaster kerberized tidak dapat mengautentikasi satu sama lain, sehingga aplikasi tidak dapat beroperasi. Jika aplikasi klaster perlu saling beroperasi, Anda harus membangun kepercayaan lintas alam antar kluster, atau menyiapkan satu cluster sebagai eksternal KDC untuk cluster lain. 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 prinsipal KDC pengguna, bersama dengan HDFS direktori untuk setiap pengguna.

  • Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster menggunakan. SSH

Kepercayaan lintas ranah

Dalam konfigurasi ini, prinsipal (biasanya pengguna) dari ranah Kerberos yang berbeda mengautentikasi ke komponen aplikasi pada cluster Kerberized, yang memiliki miliknya sendiriEMR. KDC KDCPada node primer membangun hubungan kepercayaan dengan yang lain KDC menggunakan prinsip lintas alam yang ada di keduanya. KDCs Nama utama dan kata sandi cocok persis di masing-masingKDC. Kepercayaan lintas ranah yang paling umum dengan implementasi Direktori Aktif, seperti yang ditunjukkan di diagram berikut. Perwalian lintas alam dengan eksternal MIT KDC atau KDC di EMR cluster Amazon lain juga didukung.

Amazon EMR clusters in different Kerberos realms with cross-realm trust to Active Directory.
Keuntungan
  • EMRCluster tempat KDC dipasang mempertahankan kepemilikan penuh atasKDC.

  • Dengan Active Directory, Amazon EMR secara otomatis membuat pengguna Linux yang sesuai dengan prinsipal pengguna dari file. KDC Anda masih harus membuat HDFS direktori 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 cluster KDC mengelola otentikasi untuk node di cluster, efek latensi jaringan dan overhead pemrosesan untuk sejumlah besar node di seluruh cluster 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 Cluster A dan Cluster B sama-sama membangun kepercayaan lintas alam dengan aKDC, mereka tidak secara inheren mempercayai satu sama lain dan aplikasi mereka tidak dapat mengautentikasi satu sama lain untuk saling beroperasi.

  • KDCsharus dijaga secara independen dan terkoordinasi sehingga kredensyal prinsipal pengguna cocok dengan tepat.

Eksternal KDC

Konfigurasi dengan Eksternal KDC didukung dengan Amazon EMR 5.20.0 dan yang lebih baru.

Eksternal KDC - MIT KDC

Konfigurasi ini memungkinkan satu atau lebih EMR cluster untuk menggunakan prinsipal yang didefinisikan dan dipelihara di server. MIT KDC

Amazon EMRklaster architecture with Kerberos realm, showing master, core, and task nodes.
Keuntungan
  • Prinsipal pengelola dikonsolidasikan dalam satu. KDC

  • Beberapa cluster dapat menggunakan hal yang sama KDC di ranah Kerberos yang sama. Untuk informasi selengkapnya, lihat Persyaratan untuk menggunakan beberapa cluster dengan yang sama KDC.

  • 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 prinsipal KDC pengguna, bersama dengan direktori untuk setiap pengguna. HDFS

  • Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster Kerberized menggunakan. SSH

  • Setiap node dalam EMR cluster Kerberized harus memiliki rute jaringan ke file. KDC

  • Setiap node dalam cluster Kerberized menempatkan beban otentikasi pada eksternalKDC, sehingga konfigurasi mempengaruhi kinerja cluster. KDC Saat Anda mengonfigurasi perangkat keras KDC server, pertimbangkan jumlah maksimum EMR node Amazon yang akan didukung secara bersamaan.

  • Kinerja cluster tergantung pada latensi jaringan antara node dalam cluster Kerberized dan. KDC

  • Pemecahan masalah bisa lebih sulit karena saling ketergantungan.

Eksternal KDC —node primer pada cluster yang berbeda

Konfigurasi ini hampir identik dengan MIT KDC implementasi eksternal di atas, kecuali bahwa KDC ada pada node utama dari sebuah EMR cluster. Untuk informasi selengkapnya, silakan lihat Cluster-dedicated KDC (KDCpada simpul utama) dan Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif.

Diagram of Amazon EMR clusters with Kerberos realm, showing master and core nodes.
Keuntungan
Pertimbangan dan batasan
  • Anda harus membuat pengguna Linux pada EC2 instance dari setiap node utama cluster Kerberized yang sesuai dengan prinsipal KDC pengguna, bersama dengan direktori untuk setiap pengguna. HDFS

  • Prinsipal pengguna harus menggunakan file kunci EC2 pribadi dan kinit kredensyal untuk terhubung ke cluster Kerberized menggunakan. SSH

  • Setiap node di setiap EMR cluster harus memiliki rute jaringan keKDC.

  • Setiap EMR node Amazon di cluster Kerberized menempatkan beban otentikasi pada eksternalKDC, sehingga konfigurasi mempengaruhi kinerja cluster. KDC Saat Anda mengonfigurasi perangkat keras KDC server, pertimbangkan jumlah maksimum EMR node Amazon yang akan didukung secara bersamaan.

  • Kinerja cluster tergantung pada latensi jaringan antara node dalam cluster dan. KDC

  • Pemecahan masalah bisa lebih sulit karena saling ketergantungan.

Eksternal KDC —cluster KDC pada cluster yang berbeda dengan kepercayaan lintas ranah Active Directory

Dalam konfigurasi ini, pertama-tama Anda membuat klaster dengan cluster khusus KDC yang memiliki kepercayaan lintas alam satu arah dengan Active Directory. Untuk tutorial detail, lihat Tutorial: Konfigurasi kepercayaan lintas ranah dengan domain Direktori Aktif. Anda kemudian meluncurkan cluster tambahan, merujuk cluster KDC yang memiliki kepercayaan sebagai eksternal. KDC Sebagai contoh, lihat Cluster eksternal KDC dengan kepercayaan lintas ranah Direktori Aktif. Ini memungkinkan setiap EMR klaster Amazon yang menggunakan eksternal KDC untuk mengautentikasi prinsipal yang ditentukan dan dipelihara dalam domain Microsoft Active Directory.

Amazon EMR clusters with Kerberos authentication and Active Directory integration diagram.
Keuntungan
  • Utama pengelola dikonsolidasikan di domain Direktori Aktif.

  • Amazon EMR bergabung dengan ranah Active Directory, yang menghilangkan kebutuhan untuk membuat pengguna Linux yang sesuai dengan pengguna Active Directory. Anda masih harus membuat HDFS direktori untuk setiap pengguna.

  • Beberapa cluster dapat menggunakan hal yang sama KDC di ranah Kerberos yang sama. Untuk informasi selengkapnya, lihat Persyaratan untuk menggunakan beberapa cluster dengan yang sama KDC.

  • 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 node EMR primer Amazon yang memiliki beban untuk mempertahankanKDC, dan hanya klaster itu yang harus dibuat dengan kredensyal Active Directory untuk kepercayaan lintas alam antara Direktori Aktif KDC dan Direktori Aktif.

Pertimbangan dan batasan
  • Setiap node di setiap EMR cluster harus memiliki rute jaringan ke KDC dan Active Directory domain controller.

  • Setiap EMR node Amazon menempatkan beban otentikasi pada eksternalKDC, sehingga konfigurasi KDC mempengaruhi kinerja cluster. Saat Anda mengonfigurasi perangkat keras KDC server, pertimbangkan jumlah maksimum EMR node Amazon yang akan didukung secara bersamaan.

  • Kinerja cluster tergantung pada latensi jaringan antara node di cluster dan server. KDC

  • Pemecahan masalah bisa lebih sulit karena saling ketergantungan.

Persyaratan untuk menggunakan beberapa cluster dengan yang sama KDC

Beberapa cluster dapat menggunakan hal yang sama KDC 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 eksternal yang samaKDC, maka pastikan bahwa cluster menggunakan alam Kerberos yang berbeda. Jika cluster harus menggunakan ranah Kerberos yang sama, maka pastikan bahwa cluster berada di subnet yang berbeda, dan rentangnya CIDR tidak tumpang tindih.