[ English | Indonesia | Deutsch | 日本語 ]

Manajemen pengguna

OpenStack Dashboard menyediakan antarmuka grafis untuk mengelola pengguna. Bagian ini menjelaskan manajemen pengguna dengan Dasbor.

Anda juga bisa manage projects, users, and roles dari klien command-line.

Selain itu, banyak situs menulis alat kustom untuk kebutuhan lokal untuk menegakkan kebijakan lokal dan menyediakan tingkat layanan mandiri kepada pengguna yang saat ini tidak tersedia dengan alat dikemas.

Membuat Pengguna Baru

Untuk membuat pengguna, Anda memerlukan informasi berikut:

• Username

• Deskripsi

• Alamat email

• Password

• Primary project

• Role

• Enabled

Nama pengguna dan alamat email cukup jelas, meskipun situs Anda mungkin memiliki konvensi lokal yang harus Anda amati. Proyek utama hanyalah proyek pertama yang dikaitkan dengan pengguna dan harus ada sebelum membuat pengguna. Peran hampir selalu akan menjadi "member." Di luar kotak, OpenStack hadir dengan dua peran yang ditentukan:

member

A typical user

admin

Pengguna super administratif, yang memiliki izin penuh di semua proyek dan harus digunakan dengan sangat hati-hati

Dimungkinkan untuk mendefinisikan peran lain, tetapi hal itu jarang terjadi.

Setelah Anda mengumpulkan informasi ini, membuat pengguna di dasbor hanyalah bentuk web lain yang mirip dengan apa yang telah kita lihat sebelumnya dan dapat ditemukan dengan mengklik tautan Users di navigation bar Identity dan kemudian mengklik tombol Create User di kanan atas.

Memodifikasi pengguna juga dilakukan dari halaman ini Users. Jika Anda memiliki banyak pengguna, halaman ini bisa sangat ramai. Kotak pencarian :guilabel: Filter di bagian atas halaman dapat digunakan untuk membatasi daftar pengguna. Formulir yang sangat mirip dengan dialog pembuatan pengguna dapat ditarik ke atas dengan memilih Edit dari menu drop-down tindakan di akhir baris untuk pengguna yang Anda modifikasi.

Mengaitkan Pengguna dengan Proyek

Banyak situs dijalankan dengan pengguna yang dikaitkan dengan hanya satu proyek. Ini adalah pilihan yang lebih konservatif dan lebih sederhana baik untuk administrasi maupun untuk pengguna. Secara administratif, jika pengguna melaporkan masalah dengan sebuah instance atau kuota, jelas proyek ini terkait dengan apa. Pengguna tidak perlu khawatir tentang proyek apa yang mereka lakukan jika mereka hanya dalam satu proyek. Namun, perhatikan bahwa, secara default, pengguna mana pun dapat memengaruhi sumber daya pengguna lain mana pun dalam proyek mereka. Dimungkinkan juga untuk mengaitkan pengguna dengan beberapa proyek jika itu masuk akal untuk organisasi Anda.

Mengaitkan pengguna yang ada dengan proyek tambahan atau menghapusnya dari proyek yang lebih lama dilakukan dari halaman Projects pada dasbor dengan memilih Manage Members dari kolom Actions, seperti yang ditunjukkan dalam tangkapan layar di bawah ini.

Dari tampilan ini, Anda dapat melakukan sejumlah hal bermanfaat, serta beberapa hal berbahaya.

Kolom pertama dari formulir ini, bernama All Users, termasuk daftar semua pengguna di cloud Anda yang belum dikaitkan dengan proyek ini. Kolom kedua menunjukkan semua pengguna. Daftar ini bisa sangat panjang, tetapi mereka dapat dibatasi dengan mengetikkan substring nama pengguna yang Anda cari di field filter di bagian atas kolom.

Dari sini, klik ikon :guilabel: + untuk menambahkan pengguna ke proyek. Klik pada - untuk menghapusnya.

Kemungkinan berbahaya datang dengan kemampuan untuk mengubah peran anggota. Ini adalah daftar dropdown di bawah nama pengguna di daftar Project Members. Dalam hampir semua kasus, nilai ini harus ditetapkan ke Member. Contoh ini dengan sengaja menunjukkan pengguna administratif di mana nilai ini adalah admin.

