Kibana: Otorisasi objek tersimpan - Fase 1

+1

tbragin: Anda menyebutkan solusi menggunakan beberapa instance kibana. yang akan bekerja untuk saya karena saya hanya memiliki dua kelompok. satu mendapat akses penuh, yang lain akan terbatas pada jenis log tertentu seperti log akses.

untuk pengaturan ini, apakah saya perlu menyimpan log akses ke indeks tambahan yang terhubung dengan titik instance kibana kedua?

Apakah pendekatan ini bekerja dengan Shield?

Saat ini kami menggunakan beberapa instance Kibana dengan .kibana-index yang berbeda untuk membagi grup kami.
Pengguna dalam grup akan melihat dasbor/data yang berbeda.
Untuk setiap grup baru, kami harus menyiapkan instance baru. Ini akan menjadi masalah besar bagi pelanggan kami.
Karena persyaratan organisasi ini menghasilkan biaya.

melalui @dannymeijer di #4714

Dalam kasus penggunaan kami, kami ingin mulai menerapkan Kibana ke basis pengguna yang sangat luas. Untuk mencegah masalah dengan orang yang 'tidak sengaja' melanggar sesuatu untuk orang lain (misalnya, menghapus dasbor orang lain), kami ingin dapat menentukan tingkat otorisasi.

Saya sedang memikirkan sesuatu seperti ini (sebagai contoh):

Pengguna biasa:
Dapat menemukan dan menggunakan salah satu visualisasi yang tersimpan, tetapi Anda tidak ingin pengguna biasa 'mengacaukan apa pun'. Tidak dapat menyimpan atau mengelola objek.
Pengguna istimewa:
Memiliki beberapa hak lebih dari pengguna biasa. Dapat membuat dasbor dan mengelola beberapa pengaturan, tetapi tidak terlalu ekstensif.
Pengguna listrik:
orang yang bisa mengubah segalanya.
Masalah (sejauh yang saya tahu dengan rilis saat ini) adalah bahwa tingkat penguncian tidak sampai pada tingkat detail yang saya jelaskan. Misalnya, saya dapat menghapus plugin pengaturan, yang memberi saya keamanan bahwa pengaturan tidak akan dikacaukan. Tetapi ini juga menghilangkan fungsionalitas/kemampuan bagi pengguna untuk mengelola objek yang disimpan (karena bersarang di dalam plugin pengaturan).

Contoh lain dari ini adalah visualisasi. Saya tidak ingin pengguna biasa membuat dan menyimpan visualisasi (mereka hanya mampir untuk memeriksa konten yang sudah ada) - tetapi menonaktifkan plugin visualisasi tidak hanya akan menghapus tab visualisasi; itu benar-benar menonaktifkan semua dan setiap visualisasi.

Saya harap saya cukup luas dengan contoh-contoh untuk menggambarkan apa yang saya bicarakan. Solusi yang saya pikirkan akan melibatkan kemampuan untuk menyesuaikan di tingkat yang lebih rinci tentang apa yang disajikan kepada pengguna, mungkin dalam bentuk tag atau ember yang dapat Anda tetapkan sebelumnya.

