Data lake Kerberized di Dataproc

Last reviewed 2024-04-16 UTC

Dokumen ini menjelaskan konsep, praktik terbaik, dan arsitektur referensi untuk jejaring, autentikasi, dan otorisasi data lake Kerberized di Google Cloud menggunakan Key Distribution Center (KDC) pada cluster Dataproc dan Apache Ranger. Dataproc adalah layanan Hadoop dan Spark yang dikelola Google Cloud. Dokumen ini ditujukan untuk administrator Apache Hadoop, arsitek cloud, dan tim big data yang memigrasikan cluster Hadoop dan Spark tradisional mereka ke data lake modern yang didukung oleh Dataproc.

Data lake Kerberized di Google Cloud membantu organisasi dengan deployment hybrid dan multi-cloud untuk memperluas dan menggunakan investasi IT mereka yang sudah ada dalam pengelolaan kontrol akses dan identitas.

Di Google Cloud, organisasi dapat menyediakan kepada tim mereka cluster efemeral dengan cakupan tugas sebanyak yang diperlukan. Pendekatan ini menghilangkan sebagian besar kompleksitas dalam mempertahankan satu cluster dengan dependensi dan interaksi konfigurasi software yang terus berkembang. Organisasi juga dapat membuat cluster yang berjalan lebih lama untuk diakses oleh beberapa pengguna dan layanan. Dokumen ini menunjukkan cara menggunakan alat standar industri, seperti Kerberos dan Apache Ranger, untuk membantu memastikan keamanan pengguna yang mendetail (autentikasi, otorisasi, dan audit) untuk kedua kasus cluster di Dataproc.

Kasus penggunaan pelanggan

Banyak perusahaan memigrasikan data lake berbasis Hadoop lokal ke platform cloud publik untuk mengatasi tantangan dalam mengelola cluster tradisional mereka.

Salah satu organisasi ini, pemimpin teknologi besar dalam Enterprise Software and Hardware, memutuskan untuk memigrasikan sistem Hadoop lokal mereka ke Google Cloud. Lingkungan Hadoop lokal mereka memenuhi kebutuhan analisis dari ratusan tim dan unit bisnis, termasuk tim pengamanan cyber mereka yang memiliki 200 anggota tim analisis data. Ketika salah satu anggota tim menjalankan kueri besar dengan data lake lama, mereka mengalami masalah karena sifat resource yang kaku. Organisasi ini kesulitan untuk memenuhi kebutuhan analisis tim menggunakan lingkungan lokal mereka, sehingga mereka beralih ke Google Cloud. Dengan beralih ke Google Cloud, organisasi ini dapat mengurangi jumlah masalah yang dilaporkan di data lake lokal sebesar 25% per bulan.

Fondasi rencana migrasi organisasi ke Google Cloud adalah keputusan untuk membentuk ulang dan mengoptimalkan cluster monolitik besar mereka sesuai dengan workload tim, dan mengalihkan fokus dari pengelolaan cluster ke membuka nilai bisnis. Beberapa cluster besar dipecah menjadi cluster Dataproc yang lebih kecil dan hemat biaya, sementara workload dan tim dimigrasikan ke jenis model berikut:

  • Cluster dengan cakupan tugas efemeral: Dengan waktu penyiapan yang hanya beberapa menit, model efemeral memungkinkan tugas atau alur kerja memiliki cluster khusus yang dimatikan setelah tugas selesai. Pola ini memisahkan penyimpanan dari node komputasi dengan mengganti Hadoop Distributed File System (HDFS) dengan Cloud Storage, menggunakan Konektor Cloud Storage untuk Hadoop, yang merupakan bawaan Dataproc.
  • Cluster yang berjalan semi lama: Jika cluster dengan cakupan tugas efemeral tidak dapat menangani kasus penggunaan, cluster Dataproc dapat berjalan lama. Jika data stateful cluster dialihkan ke Cloud Storage, cluster dapat dimatikan dengan mudah, dan dianggap berjalan semi lama. Penskalaan otomatis cluster pintar juga memungkinkan cluster ini untuk memulai dari yang kecil dan mengoptimalkan resource komputasinya untuk aplikasi tertentu. Penskalaan otomatis ini menggantikan pengelolaan antrean YARN.

Tantangan keamanan hybrid

Dalam skenario pelanggan sebelumnya, pelanggan memigrasikan sistem pengelolaan data yang substansial ke cloud. Namun, bagian lain dalam IT organisasi harus tetap berada di infrastruktur lokal (misalnya, beberapa sistem operasional lama yang memasukkan data ke data lake).