Peringatan

Admin bersifat global, bukan per proyek, jadi memberi pengguna peran admin dalam proyek apa pun memberikan hak administratif pengguna di seluruh cloud.

Penggunaan khusus adalah untuk hanya membuat pengguna administratif dalam satu proyek, dengan konvensi proyek admin, yang dibuat secara default selama pengaturan cloud. Jika pengguna administratif Anda juga menggunakan cloud untuk meluncurkan dan mengelola instance, sangat disarankan agar Anda menggunakan akun pengguna yang terpisah untuk akses administratif dan operasi normal dan mereka berada dalam proyek yang berbeda.

Customizing Authorization

Pengaturan default :term: `authorization ` memungkinkan pengguna administratif hanya untuk membuat sumber daya atas nama proyek yang berbeda. OpenStack menangani dua jenis kebijakan otorisasi:

Operation based

Kebijakan menentukan kriteria akses untuk operasi tertentu, mungkin dengan kontrol fine-grained atas atribut tertentu.

Resource based

Apakah akses ke sumber daya tertentu mungkin diberikan atau tidak sesuai dengan izin yang dikonfigurasi untuk sumber daya (saat ini hanya tersedia untuk sumber daya jaringan). Kebijakan otorisasi aktual yang diberlakukan dalam layanan OpenStack bervariasi dari penerapan hingga penerapan lainnya.

Mesin kebijakan membaca entri dari file policy.json. Lokasi sebenarnya dari file ini mungkin berbeda dari distribusi ke distribusi lainnya :untuk nova, biasanya dalam /etc/nova/policy.json. Anda dapat memperbarui entri saat sistem berjalan, dan Anda tidak harus memulai ulang layanan. Saat ini, satu-satunya cara untuk memperbarui kebijakan tersebut adalah mengedit file kebijakan.

Mesin kebijakan layanan OpenStack cocok dengan kebijakan secara langsung. Suatu peraturan menunjukkan evaluasi terhadap unsur-unsur kebijakan tersebut. Misalnya, dalam pernyataan compute:create: "rule:admin_or_owner", kebijakannya adalah compute:create, dan aturannya adalah admin_or_owner.

Kebijakan dipicu oleh mesin kebijakan OpenStack setiap kali salah satu dari mereka cocok dengan operasi OpenStack API atau atribut tertentu yang digunakan dalam operasi yang diberikan. Sebagai contoh, mesin menguji kebijakan create: compute setiap kali pengguna mengirim permintaan POST /v2/{tenant_id}/servers ke server OpenStack Compute API. Kebijakan dapat juga terkait dengan spesifik API extensions. Misalnya, jika pengguna membutuhkan ekstensi seperti compute_extension:rescue, atribut yang ditentukan oleh ekstensi penyedia memicu tes aturan untuk operasi itu.

Kebijakan otorisasi dapat disusun oleh satu atau beberapa aturan. Jika lebih banyak aturan ditetapkan, kebijakan evaluasi berhasil jika ada aturan yang berhasil dievaluasi; jika operasi API cocok dengan beberapa kebijakan, maka semua kebijakan harus dievaluasi dengan sukses. Juga, aturan otorisasi bersifat rekursif. Setelah aturan dicocokkan, aturan tersebut dapat diselesaikan ke aturan lain, sampai aturan terminal tercapai. Ini adalah aturan yang didefinisikan:

Aturan berbasis peran

Mengevaluasi dengan sukses jika pengguna yang mengajukan permintaan memiliki peran yang ditentukan. Misalnya, "role:admin" berhasil jika pengguna yang mengajukan permintaan adalah administrator.

Aturan berbasis field

Mengevaluasi dengan sukses jika bidang sumber daya yang ditentukan dalam permintaan saat ini cocok dengan nilai tertentu. Misalnya, "field:networks:shared=True" berhasil jika atribut yang dibagikan dari sumber daya jaringan diatur ke true.

Aturan umum

