RBAC rol matrisini oku ve rol ata

Moonborn yedi yerleşik rol gönderir. Her biri kaynak × eylem (resource × action) matrisi üzerinde belirlenmiş bir izin (permission) seti ile gelir. Çoğu çalışma alanı bu yerleşik setle yetinir; özel bir matrisi olan ekipler (uyumluluk / compliance, özel iş akışları) Enterprise planında özel rol tanımlayabilir.

Bu rehber matrisi okumayı, davete rol atamayı, mevcut bir kullanıcının rolünü değiştirmeyi ve özel rol tanımlamayı gösterir. Üyelik (membership) değişiklikleri denetim kaydına (audit log) düşer — bu rehber boyunca gözlemlenebilir iz kalır.

Bu rehberi bitirdiğinde

• Yedi yerleşik rolün izin matrisini okuyabileceksin.
• api-only rolünün ne zaman tercih edileceğini bileceksin.
• Bir davete rol atayabilecek + mevcut bir üyenin rolünü güncelleyebileceksin.
• Özel rol (Enterprise) tanımlayabileceksin — <kaynak>:<eylem> izinleri listeleyerek.
• v1'de LDAP tarzı iç içe grup (nested group) olmadığını ve neden olmadığını bileceksin.

Ön koşul: owner veya admin rolü olan bir üyelik. Çalışma alanı ve davet temellerini bilmiyorsan önce Çalışma alanı, roller ve SSO kurulumu eğitimine bak.

Yerleşik roller — izin matrisi

Kısaltmalar: R = okuma (read), RW = okuma + yazma (read + write), — = erişim yok.

owner ve admin farkı

İkisi de tüm kaynaklarda RW. Farklar:

api-only — servis hesapları için

api-only rolü insan kullanıcı için tasarlanmamıştır — kullanıcı arayüzüne (UI) giriş yapamaz, sadece taşıyıcı belirteç (bearer token) ile çalışır. CI çalıştırıcısı, arka uç işi, ETL işçisi gibi servis hesapları için tercih edilir.

await client.memberships.invite({
  email: 'ci-bot@acme.co',
  role: 'api-only',
  workspaceId: 'ws_...',
});

İzinleri API anahtarı yetki kapsamlarından (scope) gelir; anahtarın kapsam listesinde ne varsa o izin verilir. Detay: API anahtarı yetki kapsamları (scope) referansı.

billing — finans takımı için

Sadece faturalama okuma + ödeme yöntemleri yönetimi. Persona, sohbet, yapılandırma erişimi yoktur. Tipik kullanım: muhasebe ekibinde fatura indiren ama persona içeriğini görmemesi gereken bir kullanıcı.

auditor — uyumluluk ekibi için

Denetim kaydı + yapılandırma + webhook'larda sadece okuma (read-only) yetkisi. Hiçbir kaynağa yazamaz. Uyumluluk incelemesi (compliance review) ve dahili güvenlik için idealdir — inceleme ekibi neyin ne zaman değiştiğini görür ama değiştiremez.

Davete rol ata

const invitation = await client.memberships.invite({
  email: 'designer@acme.co',
  role: 'editor',
  workspaceId: 'ws_...',
});
 
console.log(invitation.acceptUrl);

Davet edilen e-postaya acceptUrl ile bir bağlantı gider; kullanıcı kabul edene kadar üyelik pending (beklemede) durumunda kalır.

Mevcut bir üyenin rolünü değiştir

await client.memberships.update({
  id: 'mem_01H...',
  role: 'admin',
});

Özel roller (Enterprise)

Yerleşik matris ihtiyacına uymuyorsa kendi kaynak × eylem setini tanımla:

await client.roles.createCustomRole({
  workspaceId: 'ws_...',
  name: 'persona-reviewer',
  permissions: [
    'persona:read',
    'persona:audit:run',
    'audit:read',
  ],
});

İzinler <kaynak>:<eylem> desenini takip eder. Tam eylem listesi GET /v1/roles/actions uç noktasında döner.

Tipik özel rol örnekleri

İç içe grup (nested group) neden yok

Moonborn v1'de LDAP tarzı iç içe grup desteklemez. Düz rol listesi bilinçli bir tasarım kararıdır:

• Akıl yürütmesi daha kolay — "bu kullanıcı şu rolde" diyebilmek iç içe genişletme (nested expansion) zinciri çıkarmaktan kolaydır.
• SCIM hazırlama (provisioning) yeterlidir — kimlik sağlayıcının (IdP) gruplarını Moonborn rollerine 1:1 eşleyebilirsin. Grup hiyerarşisi IdP tarafında kalır.
• Denetim mantığı — kim hangi yetkiyi neden aldığı sorusu düz matriste anlıktır.

Eğer karmaşık grup hiyerarşisi gerekiyorsa, IdP (Okta, Azure AD, Google Workspace) tarafında grup hiyerarşisini tut, SCIM ile her grubun doğrudan Moonborn rolüne eşlendiği yapıyı kur. SCIM kurulumu için SCIM hazırlama.

Plan gereksinimi

• 4 temel rol (owner, admin, viewer, member): Free.
• editor, api-only, billing, auditor: Pro ve üstü.
• Özel roller: Enterprise.

İlgili