Arsitektur keamanan yang diperlukan untuk membantu memastikan penyedia identitas (IdP) berbasis LDAP lokal tetap menjadi sumber otoritatif untuk identitas perusahaan mereka menggunakan data lake. Keamanan Hadoop lokal didasarkan pada Kerberos dan LDAP untuk autentikasi (sering kali merupakan bagian dari Microsoft Active Directory (AD) organisasi) serta beberapa produk software open source (OSS) lainnya, seperti Apache Ranger. Pendekatan keamanan ini memungkinkan otorisasi dan audit terperinci terhadap aktivitas pengguna dan aktivitas tim di cluster data lake. Di Google Cloud, Identity and Access Management (IAM) digunakan untuk mengelola akses ke resource Google Cloud tertentu, seperti Dataproc dan Cloud Storage.

Dokumen ini membahas pendekatan keamanan yang menggunakan keamanan lokal dan OSS Hadoop terbaik (yang berfokus pada Kerberos, LDAP perusahaan, dan Apache Ranger) beserta IAM untuk membantu mengamankan workload dan data baik di dalam maupun di luar cluster Hadoop.

Arsitektur

Diagram berikut menunjukkan arsitektur tingkat tinggi:

Arsitektur tingkat tinggi data lake Kerberized di Google Cloud menggunakan Dataproc.

Pada diagram sebelumnya, klien menjalankan tugas di cluster multi-tim atau satu tim. Cluster menggunakan metastore Hive pusat dan autentikasi Kerberos dengan penyedia identitas perusahaan.

Komponen

Arsitektur ini mengusulkan kombinasi alat open source standar industri dan IAM untuk mengautentikasi dan memberikan otorisasi ke berbagai cara untuk mengirim tugas yang akan dijelaskan nanti dalam dokumen ini. Berikut adalah komponen utama yang bekerja sama untuk memberikan keamanan terperinci untuk workload tim dan pengguna di cluster Hadoop:

  • Kerberos: Kerberos adalah protokol autentikasi jaringan yang menggunakan kriptografi kunci rahasia untuk memberikan autentikasi yang kuat bagi aplikasi klien/server. Server Kerberos dikenal sebagai Key Distribution Center (KDC).

    Kerberos banyak digunakan dalam sistem lokal seperti AD untuk mengautentikasi pengguna manusia, layanan, dan mesin (entity klien dilambangkan sebagai akun utama pengguna). Mengaktifkan Kerberos di Dataproc menggunakan Distribusi MIT Kerberos gratis untuk membuat KDC di cluster. KDC on-cluster Dataproc melayani permintaan akun utama pengguna untuk mengakses resource di dalam cluster, seperti Apache Hadoop YARN, HDFS, dan Apache Spark (resource server dilambangkan sebagai akun utama layanan). Kepercayaan lintas realm Kerberos memungkinkan Anda menghubungkan akun utama pengguna dari satu realm ke realm lain.

  • Apache Ranger: Apache Ranger memberikan otorisasi terperinci bagi pengguna untuk melakukan tindakan tertentu pada layanan Hadoop. Apache Ranger juga mengaudit akses pengguna dan menerapkan tindakan administratif. Ranger dapat menyinkronkan dengan server LDAP perusahaan lokal atau dengan AD untuk mendapatkan identitas pengguna dan layanan.

  • Metastore Hive Bersama: Metastore Hive adalah layanan yang menyimpan metadata untuk Apache Hive dan alat Hadoop lainnya. Karena banyak alat ini yang dibuat berdasarkan hal tersebut, metastore Hive telah menjadi komponen penting dari banyak data lake. Dalam arsitektur yang diusulkan, metastore Hive yang terpusat dan Kerber memungkinkan beberapa cluster untuk berbagi metadata dengan cara yang aman.

Meskipun Kerberos, Ranger, dan metastore Hive bersama bekerja sama untuk memungkinkan keamanan pengguna terperinci dalam cluster Hadoop, IAM mengontrol akses ke resource Google Cloud. Misalnya, Dataproc menggunakan Akun Layanan Dataproc untuk melakukan pembacaan dan penulisan di bucket Cloud Storage.

Dimensi cluster

Dimensi berikut menunjukkan ciri cluster Dataproc:

  • Tenancy: Cluster bersifat multi-tenant jika melayani permintaan dari lebih dari satu pengguna manusia atau layanan, atau tenant tunggal jika melayani permintaan dari satu pengguna atau layanan.
  • Kerberos: Cluster dapat bersifat Kerberized jika Anda mengaktifkan Kerberos di Dataproc atau non-Kerberized jika Anda tidak mengaktifkan Kerberos di Dataproc.
  • Siklus proses: Cluster bersifat efemeral jika dibuat hanya untuk durasi tugas atau alur kerja tertentu, hanya berisi resource yang diperlukan untuk menjalankan tugas tersebut, dan dimatikan setelah tugas selesai. Jika tidak, cluster akan dianggap berjalan semi lama.

