Cara Mengotomatiskan Orkestrasi Hak Akses Dalam AWS S3 Bucket

Bertahun-tahun yang lalu, ketika server Unix di tempat dengan sistem file besar adalah suatu hal, perusahaan membangun aturan dan strategi manajemen folder yang ekstensif untuk mengelola hak akses ke folder yang berbeda untuk orang yang berbeda.

Biasanya, platform organisasi melayani kelompok pengguna yang berbeda dengan minat, batasan tingkat kerahasiaan, atau definisi konten yang benar-benar berbeda. Dalam kasus organisasi global, ini bahkan bisa berarti memisahkan konten berdasarkan lokasi, jadi pada dasarnya, antara pengguna yang berasal dari negara yang berbeda.

Contoh tipikal lebih lanjut mungkin termasuk:

• pemisahan data antara lingkungan pengembangan, pengujian, dan produksi
• konten penjualan tidak dapat diakses oleh khalayak luas
• konten legislatif khusus negara yang tidak dapat dilihat atau diakses dari dalam wilayah lain
• konten terkait proyek di mana "data kepemimpinan" hanya akan diberikan kepada sekelompok orang terbatas, dll.

Ada daftar contoh seperti itu yang berpotensi tak ada habisnya. Intinya adalah selalu ada semacam kebutuhan untuk mengatur hak akses ke file dan data antara semua pengguna yang aksesnya disediakan oleh platform.

Dalam kasus solusi di tempat, ini adalah tugas rutin. Administrator sistem file hanya mengatur beberapa aturan, menggunakan alat pilihan, dan kemudian orang-orang dipetakan ke dalam grup pengguna, dan grup pengguna dipetakan ke dalam daftar folder atau titik pemasangan yang dapat mereka akses. Sepanjang jalan, tingkat akses didefinisikan sebagai akses baca-saja atau baca & tulis.

Sekarang melihat ke dalam platform cloud AWS, jelas mengharapkan orang memiliki persyaratan serupa untuk pembatasan akses konten. Solusi untuk masalah ini harus, namun sekarang, berbeda. File tidak lagi bertahan di server Unix tetapi di cloud (dan berpotensi dapat diakses tidak hanya oleh seluruh organisasi tetapi bahkan seluruh dunia), dan konten tidak disimpan di folder tetapi di bucket S3.

Di bawah ini dijelaskan adalah alternatif untuk mendekati masalah ini. Itu dibangun di atas pengalaman dunia nyata yang saya miliki ketika saya merancang solusi semacam itu untuk proyek nyata.

Pendekatan Sederhana Tapi Sangat Manual

Salah satu cara untuk mengatasi masalah ini tanpa otomatisasi apa pun relatif mudah dan sederhana:

• Buat keranjang baru untuk setiap kelompok orang yang berbeda.
• Tetapkan hak akses ke bucket sehingga hanya grup khusus ini yang dapat mengakses bucket S3.

Hal ini tentunya dimungkinkan jika persyaratannya adalah dengan resolusi yang sangat sederhana dan cepat. Namun, ada beberapa batasan yang harus diperhatikan.

Secara default, hanya hingga 100 bucket S3 yang dapat dibuat dalam satu akun AWS. Batas ini dapat diperpanjang hingga 1000 dengan mengajukan peningkatan batas layanan ke tiket AWS. Jika batasan tersebut bukan sesuatu yang dikhawatirkan oleh kasus implementasi khusus Anda, maka Anda dapat membiarkan setiap pengguna domain Anda yang berbeda beroperasi pada bucket S3 terpisah dan menghentikannya setiap hari.

Masalah mungkin timbul jika ada beberapa kelompok orang dengan tanggung jawab lintas fungsi atau hanya beberapa orang yang memerlukan akses ke konten dari lebih banyak domain pada waktu yang bersamaan. Sebagai contoh:

• Analis data mengevaluasi konten data untuk beberapa area, wilayah, dll.
• Tim pengujian berbagi layanan yang melayani tim pengembangan yang berbeda.
• Melaporkan pengguna yang perlu membuat analisis dasbor di atas berbagai negara di dalam wilayah yang sama.

Seperti yang Anda bayangkan, daftar ini dapat bertambah lagi sebanyak yang Anda bayangkan, dan kebutuhan organisasi dapat menghasilkan semua jenis kasus penggunaan.

Semakin kompleks daftar ini, orkestrasi hak akses yang lebih kompleks akan diperlukan untuk memberikan semua grup yang berbeda hak akses yang berbeda ke bucket S3 yang berbeda dalam organisasi. Akan ada alat tambahan yang diperlukan, dan bahkan mungkin sumber daya khusus (administrator) perlu memelihara daftar hak akses dan memperbaruinya setiap kali ada perubahan yang diminta (yang akan sangat sering terjadi, terutama jika organisasinya besar).