Persyaratan agar ini berfungsi jelas bahwa kerangka otentikasi sudah ada (masalah #3904 / #4419 / #4634).

+1

Jika ini dapat dikaitkan dengan LDAP/AD di mana kita sudah memiliki grup yang berbeda, itu akan sangat bagus.

+1
dengan LDAP!

+1
Kami berada dalam situasi yang sama dengan @Malu44 , jadi akan sangat bagus untuk mengintegrasikan ini dengan Shield

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1!!
Orang-orang yang dimaksudkan hanya untuk memeriksa dasbor saya untuk analisis dan mendapatkan informasi mengubah dasbor dan visualisasi saya (kebanyakan dari mereka menganggap perubahan itu lokal) dan saya harus mengimpor cadangan sesekali .....
Izin grup akan sangat bagus!

+1, ini sangat dibutuhkan.

+1

+1

+1 Menyiapkan instans Kibana terpisah bukanlah pilihan yang baik untuk penerapan dengan penawaran layanan untuk ribuan pelanggan, dll..

+1

+1000

Sudah bisa dilakukan dengan dasbor yang disematkan.

Meskipun perlu penguncian tata letak dan tampilan bilah atas dengan timepicker.

Pada hari Rabu, 25 November 2015, gnom1gnom [email protected] menulis:

+1000

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/elastic/kibana/issues/4453#issuecomment -159556182.

Dikirim dari Gmail Seluler

Bagaimana cara kerjanya dengan batasan hanya memiliki satu kibana_index per Server Kibana?
Saya pikir setiap pengguna membutuhkan pola indeksnya sendiri, karena dia mungkin tidak memiliki akses ke semua indeks.
Bisakah Pola-Indeks difilter per pengguna?

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Memberi +1 ini akan menempatkan Kibana pada level playing field dengan Graylog2 yang ingin saya hindari karena kerumitan penerapannya.

+1

+1

+1

+1

+1

+1

Diperhatikan juga tidak ada di Kibana 5.
+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

Halo semua,

mungkinkah ini solusi yang mungkin?

Saya menggunakan versi 5.2.0. Di Kibana-Management-Users, buat pengguna (user1) dan peran khusus untuk pengguna ini (role1).

Pengguna ini hanya harus memiliki akses ke indeks "contoh-*", dan hanya visualisasi, dasbor, pencarian mereka...

== PERAN1 ==

Nama: Peran1
Hak istimewa cluster: Tidak ada
Hak istimewa indeks:

| Indeks: contoh-*
| Hak istimewa: baca, lihat_index_metadata
| Bidang yang Diberikan: *

+

| Indeks: .kibana
| Hak istimewa: baca, lihat_index_metadata
| Bidang yang Diberikan: *
| Kueri Dokumen yang Diberikan

{
  "bool" : {
      "should" :  [
              { "term" :  { "_id" : "default_index" } },
              { "term" :  { "_id" : "5.2.0" } },
              { "term" :  { "_id" : "example-*" } },
         { "term" :  { "_id" : "DASHBOARD1" } },
         { "term" :  { "_id" : "DASHBOARD2" } },
         { "term" :  { "_id" : "..." } },
         { "term" :  { "_id" : "VISUALIZATION1" } },
         { "term" :  { "_id" : "VISUALIZATION2" } },
         { "term" :  { "_id" : "..." } },
         { "term" :  { "_id" : "SEARCH1" } },
         { "term" :  { "_id" : "SEARCH2" } },
         { "term" :  { "_id" : "..." } }
      ],
      "minimum_should_match" : 1
  }
}

Anda dapat membuat indeks default netral kosong untuk semua pengguna. PUT / mulai

Salam

Ada pembaruan tentang ini?

+1

tambah satu

@sergolr100

Yah saya suka solusinya tetapi menghadapi beberapa masalah. Sangat menyesal saya menanyakan pertanyaan di sini.
Jadi peran saya seperti
Nama Peran :- Manajemen
Hak istimewa cluster: Tidak ada
Hak istimewa indeks:
| Indeks: manajemen
| Hak istimewa: baca, lihat_index_metadata
| Bidang yang Diberikan: *

| Indeks: .kibana_management
| Hak istimewa: baca, lihat_index_metadata
| Bidang yang Diberikan: *
| Kueri Dokumen yang Diberikan

{
  "bool" : {
      "should" :  [
{ "term" :  { "_id" : "management" } },
{ "term" :  { "_id" : "5.2.2" } },
{ "term" :  { "_id" : "7a386190-19e5-11e7-90e2-a52016cb5a60" } }
      ],
      "minimum_should_match" : 1
  }
}

Dengan di atas saya tidak dapat melihat data/dokumen di halaman temukan, namun dengan pengguna elastis yang membuat indeks ini (manajemen) dapat melihat dokumen/data di halaman temukan. FYI saya telah menggabungkan kedua pengaturan di atas dalam satu peran saja juga di sini ID adalah ID visualisasi saya meskipun ini tidak menampilkan data apa pun.

+1

+1

Apache Shiro menginspirasi saya untuk membuat Rushhiro https://github.com/guyboertje/rushiro untuk platform Rails e-commerce yang saya kerjakan beberapa tahun yang lalu.

Dari apa yang saya lihat dari sistem izin AWS, itu juga terinspirasi oleh Shiro.

------ ekstrak
Bagian izin memiliki beberapa bagian yang dipisahkan pipa, Anda benar-benar gratis
untuk memilih skema, tetapi ingat bahwa evaluasi dilakukan dari kiri ke kanan.

Satu saran mungkin: Domain|Action|Instance

• Domain - alias sumber daya, misalnya halaman web, entitas db, model atau layanan domain
• Tindakan - entri dari rangkaian tindakan yang tersedia untuk domain (mentah, rw, gunakan/kelola)
• Instance - entri ini adalah 'label' yang telah Anda berikan ke instance domain,
  misalnya halaman web tertentu, uuid atau id unik dari catatan db
  Catatan: Beberapa entri yang dipisahkan koma diperbolehkan, seperti * wildcard

contoh: hash ini diproses menjadi hierarki objek

perm = {
  allows: {
    individual: [
      "feature|create,read,update|feat-x",
      "page|*|posts",
      "company|read"
      "company|update|5b90a720-e6b0-012e-dc18-782bcb979e60"
    ],
    organization: [],
    system: []
  },
  denies: {}
}

access_control = AllowBasedControl.new(perm)
access_control.permitted?("company|read|5b90a720-e6b0-012e-dc18-782bcb979e60") ==> true
access_control.permitted?("feature|delete|feat-x") ==> false

------ ekstrak

Hai @tbragin
Adakah pembaruan tentang peningkatan ini? Kapan dan versi Kibana mana yang bisa kita lihat ini? Apakah ini akan tersedia sebagai open source?

Apa masalah # di GitHub untuk meningkatkan kibana untuk memberikan akses berbutir halus yang nyata ke objek kibana (di mana beberapa pengguna akan membaca, yang lain dapat memiliki akses penuh) berdasarkan peran/keanggotaan grup? Saya tidak dapat menemukannya. Jika masalah itu belum ada, seharusnya. Pendekatan yang digunakan dalam masalah ini dengan tag yang dapat Anda tetapkan ke objek masih memberi semua pengguna dengan tag tersebut tingkat akses yang sama (akses penuh) - bukan yang diinginkan banyak orang. Terima kasih.

Solusi terbaik yang saya temukan sejauh ini mengenai masalah ini:

https://github.com/wtakase/kibana-own-home

+1

+1

+1

+1

Perusahaan kami telah menemukan cara untuk mengatasi masalah ini: menyerah pada ELK dan gunakan saja Splunk. ELK baik-baik saja untuk beberapa orang dalam tim yang erat, tetapi Splunk memiliki fungsionalitas terkait akun pengguna yang jauh lebih baik untuk tim yang lebih besar atau banyak tim.

+1

+1

+1, akan senang melihat fitur ini diimplementasikan dalam bentuk apa pun yang tepat!

+1 tetapi tiga tahun dan saya tidak percaya ada yang dilakukan di depan ini?

Kami ingin memberikan akses luar ke instans Kibana kami, tetapi akses halus ke dasbor adalah KEHARUSAN. Bahkan secara internal ini adalah semacam kebutuhan dan saya kira itu berlaku untuk semua orang yang menggunakan Kibana di luar tim kecil.

cc @elastic/kibana-security jangan ragu untuk menutup dan merujuk ke masalah yang lebih terkini, jika ada

Digantikan oleh https://github.com/elastic/kibana/issues/18473