Kombinasi berbagai dimensi ini menentukan kasus penggunaan yang paling sesuai untuk cluster tertentu. Dokumen ini membahas contoh representatif berikut:

  1. Contoh cluster multi-tim yang ditampilkan dalam arsitektur adalah cluster Kerberized, multi-tenant, dan berjalan semi lama. Cluster ini sangat cocok untuk workload kueri interaktif. Misalnya, cluster ini menyajikan analisis data jangka panjang dan eksplorasi business intelligence (BI). Dalam arsitektur ini, cluster tersebut berada dalam project Google Cloud yang digunakan bersama oleh beberapa tim dan melayani permintaan tim tersebut, dan oleh karena itu namanya demikian.

    Dalam dokumen ini, istilah tim atau tim aplikasi menjelaskan sekelompok orang dalam organisasi yang bekerja pada komponen software yang sama atau bertindak sebagai satu tim fungsional. Misalnya, sebuah tim mungkin merujuk pada developer backend dari microservice, analis BI aplikasi bisnis, atau bahkan tim lintas fungsi, seperti tim infrastruktur Big Data.

  2. Contoh cluster satu tim yang ditampilkan dalam arsitektur adalah cluster yang dapat berupa multi-tenant (untuk anggota tim yang sama) atau tenant tunggal.

  • Sebagai cluster efemeral, cluster satu tim dapat digunakan untuk tugas-tugas seperti yang dilakukan oleh Data Engineer untuk menjalankan tugas batch processing Spark, atau oleh Data Scientist untuk tugas pelatihan model.

  • Sebagai cluster yang berjalan semi lama, cluster satu tim dapat menyajikan analisis data dan workload BI yang menjadi lingkup untuk satu tim atau orang.

    Cluster satu tim berada di project Google Cloud yang merupakan milik satu tim, sehingga menyederhanakan audit penggunaan, penagihan, dan isolasi resource. Misalnya, hanya anggota satu tim yang dapat mengakses bucket Cloud Storage yang digunakan untuk mempertahankan data cluster. Dalam pendekatan ini, tim aplikasi memiliki project khusus, sehingga cluster satu tim tidak bersifat Kerberized.

Sebaiknya analisis persyaratan khusus Anda dan pilih kombinasi dimensi terbaik untuk situasi Anda.

Mengirimkan tugas

Pengguna dapat mengirimkan tugas ke kedua jenis cluster menggunakan berbagai alat, termasuk:

  • Dataproc API, menggunakan panggilan REST atau library klien.
  • Alat command line gcloud Google Cloud CLI di jendela terminal lokal atau dari konsol Google Cloud di Cloud Shell, yang dibuka di browser lokal.
  • Template Alur Kerja Dataflow, yang merupakan konfigurasi alur kerja yang dapat digunakan kembali dan menentukan grafik tugas dengan informasi tentang tempat untuk menjalankan tugas tersebut. Jika alur kerja menggunakan opsi cluster terkelola, alur kerja tersebut akan menggunakan cluster efemeral.
  • Cloud Composer yang menggunakan Operator Dataproc. Directed acyclic graph (DAG) Composer juga dapat digunakan untuk mengorkestrasi Template Alur Kerja Dataproc.
  • Membuka sesi SSH ke node master di cluster, dan mengirimkan tugas secara langsung, atau dengan menggunakan alat seperti Apache Beeline. Alat ini biasanya hanya disediakan untuk administrator dan pengguna super. Contoh pengguna super adalah developer yang ingin memecahkan masalah parameter konfigurasi untuk layanan dan memverifikasinya dengan menjalankan tugas pengujian secara langsung pada node master.

Jaringan

Diagram berikut menyoroti konsep jejaring dalam arsitektur:

Arsitektur jejaring menggunakan pola mesh hybrid.

Dalam diagram sebelumnya, arsitektur jejaring menggunakan pola hybrid mesh, tempat beberapa resource berada di Google Cloud, dan sebagian lagi berada di infrastruktur lokal. Pola hybrid mesh menggunakan VPC Bersama, dengan project host umum dan project terpisah untuk setiap jenis dan tim cluster Dataproc. Arsitektur ini dijelaskan secara mendetail di bagian Di Google Cloud dan Lokal berikut.

Di Google Cloud

Di Google Cloud, arsitektur ini disusun menggunakan VPC Bersama. VPC Bersama memungkinkan resource dari beberapa project terhubung ke jaringan VPC umum. Penggunaan jaringan VPC umum memungkinkan resource saling berkomunikasi secara aman dan efisien menggunakan alamat IP internal dari jaringan tersebut. Untuk menyiapkan VPC Bersama, Anda harus membuat project berikut:

  • Project host: Project host berisi satu atau beberapa Jaringan VPC Bersama yang digunakan oleh semua project layanan.

  • Project layanan: project layanan berisi resource Google Cloud terkait. Admin VPC Bersama memasang project layanan ke Project Host agar dapat menggunakan subnet dan resource di jaringan VPC Bersama. Pemasangan ini sangat penting agar cluster satu tim dapat mengakses metastore Hive terpusat.

    Seperti yang ditampilkan dalam diagram Networking, sebaiknya buat project layanan terpisah untuk cluster metastore Hive, cluster multi-tim, dan cluster untuk setiap tim individual. Anggota setiap tim di organisasi Anda kemudian dapat membuat cluster satu tim dalam project mereka masing-masing.