Jadi, bagaimana cara mencapai hal yang sama dengan cara yang lebih terorganisir dan otomatis?

Perkenalkan Tag Untuk Bucket

Jika pendekatan keranjang-per-domain tidak berfungsi, solusi lain apa pun akan berakhir dengan keranjang bersama untuk lebih banyak grup pengguna. Dalam kasus seperti itu, perlu membangun keseluruhan logika pemberian hak akses di beberapa area yang mudah diubah atau diperbarui secara dinamis.

Salah satu cara untuk mencapainya adalah dengan menggunakan Tag pada bucket S3. Tag direkomendasikan untuk digunakan dalam hal apa pun (jika hanya untuk mengaktifkan kategorisasi penagihan yang lebih mudah). Namun, tag dapat diubah kapan saja di masa mendatang untuk sembarang keranjang.

Jika seluruh logika dibuat berdasarkan tag bucket dan sisanya bergantung pada konfigurasi nilai tag, properti dinamis dijamin karena seseorang dapat mendefinisikan ulang tujuan bucket hanya dengan memperbarui nilai tag.

Jenis tag apa yang digunakan untuk membuat ini berfungsi?

Ini tergantung pada kasus penggunaan konkret Anda. Sebagai contoh:

• Mungkin diperlukan untuk memisahkan bucket per jenis lingkungan. Jadi, dalam hal ini, salah satu nama tag harus seperti "ENV" dan dengan kemungkinan nilai "DEV", "TEST", "PROD", dll.
• Mungkin Anda ingin memisahkan tim berdasarkan negara. Dalam hal ini, tag lain akan menjadi "NEGARA" dan menghargai beberapa nama negara.
• Atau Anda mungkin ingin memisahkan pengguna berdasarkan departemen fungsional tempat mereka berada, seperti analis bisnis, pengguna gudang data, ilmuwan data, dll. Jadi, Anda membuat tag dengan nama "USER_TYPE" dan nilainya masing-masing.
• Opsi lain mungkin Anda ingin secara eksplisit menentukan struktur folder tetap untuk grup pengguna tertentu yang harus mereka gunakan (agar tidak membuat kekacauan folder mereka sendiri dan tersesat di sana seiring waktu). Anda dapat melakukannya lagi dengan tag, di mana Anda dapat menentukan beberapa direktori kerja seperti: "data/import", "data/processed", "data/error", dll.

Idealnya, Anda ingin menentukan tag sehingga dapat digabungkan secara logis dan membuatnya membentuk keseluruhan struktur folder pada bucket.

Misalnya, Anda dapat menggabungkan tag berikut dari contoh di atas untuk membuat struktur folder khusus untuk berbagai jenis pengguna dari berbagai negara dengan folder impor yang telah ditentukan sebelumnya yang diharapkan akan mereka gunakan:

• /<ENV>/<USER_TYPE>/<NEGARA>/<UPLOAD>

Hanya dengan mengubah nilai <ENV>, Anda dapat mendefinisikan ulang tujuan tag (apakah akan ditugaskan untuk menguji ekosistem lingkungan, dev, prod, dll.)

Ini akan memungkinkan penggunaan keranjang yang sama untuk banyak pengguna yang berbeda. Bucket tidak mendukung folder secara eksplisit, tetapi mereka mendukung "label". Label tersebut pada akhirnya berfungsi seperti subfolder karena pengguna harus melalui serangkaian label untuk mencapai data mereka (seperti yang akan mereka lakukan dengan subfolder).

Buat Kebijakan Dinamis Dan Tag Bucket Peta Di Dalam

Setelah menentukan tag dalam beberapa bentuk yang dapat digunakan, langkah berikutnya adalah membangun kebijakan bucket S3 yang akan menggunakan tag tersebut.

Jika kebijakan menggunakan nama tag, Anda membuat sesuatu yang disebut "kebijakan dinamis". Ini pada dasarnya berarti kebijakan Anda akan berperilaku berbeda untuk keranjang dengan nilai tag berbeda yang dirujuk oleh kebijakan dalam bentuk atau placeholder.

Langkah ini jelas melibatkan beberapa pengkodean khusus dari kebijakan dinamis, tetapi Anda dapat menyederhanakan langkah ini menggunakan alat editor kebijakan Amazon AWS, yang akan memandu Anda melalui proses tersebut.