Bandingkan atribut dalam sumber daya dengan atribut yang diambil dari kredensial keamanan pengguna dan mengevaluasi dengan sukses jika perbandingan berhasil. Misalnya, "tenant_id:%(tenant_id)s" berhasil jika pengidentifikasi tenant dalam sumber daya sama dengan pengidentifikasi tenant dari pengguna yang mengirimkan permintaan.

Berikut ini cuplikan dari file policy.json nova default:

{
   "context_is_admin":  "role:admin",
   "admin_or_owner":  "is_admin:True", "project_id:%(project_id)s",
   "default": "rule:admin_or_owner",
   "compute:create": "",
   "compute:create:attach_network": "",
   "compute:create:attach_volume": "",
   "compute:get_all": "",
   "admin_api": "is_admin:True",
   "compute_extension:accounts": "rule:admin_api",
   "compute_extension:admin_actions": "rule:admin_api",
   "compute_extension:admin_actions:pause": "rule:admin_or_owner",
   "compute_extension:admin_actions:unpause": "rule:admin_or_owner",
   "compute_extension:admin_actions:migrate": "rule:admin_api",
   "compute_extension:aggregates": "rule:admin_api",
   "compute_extension:certificates": "",
   "compute_extension:flavorextraspecs": "",
   "compute_extension:flavormanage": "rule:admin_api",
}

1. admin_or_owner menunjukkan aturan yang mengevaluasi dengan sukses jika pengguna saat ini adalah administrator atau pemilik sumber daya yang ditentukan dalam permintaan (pengidentifikasi tenant sama).

2. default menampilkan kebijakan default, yang selalu dievaluasi jika operasi API tidak cocok dengan salah satu kebijakan di policy.json.

3. compute_extension: flavormanage menunjukkan kebijakan yang membatasi kemampuan untuk memanipulasi flavor ke administrator menggunakan Admin API saja.

Dalam beberapa kasus, beberapa operasi harus dibatasi hanya untuk administrator. Karena itu, sebagai contoh lebih lanjut, mari kita pertimbangkan bagaimana file kebijakan sampel ini dapat dimodifikasi dalam skenario di mana kami memungkinkan pengguna untuk membuat flavor mereka sendiri:

{
  "compute_extension:flavormanage": ""
}

Pengguna Yang Mengganggu Pengguna Lain

Pengguna di cloud Anda dapat mengganggu pengguna lain, terkadang dengan sengaja dan jahat, dan di waktu lain secara tidak sengaja. Memahami situasi memungkinkan Anda membuat keputusan yang lebih baik tentang bagaimana menangani gangguan itu.

Sebagai contoh, sekelompok pengguna memiliki instance yang memanfaatkan sejumlah besar sumber daya komputasi untuk tugas yang sangat intensif komputasi. Ini mendorong pemuatan pada node komputasi dan memengaruhi pengguna lain. Dalam situasi ini, tinjau kasus penggunaan pengguna Anda. Anda mungkin menemukan bahwa skenario komputasi tinggi adalah umum, dan kemudian harus merencanakan pemisahan yang tepat di cloud Anda, seperti agregasi host atau wilayah.

Contoh lain adalah pengguna mengkonsumsi jumlah bandwidth yang sangat besar. Sekali lagi, kuncinya adalah memahami apa yang dilakukan pengguna. Jika dia secara alami membutuhkan jumlah bandwidth yang tinggi, Anda mungkin harus membatasi laju transmisinya agar tidak mempengaruhi pengguna lain atau memindahkannya ke area dengan bandwidth yang lebih banyak tersedia. Di sisi lain, mungkin instancenya telah diretas dan merupakan bagian dari botnet yang meluncurkan serangan DDOS. Penyelesaian masalah ini sama seperti jika server lain di jaringan Anda telah diretas. Hubungi pengguna dan beri dia waktu untuk merespons. Jika dia tidak merespons, tutup instance.

Contoh terakhir adalah jika pengguna mempalu (hammering) sumber daya cloud berulang kali. Hubungi pengguna dan pelajari apa yang dia coba lakukan. Mungkin dia tidak mengerti bahwa apa yang dia lakukan tidak pantas, atau mungkin ada masalah dengan sumber daya yang dia coba akses yang menyebabkan permintaannya mengantri atau ketinggalan.