Agar komponen dalam jaringan hybrid dapat berkomunikasi, Anda harus mengonfigurasi aturan firewall untuk mengizinkan traffic berikut:

  • Traffic cluster internal bagi layanan Hadoop termasuk HDFS NameNode untuk berkomunikasi dengan HDFS DataNodes, dan bagi YARN ResourceManager untuk berkomunikasi dengan YARN NodeManagers. Sebaiknya gunakan pemfilteran dengan akun layanan cluster untuk aturan ini.
  • Traffic cluster eksternal di port tertentu untuk berkomunikasi dengan metastore Hive (port tcp:9083,8020), KDC lokal (port tcp:88), dan LDAP (port 636), dan layanan eksternal terpusat lainnya yang Anda gunakan dalam skenario khusus Anda, misalnya Kafka di Google Kubernetes Engine (GKE).

Semua cluster Dataproc dalam arsitektur ini dibuat hanya dengan alamat IP internal. Agar node cluster dapat mengakses Google API dan layanan Google, Anda harus mengaktifkan Akses Google Pribadi untuk subnet cluster. Agar administrator dan pengguna super dapat mengakses instance VM alamat IP pribadi, gunakan penerusan IAP TCP untuk meneruskan SSH, RDP, dan traffic lainnya melalui tunnel terenkripsi.

Antarmuka web cluster dari aplikasi cluster dan komponen opsional (misalnya Spark, Hadoop, Jupyter, dan Zeppelin) akan diakses dengan aman melalui Gateway Komponen Dataproc. Gateway Komponen Dataproc adalah proxy pembalik HTTP yang didasarkan pada Apache Knox.

Lokal

Dokumen ini mengasumsikan bahwa resource yang terletak di infrastruktur lokal adalah layanan direktori LDAP perusahaan dan Kerberos Key Distribution Center (KDC) perusahaan tempat akun utama layanan pengguna dan tim ditentukan. Jika tidak perlu menggunakan penyedia identitas lokal, Anda dapat menyederhanakan penyiapannya menggunakan Cloud Identity dan KDC pada cluster Dataproc atau di virtual machine.

Untuk berkomunikasi dengan LDAP dan KDC lokal, Anda dapat menggunakan Cloud Interconnect atau Cloud VPN. Penyiapan ini membantu memastikan bahwa komunikasi antarlingkungan menggunakan alamat IP pribadi jika subnetwork di alamat IP RFC 1918 tidak tumpang-tindih. Untuk mengetahui informasi selengkapnya tentang berbagai opsi koneksi, lihat Memilih produk Network Connectivity.

Dalam skenario hybrid, permintaan autentikasi Anda harus ditangani dengan latensi minimal. Untuk mencapai tujuan ini, Anda dapat menggunakan teknik berikut:

  • Melayani semua permintaan autentikasi untuk identitas layanan dari KDC pada cluster, dan hanya menggunakan penyedia identitas di luar cluster untuk identitas pengguna. Sebagian besar traffic autentikasi diperkirakan merupakan permintaan dari identitas layanan.
  • Jika Anda menggunakan AD sebagai penyedia identitas, Nama Akun Utama Pengguna (UPN) mewakili pengguna manusia dan akun layanan AD. Sebaiknya Anda mereplikasi UPN dari AD lokal ke region Google Cloud yang dekat dengan cluster data lake Anda. Replika AD ini menangani permintaan autentikasi untuk UPN, sehingga permintaan tidak pernah transit ke AD lokal Anda. Setiap KDC pada cluster menangani Nama Akun Utama Layanan (SPN) menggunakan teknik pertama.

Diagram berikut menunjukkan arsitektur yang menggunakan kedua teknik tersebut:

AD lokal menyinkronkan UPN ke replika AD, sedangkan KDC pada cluster mengautentikasi UPN dan SPN.

Dalam diagram sebelumnya, AD lokal menyinkronkan UPN ke replika AD di region Google Cloud. Replika AD mengautentikasi UPN, dan KDC pada cluster mengautentikasi SPN.

Untuk informasi tentang cara men-deploy AD di Google Cloud, lihat Men-deploy lingkungan Microsoft Active Directory yang fault-tolerant. Untuk informasi tentang cara mengukur jumlah instance untuk pengontrol domain, lihat Mengintegrasikan MIT Kerberos dan Active Directory.

