vStack Center erişim modeli

Sorun ve amaç

Tek bir küme birçok kullanıcıya hizmet verir: platform yöneticisi, tek bir VDC'nin (sanal veri merkezi) yöneticisi, yalnızca kendi makineleriyle çalışan bir kullanıcı ve yalnızca okuma erişimine ve raporlara ihtiyaç duyan bir görüntüleyici. Hepsi aynı küme HTTPS uç noktasını kullanır ve aynı yöntemleri çağırır. Tek bir "yönetici / yönetici değil" işareti onları ayırt edemez: "bir ağı görüntüleme" ve "kendi ağınızı düzenleme" farklı izinlerdir ve ikincisi ayrıca sınırlı bir nesne kümesine uygulanır.

Bu da tek bir rol listesi yerine üç katmanlı bir model gerektirir. Rol yetkilerden oluşur, yetki erişim verdiği yöntemleri listeler ve kapsam özniteliği yetkiyi belirli nesnelerle sınırlar. Bu üç katman net olarak anlaşılmadığında platformun davranışı tutarsız görünebilir: bir VDC'de yönetici rolüne sahip bir kullanıcının başka bir VDC'de erişimi reddedilir ve "tüm yetkili kullanıcılara" açık bir yöntem farklı roller için farklı alan kümeleri döndürür.

Bu sayfa modeli açıklar. Hesap oluşturma ve bakımı için Kullanıcıları yönetme sayfasına; özel bir rol oluşturma ve atama için Rolleri ve yetkileri yapılandırma sayfasına; oturumlar ve oturum açma ilkesi için Oturum açmayı yapılandırma ve oturumları yönetme sayfasına bakın.

Model ve varlıklar

vStack Center'da erişim dört varlıktan oluşur.

Kullanıcı. Sayısal bir id, bir name, tam ad fullname ve created ile modified zaman damgalarına sahip bir küme hesabı. Hesap oluşturulduğunda parolası yoktur; parola ayrı bir çağrıyla belirlenir. Oturum açma sayaçları profille birlikte saklanır: failed_login_attempts, first_failed_at ve locked_until. id < 10 tanımlayıcıları yerleşik hesaplara ayrılmıştır: platform bunların silinmesini veya rol atamalarının değiştirilmesini yasaklar.

Yetki. Bir izin birimi. Yetkinin bir id değeri, okunabilir bir name adı, bir category_id kategorisi, bir scope_ids kümesi ve ana alanı olan methods vardır: yetkinin erişim verdiği JSON-RPC yöntem adlarının listesi. Bir yöntemi kimin çağırabileceğini rol numarası değil, yetki belirler.

Kapsam özniteliği. Bir izni nesnelerin bir alt kümesiyle sınırlayan öznitelik. Bir id, bir name ve bir self_referencing işaretine sahiptir. Aralarında temel bir fark bulunan iki tür öznitelik vardır:

Öznitelik	self_referencing	Değer kaynağı	Neyi sınırlar
vdc_id	false	user_role_scope atama tablosu	rolün geçerli olduğu VDC'lerin listesi
creator	true	çağıranın user_id değerinden üretilir	çağıranın oluşturduğu nesneler

Rol. Adlandırılmış bir yetki kümesi ile bir kapsam öznitelikleri kümesi. Roller, tanımlayıcı aralıklarına göre sabit veya özel olarak sınıflandırılır.

ID	Rol adı	Tür	Düzey
1	Cluster Master	sabit	küme
2	vDC Admin	sabit	VDC
3	vDC User	sabit	VDC
4	vDC Viewer	sabit	VDC
5	Resource Viewer	sabit	küme
6	Security Admin	sabit	küme
7	VM Developer	sabit	VDC
≥ 10000	özel ad, en fazla 64 karakter	özel	kapsam özniteliklerine göre belirlenir

