# Kaynak Gruplarıyla Kuruluşlarda Gelişmiş Erişim Denetimi

> [!WARNING]
> Bu özellik, Team & Enterprise planlarının bir parçasıdır.

Hugging Face organizasyonunuzda, belirli depolara hangi üyelerin erişebileceğini kontrol etmek için Resource Groups kullanabilirsiniz.

## Nasıl çalışır?

Resource Groups, organizasyon yöneticilerine **ilgili depoları birlikte gruplamayı** ve organizasyonunuzdaki farklı ekiplerin bağımsız depo kümeleri üzerinde çalışmasını sağlar.

- **Kaynaklar**: grubun depoları ve koleksiyonları. Her kaynak yalnızca **tek bir** Kaynak Grubuna ait olabilir ve uygun izinlere sahip üyeler tarafından gruplar arasında taşınabilir.
- **Üyeler**: bir Resource Group'daki depolara erişmek için organizasyon üyelerinin **eklenmesi gerekir**. Bir üye **birden fazla Resource Group**'a ait olabilir.

Üyeler, grup depolarındaki izinlerini belirleyen bir **rol** ile her Kaynak Grubunda atanır. Kaynak Grupları için dört farklı rol mevcuttur:

- `read`: Kaynak Grubu içindeki depolara **okuma erişimi** sağlar.
- `contributor`: **kullanıcının oluşturduğu depolara sınırlı yazma hakları** sağlar (yani kullanıcılar depolar oluşturabilir ve yalnızca bu depoları değiştirebilir). 'Write' rolüne benzer, ancak kullanıcının oluşturduğu depolarla sınırlıdır.
- `write`: Kaynak Grubu'ndaki **tüm depolara yazma erişimi** sağlar. Kullanıcılar, Kaynak Grubu'ndaki herhangi bir depoyu oluşturabilir, silebilir veya yeniden adlandırabilir.
- `admin`: Depolardaki yazma izinlerinin yanı sıra, admin üyeleri **Resource Group'u yönetebilir**: diğer üyelerin rollerini ekleyebilir, kaldırabilir ve değiştirebilir. Ayrıca bir Resource Group'ta zaten var olan depoları da yönetebilirler.
- `inherit`: Kaynak Grubu'ndaki üyenin rolü, **organizasyon rolü** ile aynıdır. Örneğin, `write` organizasyon rolüne sahip ve `inherit` ile bir gruba eklenen bir üye, grupta `write` erişimine sahip olur

Ayrıca, Organizasyon yöneticileri organizasyon içindeki **tüm kaynak gruplarını** yönetebilir. Bu, depoların herhangi bir Kaynak Grubu içine veya dışına taşınmasını da içerir.

Resource Groups, organizasyon içindeki özel depoların görünürlüğünü de etkiler:

- Bir Kaynak Grubu'nun parçası olan **özel** bir depo, yalnızca **o Kaynak Grubu'nun üyelerine** görünür.
- **Public** depolar, organizasyonun içinde ve dışında **herkese** açıktır.
- Bir Kaynak Grubu'na ait özel **koleksiyonlar** için de aynı görünürlük kuralları geçerlidir.

## Başlangıç

Organizasyonunuzun ayarlarına gidin, ardından sol menüdeki "Resource Groups" girdisine geçin. Sayfa iki sekmede bölünmüştür: grupların kendilerinin listelendiği ve yönetildiği **Resource Groups** ve organizasyon yöneticilerinin Resource Groups oluşturabilecek kişileri ve belirli organizasyon özelliklerini kullanabilecek üyeleri yapılandırdığı **Access settings**.

    
    