Autentikasi

Diagram berikut menunjukkan komponen yang digunakan untuk mengautentikasi pengguna di berbagai cluster Hadoop. Dengan autentikasi, pengguna dapat menggunakan layanan seperti Apache Hive atau Apache Spark.

Komponen mengautentikasi pengguna di berbagai cluster Hadoop.

Dalam diagram sebelumnya, cluster di realm Kerberos dapat menyiapkan kepercayaan lintas realm untuk menggunakan layanan di cluster lain, seperti metastore Hive. Cluster yang bersifat non-kerberized dapat menggunakan klien Kerberos dan keytab akun untuk menggunakan layanan di cluster lain.

Metastore Hive yang dibagikan dan diamankan

Metastore Hive terpusat memungkinkan beberapa cluster yang menjalankan berbagai mesin kueri open source—seperti Apache Spark, Apache Hive/Beeline, dan Presto—untuk berbagi metadata.

Anda men-deploy server metastore Hive di cluster Dataproc Kerberized dan men-deploy database metastore Hive pada RDBMS jarak jauh, seperti instance MySQL di Cloud SQL. Sebagai layanan bersama, cluster metastore Hive hanya melayani permintaan yang diautentikasi. Untuk informasi selengkapnya tentang cara mengonfigurasi metastore Hive, lihat Menggunakan Apache Hive di Dataproc.

Sebagai ganti metastore Hive, Anda dapat menggunakan Metastore Dataproc, yang merupakan metastore Apache Hive yang terkelola sepenuhnya, sangat tersedia (dalam suatu region), autohealing, serverless. Anda juga dapat mengaktifkan Kerberos untuk layanan Dataproc Metastore, seperti yang dijelaskan di Mengonfigurasi Kerberos untuk layanan.

Kerberos

Dalam arsitektur ini, cluster multi-tim digunakan untuk tujuan analisis dan bersifat Kerberized dengan mengikuti panduan untuk Konfigurasi keamanan Dataproc. Mode aman Dataproc membuat KDC pada cluster dan mengelola keytab dan akun utama layanan cluster seperti yang diwajibkan oleh spesifikasi mode aman Hadoop.

Keytab adalah file yang berisi satu atau beberapa pasangan akun utama Kerberos dan salinan terenkripsi dari kunci akun utama tersebut. Keytab memungkinkan autentikasi Kerberos terprogram jika login interaktif dengan perintah kinit tidak memungkinkan.

Akses ke keytab berarti kemampuan untuk meniru identitas akun utama yang ada di dalamnya. Oleh karena itu, keytab adalah file yang sangat sensitif yang perlu ditransfer dan disimpan dengan aman. Sebaiknya gunakan Secret Manager untuk menyimpan konten keytab sebelum ditransfer ke cluster masing-masing. Untuk contoh cara menyimpan konten keytab, lihat Mengonfigurasi Kerberos untuk layanan. Setelah keytab didownload ke node master cluster, file harus memiliki izin akses file yang dibatasi.

KDC pada cluster menangani permintaan autentikasi untuk semua layanan dalam cluster tersebut. Sebagian besar permintaan autentikasi diperkirakan merupakan jenis permintaan ini. Untuk meminimalkan latensi, penting bagi KDC untuk menyelesaikan permintaan tersebut tanpa membiarkan permintaan tersebut keluar dari cluster.

Permintaan yang tersisa berasal dari pengguna manusia dan akun layanan AD. Replika AD di Google Cloud atau penyedia ID pusat lokal menangani permintaan ini, seperti yang dijelaskan di bagian Lokal sebelumnya.

Dalam arsitektur ini, cluster satu tim tidak bersifat Kerberized, sehingga tidak ada KDC. Agar cluster ini dapat mengakses metastore Hive bersama, Anda hanya perlu menginstal klien Kerberos. Untuk mengotomatiskan akses, Anda dapat menggunakan keytab tim. Untuk mengetahui informasi selengkapnya, lihat bagian Pemetaan identitas nanti dalam dokumen ini.

Kepercayaan lintas realm Kerberos dalam cluster multi-tim

Kepercayaan lintas realm sangat relevan saat workload Anda bersifat hybrid atau multi-cloud. Kepercayaan lintas realm memungkinkan Anda mengintegrasikan identitas perusahaan pusat ke dalam layanan bersama yang tersedia di data lake Google Cloud Anda.

Di Kerberos, realm menentukan grup sistem di bawah KDC umum. Autentikasi lintas realm memungkinkan akun utama pengguna dari satu realm melakukan autentikasi di realm lain dan menggunakan layanannya. Konfigurasi ini mengharuskan Anda untuk membangun kepercayaan antar-realm.