Security Admin ve VM Developer rolleri 3.0.3 sürümünde kullanıma sunuldu. Birincisi küme düzeyinde çalışır ve güvenlik günlüğüne ve denetime erişim verir; ikincisi bir VDC içinde çalışır ve sanal makineleri (VM) oluşturmak ve yapılandırmak için tasarlanmıştır.

Sabit rollerin creator alanı boştur (null) ve bu roller değiştirilemez veya silinemez. Özel bir rolde creator, rolü oluşturan kullanıcının id değerini saklar. Cluster master rolünün kapsam bağlantısı yoktur: scope_ids değeri boş bir dizidir, bu nedenle kümenin tamamına uygulanır.

Beşinci varlık bir nesne değil, bir ilişkidir: atama. Rol bir kullanıcıya kapsamsız olarak değil, belirli bir VDC içinde bir kapsam özniteliği değeriyle birlikte atanır. Tek bir kullanıcı bir VDC'de vDC admin, başka bir VDC'de vDC viewer rolüne sahip olabilir.

Erişim denetimleri nasıl çalışır

Her istek sırayla dört denetimden geçer.

1. Oturum. Küme oturum belirtecini doğrular ve onu sayısal bir kullanıcı tanımlayıcısıyla değiştirir; bundan sonra kullanıcı küme içinde bu tanımlayıcıyla tanınır. Belirteç içermeyen bir istek, herhangi bir yöntem mantığı çalışmadan önce -9494 koduyla ("No session token") reddedilir.
2. Çağıranın rolleri. Tanımlayıcı bir atama haritası oluşturmak için kullanılır: kullanıcının hangi VDC'lerde hangi rollere sahip olduğu. Kullanıcılar kendi haritalarını görüntüleyebilir; her atama VDC'yi, rolü, rol adını ve bir GI hesabı işaretini içerir.
3. Yetki. Yöntem, kullanıcının rollerinin verdiği yetkilerin methods listelerine göre denetlenir. Yetki yoksa erişim reddedilir. Burada rol numarası önemsizdir: rol yalnızca bir yetki kümesi olarak önem taşır.
4. Kapsam. Bir yetkinin scope_ids değeri varsa izin yalnızca o kapsamdaki nesnelere uygulanır. vdc_id değerleri rol atamalarından, creator değerleri ise çağıranın uid değerinden gelir. Boş bir scope_ids genel bir yetki anlamına gelir.

Genel ve kapsamlı izin arasındaki fark atamanın kendisinde görünür: her rol ve kapsam özniteliği çifti ya öznitelik değerlerini listeler ya da bir "kısıtlamasız" işaretine sahiptir. Bu işaret, atamaların değer içermediği ve rolün bu öznitelikle kısıtlanmadığı anlamına gelir. Örneğin vDC admin rolünün vdc_id özniteliği iki VDC ile kısıtlanmış olabilirken Resource viewer rolünün hiç kapsam özniteliği yoktur.

Yetkiler kategoriler halinde gruplandırılır. Kategori yalnızca yetkileri gruplandırır; izin denetimlerini etkilemez. Kategori kümesi küme veritabanına başlangıçta yüklenir ve platform yeni alanlar ekledikçe büyür. İlk on kategori vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc ve Auth'tur; bunlara Security, User Interface, Unified Storage, OS Image Library ve Backup eklenmiştir.

not

API belgelerindeki örnek yalnızca ilk on kategoriyi listelerken veritabanında on beş kategori bulunur. Tutarsızlık platformun davranışında değil, örnektedir: kategori başvurusunun tamamı döndürülür, bu nedenle kümenizdeki gerçek kategori kümesini kullanın.

Yetki kaydından iki örnek her iki kısıtlama türünü de gösterir:

Yetki	Kategori	Kapsam	Erişim verdiği yöntem
1000 View vDC	1 (vDC)	[1] — vdc_id	vdc-list
2010 Edit Own Network	3 (Network)	[2] — creator	net-set

Birincisi rolün atandığı VDC'lerde geçerlidir. İkincisi VDC'den bağımsız olarak yalnızca çağıranın oluşturduğu ağlara uygulanır.