Organizasyon yöneticileri, o sayfadan Resource Group oluşturabilir ve yönetebilir. Organizasyonun ayarlarına bağlı olarak, daha düşük rollere sahip üyelerin de Resource Group oluşturmasına izin verilebilir (aşağıdaki [Kimler Resource Group oluşturabilir](#who-can-create-resource-groups) bölümüne bakın).

Bir Resource Group oluşturup ona anlamlı bir isim verdikten sonra grubun sayfasına yönlendirilirsiniz. Sayfa dört sekme halinde düzenlenmiştir:

- **Genel bakış**: grubun (depo türleri, üye rolleri, otomatik dahil etme durumu ve harcama limiti) özeti ile kaynaklarının ve kullanıcılarının önizlemesi.
- **Kaynaklar**: Grubun depolarının ve koleksiyonlarının tam listesi, ayrıca gruba faturalanan İşler; arama, sıralama ve sayfalama özellikleriyle. Kaynakları gruba buradan eklersiniz.
- **Kullanıcılar**: Grubun üyeleri ve rolleri, arama ve sıralama özellikleriyle. Kullanıcıları eklediğiniz ve rollerini yönettiğiniz yer burasıdır.
- **Ayarlar**: grubun otomatik dahil etme ve harcama limitleri yapılandırması.

    
    

**Kaynaklar** ve **Kullanıcılar** sekmelerinden gruba depolar ve kullanıcılar eklemeye başlayabilirsiniz.

    
    

> [!TIP]
> Bir Resource Group'a kullanıcı eklerken, kullanıcının organizasyonunuza ait e-posta alanıyla eşleşen, organizasyona özgü bir e-posta adresi (ör. `user@your-company.com`) varsa, e-posta adresine göre arama yapabilirsiniz.

Bir deponun yalnızca bir Kaynak Grubu'nun parçası olabileceğini unutmayın. Zaten başka bir Kaynak Grubu'na ait olan bir depoyu eklemeye çalıştığınızda uyarı alırsınız.

## Otomatik katılım

Auto-join, bir Kaynak Grubu'na belirli bir rolde **org üyelerini** otomatik olarak ekler: hem auto-join etkinleştirildiğinde org'da zaten bulunan üyeler hem de gelecekte katılacak yeni üyeler.

Bu, manuel üyelik yönetimi gerektirmeden tüm organizasyonunuz tarafından erişilebilir olması gereken Resource Groups için kullanışlıdır.

### Otomatik katılımı etkinleştirme

- **Arayüz üzerinden**: Kaynak Grubu'nun **Ayarlar** sekmesini açın, **Org üyelerini otomatik dahil et** bölümünde **Tüm org üyelerini otomatik dahil et** seçeneğini işaretleyin ve atayacak rolü seçin. Kullanıcılar sekmesi de oraya bağlantı verir ve otomatik dahil etmenin açık mı kapalı mı olduğunu gösterir.
- **API üzerinden**: [API ile otomatik katılmayı yapılandırma](./programmatic-user-access-control#configure-auto-join-via-api) bölümüne bakın.

    
    

Mevcut bir Resource Group üzerinde auto-join etkinleştirildiğinde, seçilen kapsamla eşleşen mevcut kuruluş üyeleri, yapılandırılan rolde (backfill) gruba **anında eklenir**.

### Otomatik katılım kapsamı

Auto-join şu durumlara uygulanabilir:

- **Tüm kuruluş üyeleri** (varsayılan): `no_access` kuruluş rolüne sahip üyeleri hariç tutmak için **no_access üyelerini dahil et** seçeneğini işaretli bırakmayın.
- **no_access dahil tüm kuruluş üyeleri**: `no_access` kuruluş rolüne sahip üyeler dahil olmak üzere her üyeyi içerebilmek için **no_access üyelerini dahil et** seçeneğini işaretleyin.

`no_access` üyelerinin yalnızca manuel olarak veya başka bir tedarik akışı üzerinden eklendikleri belirli Resource Group'lara erişim sağlamaya devam etmesi gerekiyorsa **yalnızca Read+ üyeleri** kullanın.

### Otomatik katılım ve SCIM

Auto-join ve SCIM yönetimi, aynı Resource Group üzerinde **karşılıklı dışlayıcıdır**. Auto-join, organizasyon üyelerini otomatik olarak eklerken SCIM yönetimi, üyelik kontrolünün yalnızca IdP tarafından yapıldığı anlamına gelir. Bu iki davranış çeliştiğinden:

- SCIM grubuna bağlı bir Resource Group üzerinde otomatik katılımı etkinleştiremezsiniz.
- Otomatik katılım özelliği etkin olan bir Kaynak Grubu'na SCIM grubu bağlayamazsınız.

Bir Resource Group'u otomatik katılımdan SCIM yönetimine (veya tam tersine) geçirmek için önce mevcut ayarı devre dışı bırakın.

## Dış davetler

Resource Groups'u organizasyonunuz dışındaki kullanıcılarla paylaşabilirsiniz. Org yöneticileri bunu, Resource Groups ayarları sayfasındaki **Erişim ayarları** sekmesindeki **Dış davetler** ayarıyla etkinleştirir. Varsayılan olarak kapalıdır ve [yönetilen kullanıcıları](./enterprise-advanced-sso) olan organizasyonlar için kullanılamaz.

Davet edilen kullanıcılar [dış işbirlikçisi](./security-sso-user-management#external-collaborators) olarak katılır:

- Varsayılan olarak `no_access` kuruluş rolünü alırlar, bu nedenle yalnızca ilgili Kaynak Grubu'nun kaynaklarını görürler.
- Kaynak Grubu'nda onları `read` veya `write` rolüyle davet edebilirsiniz.
- Organizasyonunuzun SSO'su ile oturum açmak zorunda değillerdir.

Birini davet etmek için Kaynak Grubu'nun **Kullanıcılar** sekmesini açın ve kullanıcı adıyla ekleyin. Organizasyon üyeleri gruba hemen katılır; dışarıdakiler bir davet alır. Bekleyen davetler, grubun kullanıcıları arasında "Bekleyen" rozeti altında listelenir ve bunları yeniden gönderebilir veya iptal edebilirsiniz. Yalnızca dış işbirlikçileri listelemek için **Dış** filtresini kullanın.

### Harici işbirlikçilerle bir depoyu paylaşın

Kaynak grubu yöneticileri, ayrıca **Ayarlar** sayfasındaki **Dış işbirlikçileriyle paylaş** bölümünden özel bir depoyu paylaşabilir. Bu bölüm, depoyun Kaynak Grubu'nda zaten kimlerin bulunduğunu listeler ve dış işbirlikçilerini davet etmenizi sağlar. Oraya eklediğiniz herkes, yalnızca o depoya değil, Kaynak Grubu'ndaki tüm kaynaklara erişim kazanır.

    
    

Depo henüz bir Resource Group içinde değilse, [Resource Group oluşturabilen](#who-can-create-resource-groups) üyeler, bu bölüm üzerinden bir grup oluşturabilir ve aynı anda işbirlikçileri davet edebilir. **Otomatik dahil etme** varsayılan olarak açıktır: bu özellik, `no_access` rolündeki üyeler hariç olmak üzere, organizasyonun üyelerini [otomatik katılma](#auto-join) yoluyla `inherit` rolüyle yeni gruba ekler; böylece üyeler, depoya mevcut erişimlerini korur. Bu özelliği kapatırsanız, depoyu yalnızca Resource Group'a eklediğiniz kullanıcılar ve organizasyon yöneticileri görebilir.

Harici davetleri API üzerinden de yönetebilirsiniz: [API ile harici işbirlikçileri davet etme](./programmatic-user-access-control#invite-external-collaborators-via-api).

## Kimler Kaynak Grupları oluşturabilir

Varsayılan olarak yalnızca organizasyon yöneticileri yeni Kaynak Grupları oluşturabilir. Organizasyon yöneticileri, Kaynak Grupları ayarları sayfasındaki **Erişim ayarları** sekmesinde **Kaynak Grupları oluşturma için gereken asgari üye rolunu** değiştirerek bunu değiştirebilir.

Kullanılabilir seçenekler şunlardır:
- **Sadece yöneticiler** (varsayılan): yalnızca kuruluş yöneticileri Kaynak Grupları oluşturabilir.
- **Write+**: Write veya Admin rolüne sahip üyeler Resource Group oluşturabilir.
- **Contributor+**: Contributor, Write veya Admin rolüne sahip üyeler Resource Group oluşturabilir.
- **Read+**: `no_access` organizasyon rolüne sahip üyeler hariç olmak üzere, herhangi bir organizasyon üyesi Resource Group oluşturabilir.

Bir yönetici olmayan üye, Arayüz üzerinden bir Resource Group oluşturduğunda, yeni oluşturulan bu grubun **admin**i olarak otomatik eklenir. API üzerinden bu işlem otomatik olarak gerçekleşmez, çünkü API çağrıları başkaları adına grup oluşturabilir. Yönetici olmayan API çağrıları, grubun başlangıç üye listesinde admin rolüne sahip en az bir kullanıcıyı dahil etmelidir.

## İnce tanecikli özellik erişimi

> [!WARNING]
> Bu özellik, Enterprise planı ve üzeri planların bir parçasıdır.

Org yöneticileri, bir organizasyon özelliğinin kimler tarafından kullanılmasına izin verileceğini, depo erişiminden bağımsız olarak da kontrol edebilir. Bu ayar, Resource Groups ayarları sayfasındaki **Access settings** sekmesinde bulunur.

    
    

Aşağıdaki özellikler kısıtlanabilir:

- **Blog**: organizasyon [blog yazılarını](./enterprise-blog-articles) yazma ve yayınlama.
- **Koleksiyonlar**: organizasyon [koleksiyonlarını](./collections) oluşturma ve düzenleme.
- **İşler**: Organizasyona faturalanan [İşleri](./jobs) çalıştırma ve görüntüleme.
- **Inference Endpoints**: organizasyona ait Inference Endpoints'lerin oluşturulması, yönetilmesi ve çağrılması.
- **Çıkarım Sağlayıcıları**: Kuruma faturalanan [Çıkarım Sağlayıcıları](/docs/inference-providers) istekleri.

Her biri için kimlerin erişim yetkisine sahip olduğunu seçebilirsiniz:

- **Herkes** (varsayılan): organizasyon rolüne bağlı olarak organizasyonun her üyesi.
- **Sadece kuruluş yöneticileri**: yalnızca kuruluş yöneticileri erişim yetkisini korur.
- **Belirli kaynak grupları**: grup içindeki rollerine bağlı olarak yalnızca seçilen Kaynak Grupları üyeleri.

Kuruluş yöneticileri, seçilen seçenekten bağımsız olarak her zaman tüm özelliklere erişim yetkisine sahiptir.

Belirli kaynak gruplarına kısıtlanan bir özellik, özelliğin **kimlerin** kullanabileceğini değil, **nerede** kullanılacağını kontrol eder. Seçilen grupların üyeleri, özelliği organizasyonun herhangi bir yerinde (örneğin, hiçbir kaynak grubuna ait olmayan bir koleksiyon oluşturmak gibi) kullanmaya devam edebilirken, diğer üyeler özelliğe tamamen erişimlerini kaybeder. Kısıtlama asla ek izin vermez: bir üyenin yapabilecekleri, yine organizasyon rolü tarafından belirlenir.

Erişimi olmayan üyeler, artık hem API hem de arayüz üzerinden organizasyon bağlamında bu özelliği kullanamaz. API istekleri bir yetkilendirme hatası döndürür. Kişisel hesaplarında veya başka bir organizasyonda durumları değişmez.

## Maliyet atfı

> [!WARNING]
> Bu özellik, Enterprise planı ve üzeri planların bir parçasıdır.

Resource Groups, hesaplama hizmetleri için maliyet atfı birimi olarak da görev yapar. Hesaplama bir resource group'a faturalandırıldığında, maliyetler grup başına ayrı ayrı izlenir ve bu da ekipler arası harcamaları anlamayı kolaylaştırır.

- **Spaces**: maliyet, Space'in ait olduğu kaynak grubuna otomatik olarak atfedilir.
- **İşler**: `namespace` değerini sahip olan organizasyon olarak ayarlayın ve kaynak grubunun kimliğini Python'da `resource_group_id`, CLI'da `--resource-group-id` veya HTTP istek gövdesinde `resourceGroupId` kullanarak iletin. [Kaynak grubuna fatura kesme](./jobs-pricing#bill-to-a-resource-group) bölümüne bakın.
- **Çıkarım Sağlayıcıları**: kaynak grubunun kimliğini `X-HF-Bill-To` başlığıyla (veya SDK'da `bill_to` parametresiyle) iletin. [Team ve Enterprise kuruluşları için faturalandırma](/docs/inference-providers/pricing#billing-for-team-and-enterprise-organizations) bölümüne bakın.
- **Inference Endpoints**: maliyet, model deposunun ait olduğu kaynak grubuna otomatik olarak atfedilir. Yerleşik Inference Endpoints kataloğundan doğrudan örneklenen uç noktalar şu anda desteklenmemektedir.

Kaynak grupları için maliyet atfı verilerini almak üzere ayrılmış API uç noktasını kullanabilirsiniz.

## Harcama limitleri

> [!WARNING]
> Bu özellik, Enterprise planı ve üzeri planların bir parçasıdır.

Maliyetleri takip etmenin yanı sıra, bunlara bir üst sınır koyabilirsiniz. Organizasyon yöneticileri ve kaynak grubu yöneticileri, grubun **Ayarlar** sekmesindeki **Harcama sınırları** altında aylık harcama limitleri belirleyebilir.

    
    

İki tür sınır mevcuttur, her ikisi de ABD doları (USD) cinsinden ifade edilir:

- **Toplam (tüm ürünler)**: grubun birleşik hesaplama harcamasını sınırlar.
- Toplamın yanı sıra **Inference Providers**, **Spaces**, **Jobs** ve **Inference Endpoints** için ürün bazında bir sınır.

Sınır tanımlamak istemediğiniz bir alanı boş bırakın. Hem toplam sınır hem de ürün başına sınır geçerliyse, ikisinin daha sıkı olanı uygulanır.

Sınırlar, geçerli takvim ayına ait grup harcamasına uygulanır; bu nedenle limitine ulaşan bir grup, bir sonraki ayın başında veya bir yönetici limitin artırmasıyla birlikte yeniden etkinleştirilir.

### Bir sınıra ulaşıldığında ne olur

Kaynak grubuna faturalandırılan yeni kullanım, bir yetkilendirme hatasıyla reddedilir:

- **Inference Providers**: gruba faturalandırılan istekler reddedilir.
- **İşler**: Grup içinde bir işin oluşturulması, yeniden gönderilmesi veya devam ettirilmesi reddedilir; planlanmış işler de dahildir.
- **Spaces**: gruptaki bir Space'in ücretli donanıma yükseltilmesi reddedilir.
- **Inference Endpoints**: grubun maliyetine neden olan uç noktalara yapılan istekler reddedilir.

Grubun zaten çalışmakta olan iş yükleri de, sınır aşıldıktan kısa bir süre sonra durdurulur:

- Ücretli **Spaces** duraklatılır. Donanımsız (ücretsiz) donanımda çalışan Spaces ve [donanım hibe](./spaces-gpus) kapsamında çalışan Spaces etkilenmez.
- **Jobs** iptal edilir ve durdurma nedenleri `Resource group spend limit reached` olarak işaretlenir.

Limitin artırılması veya yeni bir ayın başlaması, üyelerin yeni iş yüklerine yeniden başlamasına olanak tanır. Durdurulan Spaces ve Jobs otomatik olarak yeniden başlatılmaz.

Harcama limitlerini programatik olarak da ayarlayabilirsiniz, bkz. [API üzerinden harcama limitleri ayarlama](./programmatic-user-access-control#set-spend-limits-via-api).

## Kaynak Grupları API

Kaynak gruplarını listeleyebilir ve kullanıcılara ekleyebilirsiniz (veya bir üyenin kuruluş rolünü ve kaynak grup atamalarını değiştirebilirsiniz) Hub API'si aracılığıyla. Tam referans, örnekler ve toplu iş akışları için [Programatik Kullanıcı Erişim Denetimi Yönetimi](./programmatic-user-access-control) kılavuzuna bakın.