Dalam arsitektur, ada tiga realm:

  • EXAMPLE.COM: adalah realm perusahaan, tempat semua akun utama pengguna Kerberos untuk pengguna, tim, dan layanan ditentukan (UPN).
  • MULTI.EXAMPLE.COM: adalah realm yang berisi cluster multi-tim. Cluster telah dikonfigurasi sebelumnya dengan akun utama layanan (SPN) untuk layanan Hadoop, seperti Apache Spark dan Apache Hive.
  • METASTORE.EXAMPLE.COM: adalah realm untuk metastore Hive.

Cluster satu tim tidak bersifat Kerberized, jadi tidak termasuk dalam realm.

Agar dapat menggunakan akun utama pengguna perusahaan di semua cluster, Anda menetapkan kepercayaan lintas realm searah berikut:

  • Konfigurasi realm multi-tim dan realm metastore untuk memercayai realm perusahaan. Dengan konfigurasi ini, akun utama yang ditentukan dalam realm perusahaan dapat mengakses cluster multi-tim dan metastore.

    Meskipun kepercayaan dapat bersifat transitif, sebaiknya Anda mengonfigurasi realm metastore agar memiliki kepercayaan langsung ke realm perusahaan. Konfigurasi ini menghindari ketergantungan pada ketersediaan realm multi-tim.

  • Konfigurasikan realm metastore untuk memercayai realm multi-tim sehingga cluster multi-tim dapat mengakses metastore. Konfigurasi ini diperlukan untuk mengizinkan akses akun utama HiveServer2 ke metastore.

Untuk informasi lebih lanjut, baca artikel Mulai menggunakan cluster dataproc Kerberized dengan kepercayaan lintas realm, dan file konfigurasi Terraform yang sesuai di repositori GitHub.

Jika Anda lebih memilih pendekatan IAM bawaan, atau berbasis cloud, ketimbang cluster multi-tim dan jika Anda tidak memerlukan pengelolaan identitas hybrid, pertimbangkan untuk menggunakan Multi-tenancy yang aman dan berbasis akun layanan Dataproc. Dalam cluster ini, beberapa identitas IAM dapat mengakses Cloud Storage dan resource Google lainnya sebagai akun layanan yang berbeda.

Pemetaan identitas di cluster satu tim

Bagian sebelumnya menjelaskan konfigurasi sisi Kerberized dari arsitektur. Namun, cluster satu tim tidak bersifat Kerberized, sehingga memerlukan teknik khusus agar dapat berpartisipasi dalam ekosistem ini. Teknik ini menggunakan properti pemisahan project Google Cloud dan akun layanan IAM untuk mengisolasi dan membantu mengamankan workload Hadoop tim aplikasi.

Seperti yang dijelaskan di bagian Networking sebelumnya, setiap tim memiliki project Google Cloud yang sesuai, yang memungkinkan pembuatan cluster satu tim. Dalam cluster satu tim, satu atau beberapa anggota tim adalah tenant cluster. Metode pemisahan berdasarkan project ini juga membatasi akses ke bucket Cloud Storage (digunakan oleh cluster ini) untuk masing-masing tim.

Administrator membuat project layanan dan menyediakan akun layanan tim dalam project tersebut. Saat membuat cluster, akun layanan ini ditetapkan sebagai akun layanan cluster.

Administrator juga membuat akun utama Kerberos untuk tim di realm perusahaan, dan membuat keytab yang sesuai. Keytab disimpan dengan aman di Secret Manager dan administrator akan menyalin keytab ke node master cluster. Prinsip utama Kerberos memungkinkan akses dari cluster satu tim ke metastore Hive.

Untuk memfasilitasi penyediaan otomatis dan mengenali pasangan identitas terkait ini dengan mudah, identitas harus mengikuti konvensi penamaan yang umum, misalnya:

  • Akun layanan tim: revenue-reporting-app@proj-A.iam.gserviceaccount.com
  • Akun utama tim Kerberos: revenue_reporting/app@EXAMPLE.COM

Teknik pemetaan identitas ini menawarkan pendekatan unik untuk memetakan identitas Kerberos ke akun layanan, keduanya milik tim yang sama.

Identitas ini digunakan dengan berbagai cara:

  • Identitas Kerberos memberi cluster akses ke resource Hadoop bersama, seperti metastore Hive.
  • Akun layanan memberi cluster akses ke resource Google Cloud bersama, seperti Cloud Storage.

Dengan teknik ini, Anda tidak perlu membuat pemetaan serupa untuk setiap anggota tim. Namun, karena teknik ini menggunakan satu akun layanan atau satu akun utama Kerberos untuk seluruh tim, tindakan di cluster Hadoop tidak dapat dilacak ke setiap anggota tim.