Modelin sınırları

Yetki modeli kullanıcı yönetiminin kendisini kapsamaz. user-* grubundaki birçok yöntem genel bir rol gerektirir ve diğer herkese "Access denied" iletisiyle -403 kodunu döndürür. Bu durum user-list, user-get, user-create, user-delete, user-unlock, user-role-assign, user-role-deassign, user-roles-map ve user-remote-* ile user-vhost-* kısıtlama yöntemleri için geçerlidir. Küme yöneticisi izinleri kısmen verilemez; bu, bilinçli olarak kapalı tutulan bir izin kümesidir.

Aynı ilke, "neredeyse Cluster master" olan özel bir rol oluşturulmasını önleyen dört kısıtlama getirir:

Kısıtlama	Neden	Bunun yerine ne yapılmalı
7111–7113 rol yönetimi yetkileri özel bir role atanamaz	Aksi takdirde rol kendi izinlerini genişletebilirdi	Rol yönetimini Cluster master rolüne bırakın
Özel bir rolün scope_ids değerinde kendine başvuran öznitelik (creator) yasaktır	Değeri user_id değerinden üretilir, bu nedenle role bağlanacak bir değer yoktur	vdc_id kullanın ve "yalnızca kendi nesneleri" kısıtlaması için mevcut Own yetkilerini kullanın
Sabit roller (id < 10000) değiştirilemez veya silinemez	Platformun temel sözleşmelerini tanımlarlar	Gerekli yetki kümesiyle özel bir rol oluşturun
id < 10 olan hesapların rol atamaları değiştirilemez ve bu hesaplar silinemez	Yerleşik hesaplar kümenin çalışır durumda kalmasını sağlar	Ayrı bir kullanıcı oluşturun

İlk bakışta şaşırtıcı olabilecek bir davranış daha: aynı işlem farklı roller için farklı miktarda veri döndürebilir. Herhangi bir yetkili kullanıcı kümenin güvenlik ayarlarını okuyabilir, ancak parola gereksinimlerini herkes görebilirken başarısız deneme sınırını ve kilitleme süresini yalnızca Cluster master görebilir.

Arayüzde nerede bulunur

Hesaplar ve roller aynı bölümdedir. Yol: Provider Data Center → Users & Roles. Bölümde iki sekme vardır: Name, Status, Full Name, Created ve Changed sütunlarına sahip bir hesap tablosu olan Users ve Name, scope, Creator, Created ve Modified sütunlarına sahip bir rol tablosu olan Roles. Rol tablosundaki scope sütunu, rolün kapsam öznitelikleri kümesidir.

Bir rol ayrı bir ekranda açılır (adres çubuğunda #/panel/allusers/roles/ görünür). Yetkiler orada bölümler halinde gruplandırılmıştır: vDC, VM, Network, Edge, Storage, Node, Cluster, User, Misc, Auth, Security ve User Interface. Sabit bir rolün ekranında Actions, Reset ve Save changes düğmeleri devre dışıdır; bu, sabit rollerin değiştirilmesine yönelik yasağı yansıtır.

Ayrıca bakınız

• Hesap oluşturma, parolalar, kilit açma ve ağ kısıtlamaları — Kullanıcıları yönetme.
• Özel bir rol oluşturma ve bir VDC'de rol atama — Rolleri ve yetkileri yapılandırma.
• Oturumlar, parola ilkesi ve hesap kilitleme — Oturum açmayı yapılandırma ve oturumları yönetme.
• Tam alan kümeleri ve hata kodlarının eksiksiz listesi — Erişim yöntemlerinin alanları ve hata kodları.

API yöntemleri

Bu sayfada ele alınan API işlemleri: privilege-categories, privilege-list, privilege-scopes, role-list, role-get, role-privilege-list, user-role, user-roles, user-roles-v2, user-roles-map, auth-security-settings-get — API başvurusuna bakın.