Dalam kebijakan itu sendiri, Anda ingin mengkodekan hak akses konkret yang akan diterapkan ke bucket dan tingkat akses dari hak tersebut (baca, tulis). Logika akan membaca tag pada bucket dan akan membangun struktur folder pada bucket (membuat label berdasarkan tag). Berdasarkan nilai konkret dari tag, subfolder akan dibuat, dan hak akses yang diperlukan akan ditetapkan di sepanjang baris.

Hal yang menyenangkan tentang kebijakan dinamis semacam itu adalah Anda dapat membuat hanya satu kebijakan dinamis dan kemudian menetapkan kebijakan dinamis yang sama ke banyak keranjang. Kebijakan ini akan berperilaku berbeda untuk keranjang dengan nilai tag yang berbeda, tetapi akan selalu sesuai dengan harapan Anda untuk keranjang dengan nilai tag tersebut.

Ini adalah cara yang sangat efektif untuk mengelola penetapan hak akses dengan cara yang terorganisasi dan terpusat untuk sejumlah besar bucket, dengan harapan bahwa setiap bucket akan mengikuti beberapa struktur template yang telah disetujui sebelumnya dan akan digunakan oleh pengguna Anda di dalam seluruh organisasi.

Mengotomatiskan Onboarding Entitas Baru

Setelah menentukan kebijakan dinamis dan menetapkannya ke bucket yang ada, pengguna dapat mulai menggunakan bucket yang sama tanpa risiko pengguna dari grup yang berbeda tidak akan mengakses konten (disimpan di bucket yang sama) yang terletak di bawah struktur folder yang tidak mereka miliki. mengakses.

Juga, untuk beberapa grup pengguna dengan akses yang lebih luas, akan mudah menjangkau data karena semuanya akan disimpan di keranjang yang sama.

Langkah terakhir adalah membuat orientasi pengguna baru, keranjang baru, dan bahkan tag baru sesederhana mungkin. Ini mengarah ke pengkodean khusus lainnya, yang, bagaimanapun, tidak perlu terlalu rumit, dengan asumsi proses onboarding Anda memiliki beberapa aturan yang sangat jelas yang dapat dikemas dengan logika algoritme yang sederhana dan lugas (setidaknya Anda dapat membuktikan dengan cara ini bahwa Anda proses memiliki beberapa logika dan tidak dilakukan dengan cara yang terlalu kacau).

Ini bisa sesederhana membuat skrip yang dapat dieksekusi oleh perintah AWS CLI dengan parameter yang diperlukan untuk berhasil memasukkan entitas baru ke dalam platform. Itu bahkan bisa berupa serangkaian skrip CLI, dapat dieksekusi dalam urutan tertentu, seperti, misalnya:

• create_new_bucket(<ENV>,<ENV_VALUE>,<COUNTRY>,<COUNTRY_VALUE>, ..)
• buat_tag_baru(<bucket_id>,<nama_tag>,<nilai_tag>)
• update_existing_tag(<bucket_id>,<tag_name>,<tag_value>)
• buat_user_group(<user_type>,<negara>,<env>)
• dll.

Anda mengerti maksudnya.

Kiat Pro

Ada satu Pro Tip jika Anda suka, yang dapat dengan mudah diterapkan di atas.

Kebijakan dinamis dapat dimanfaatkan tidak hanya untuk menetapkan hak akses untuk lokasi folder tetapi juga untuk menetapkan hak layanan untuk keranjang dan grup pengguna secara otomatis!

Yang diperlukan hanyalah memperluas daftar tag pada bucket dan kemudian menambahkan hak akses kebijakan dinamis untuk menggunakan layanan tertentu bagi kelompok pengguna yang konkret.

Misalnya, mungkin ada beberapa kelompok pengguna yang juga memerlukan akses ke server cluster database tertentu. Hal ini tidak diragukan lagi dapat dicapai dengan kebijakan dinamis yang memanfaatkan tugas-tugas keranjang, terlebih lagi jika akses ke layanan didorong oleh pendekatan berbasis peran. Tambahkan saja ke kode kebijakan dinamis bagian yang akan memproses tag mengenai spesifikasi cluster database dan menetapkan hak akses kebijakan ke cluster DB dan grup pengguna tertentu secara langsung.

Dengan cara ini, orientasi grup pengguna baru akan dapat dijalankan hanya dengan satu kebijakan dinamis ini. Selain itu, karena bersifat dinamis, kebijakan yang sama dapat digunakan kembali untuk mengaktifkan banyak grup pengguna yang berbeda (diharapkan mengikuti template yang sama tetapi belum tentu layanan yang sama).

Anda juga dapat melihat Perintah AWS S3 ini untuk mengelola bucket dan data.