Untuk mengelola akses ke resource cloud dalam project tim yang berada di luar cakupan cluster Hadoop (seperti bucket Cloud Storage, layanan terkelola, dan VM), administrator menambahkan anggota tim ke grup Google. Administrator dapat menggunakan grup Google untuk mengelola izin IAM bagi seluruh tim untuk mengakses resource cloud.

Saat memberikan izin IAM ke grup dan bukan kepada anggota tim tertentu, Anda akan menyederhanakan pengelolaan akses pengguna saat anggota bergabung atau keluar dari tim aplikasi. Dengan memberikan izin IAM langsung ke grup Google tim, Anda dapat menonaktifkan peniruan identitas ke akun layanan, yang membantu menyederhanakan keterlacakan tindakan di Cloud Audit Logs. Saat menentukan anggota tim, sebaiknya Anda menyeimbangkan tingkat perincian yang diperlukan untuk pengelolaan akses, penggunaan resource, dan pengauditan terhadap upaya administratif yang berasal dari tugas tersebut.

Jika sebuah cluster hanya melayani satu pengguna manusia (cluster satu tenant), dan bukan tim, pertimbangkan untuk menggunakan Autentikasi Cluster Pribadi Dataproc. Cluster yang mengaktifkan Autentikasi Cluster Pribadi hanya ditujukan untuk workload interaktif jangka pendek agar dapat dijalankan dengan aman sebagai satu identitas pengguna akhir. Cluster ini menggunakan kredensial pengguna akhir IAM untuk berinteraksi dengan resource Google Cloud lainnya, seperti Cloud Storage. Cluster melakukan autentikasi sebagai pengguna akhir, bukan mengautentikasi sebagai akun layanan cluster. Dalam jenis cluster ini, Kerberos otomatis diaktifkan dan dikonfigurasi untuk komunikasi yang aman dalam cluster pribadi.

Alur autentikasi

Untuk menjalankan tugas di cluster Dataproc, pengguna memiliki banyak opsi, seperti yang dijelaskan di bagian Mengirimkan tugas sebelumnya. Dalam semua kasus, akun pengguna atau akun layanan mereka harus memiliki akses ke cluster.

Saat pengguna menjalankan tugas di cluster multi-tim, ada dua pilihan untuk akun utama Kerberos, seperti yang ditunjukkan pada diagram berikut:

Kerberos dan identitas cloud digunakan dengan cluster multi-tim.

Diagram sebelumnya menunjukkan opsi berikut:

  1. Jika pengguna menggunakan alat Google Cloud, seperti Dataproc API, Cloud Composer, atau alat command line gcloud, untuk mengirimkan permintaan tugas, cluster akan menggunakan akun utama Kerberos Dataproc untuk mengautentikasi dengan KDC dan mengakses metastore Hive.
  2. Jika pengguna menjalankan tugas dari sesi SSH, mereka dapat mengirim tugas secara langsung di sesi tersebut menggunakan akun utama Kerberos pengguna mereka sendiri.

Saat pengguna menjalankan tugas pada cluster satu tim, hanya ada satu akun utama Kerberos yang memungkinkan—akun utama Kerberos tim—seperti yang ditunjukkan dalam diagram berikut:

Kerberos dan identitas cloud digunakan dengan cluster satu tim.

Dalam diagram sebelumnya, tugas menggunakan akun utama Kerberos tim saat tugas memerlukan akses ke metastore Hive bersama. Jika tidak, karena cluster satu tim bersifat non-Kerberized, pengguna dapat memulai tugas menggunakan akun pengguna mereka sendiri.

Untuk cluster satu tim, sebaiknya jalankan kinit untuk akun utama tim sebagai bagian dari tindakan inisialisasi pada saat pembuatan cluster. Setelah pembuatan cluster, gunakan jadwal cron sesuai dengan masa berlaku tiket yang ditentukan, menggunakan opsi perintah masa aktif (-l). Untuk menjalankan kinit, tindakan inisialisasi akan terlebih dahulu mendownload keytab ke node master cluster.

Untuk tujuan keamanan, Anda harus membatasi akses ke keytab. Berikan izin baca POSIX hanya ke akun yang menjalankan kinit. Jika memungkinkan, hapus keytab dan perpanjang token menggunakan kinit -R untuk memperpanjang masa aktifnya menggunakan tugas cron hingga memenuhi masa berlaku tiket maksimum. Pada saat itu, tugas cron dapat mendownload ulang keytab, menjalankan kembali kinit, dan memulai ulang siklus perpanjangan.

Baik jenis cluster multi-tim maupun satu tim menggunakan akun layanan untuk mengakses resource Google Cloud lainnya, seperti Cloud Storage. Cluster satu tim menggunakan akun layanan tim sebagai akun layanan cluster kustom.

Otorisasi

Bagian ini menjelaskan mekanisme otorisasi global dan terperinci untuk setiap cluster, seperti yang ditunjukkan dalam diagram berikut:

Arsitektur otorisasi menggunakan IAM untuk otorisasi global, dan Apache Ranger untuk otorisasi terperinci.

Arsitektur dalam diagram sebelumnya menggunakan IAM untuk otorisasi global, dan Apache Ranger untuk otorisasi terperinci. Metode otorisasi ini dijelaskan di bagian berikut: Otorisasi global dan Otorisasi terperinci.

Otorisasi global

IAM memungkinkan Anda mengontrol akses pengguna dan grup ke resource project. IAM menentukan izin, dan peran yang memberikan izin tersebut.

Ada empat peran Dataproc bawaan: admin, editor, pelihat, dan worker. Peran ini memberikan izin Dataproc yang memungkinkan pengguna dan akun layanan melakukan tindakan tertentu pada cluster, tugas, operasi, dan template alur kerja. Peran tersebut memberikan akses ke resource Google Cloud yang mereka butuhkan untuk menyelesaikan tugas. Salah satu resource tersebut adalah Cloud Storage, yang sebaiknya digunakan sebagai lapisan penyimpanan cluster, bukan HDFS.

Tingkat perincian izin Dataproc IAM tidak meluas ke tingkat layanan yang berjalan di setiap cluster, seperti Apache Hive atau Apache Spark. Misalnya, Anda dapat mengizinkan akun tertentu untuk mengakses data dari bucket Cloud Storage atau untuk menjalankan tugas. Namun, Anda tidak dapat menentukan kolom Hive mana yang diizinkan untuk diakses oleh akun dengan tugas tersebut. Bagian berikutnya menjelaskan cara menerapkan otorisasi terperinci semacam itu di cluster Anda.

Otorisasi terperinci

Untuk mengizinkan akses terperinci, gunakan komponen opsional Dataproc Ranger dalam arsitektur yang dijelaskan dalam Praktik terbaik untuk menggunakan Apache Ranger di Dataproc. Dalam arsitektur tersebut, Apache Ranger diinstal di setiap cluster Anda, baik satu tim maupun multi-tim. Apache Ranger memberikan kontrol akses terperinci untuk aplikasi Hadoop Anda (otorisasi dan audit) di tingkat layanan, tabel, atau kolom.

Apache Ranger menggunakan identitas yang disediakan oleh repositori LDAP perusahaan dan ditetapkan sebagai akun utama Kerberos. Dalam cluster multi-tim, daemon Ranger UserSync secara berkala memperbarui identitas Kerberized dari server LDAP perusahaan. Dalam cluster satu tim, hanya identitas tim yang diperlukan.

Cluster efemeral menimbulkan tantangan karena mereka dimatikan setelah tugasnya selesai, tetapi tidak boleh kehilangan kebijakan Ranger dan log admin mereka. Untuk mengatasi tantangan ini, Anda perlu mengeksternalkan kebijakan ke database Cloud SQL terpusat dan mengeksternalkan log audit ke folder Cloud Storage. Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk menggunakan Apache Ranger di Dataproc.

Alur otorisasi

Jika pengguna ingin mengakses satu atau beberapa layanan cluster untuk memproses data, permintaan akan melalui alur berikut:

  1. Pengguna melakukan autentikasi melalui salah satu opsi yang dijelaskan di bagian Alur autentikasi.
  2. Layanan target menerima permintaan pengguna dan memanggil plugin Apache Ranger yang sesuai.
  3. Plugin ini secara berkala mengambil kebijakan dari Server Kebijakan Ranger. Kebijakan ini menentukan apakah identitas pengguna diizinkan untuk melakukan tindakan yang diminta pada layanan tertentu. Jika identitas pengguna diizinkan untuk melakukan tindakan, plugin akan mengizinkan layanan untuk memproses permintaan dan pengguna akan mendapatkan hasilnya.
  4. Setiap interaksi pengguna dengan layanan Hadoop, baik diizinkan atau ditolak, ditulis ke log Ranger oleh Server Audit Ranger. Setiap cluster memiliki folder log-nya sendiri di Cloud Storage. Dataproc juga menulis log tugas dan cluster yang dapat Anda lihat, telusuri, filter, dan arsipkan di Cloud Logging.

Dalam dokumen ini, arsitektur referensi menggunakan dua jenis cluster Dataproc: cluster multi-tim dan cluster satu tim. Melalui penggunaan beberapa cluster Dataproc yang dapat dengan mudah disediakan dan diamankan, organisasi dapat menggunakan pendekatan yang berfokus pada tugas, produk, atau domain, bukan cluster terpusat yang tradisional. Pendekatan ini cocok dengan keseluruhan arsitektur Mesh Data, yang memungkinkan tim memiliki dan mengamankan data lake mereka sepenuhnya beserta workload-nya, serta menawarkan data sebagai layanan.

Langkah selanjutnya