GitHub Apps’te Least Privilege İçin Yeni İzinler
GitHub, GitHub Apps tarafında bir dizi iyileştirme duyurdu. Değişiklikler klasik PAT’lerden uzaklaşmayı kolaylaştırmayı, uygulamaların gereğinden fazla hassas izin istemesini önlemeyi ve app yönetimini daha yönetilebilir kılmayı hedefliyor. Pratikte depo oluşturmak için artık tam depo yönetimi yetkisi gerekmiyor, kurulum kapsamı API üzerinden otomatikleştirilebiliyor, depo yöneticileri de kuruluşta zaten onaylanmış uygulamaları kendi depolarına ekleyebiliyor.
İki yeni fine-grained depo izni
Hem fine-grained PAT’ler hem de GitHub Apps için kullanılabilen iki yeni depo izni eklendi:
repository_creation:write: İznin verildiği hesapta depo oluşturma yetkisi verir.installation_repositories:write: İlgili deponun kuruluştaki bir kuruluma eklenmesine veya kurulumdan çıkarılmasına izin verir.
Depo oluşturmak için artık repository_administration gerekmiyor
Önceden bir uygulamanın ya da token’ın depo oluşturabilmesi için repository_administration:write izni gerekiyordu. Bu izin oluşturmanın yanında silme ve transfer gibi depo yönetimi yeteneklerini de kapsıyordu. Yöneticiler de bu yüzden ya izni isteyen uygulamaları reddediyor, ya bu izne sahip PAT’leri yasaklıyor, ya da fazla yetki riskini kabul etmek zorunda kalıyordu.
Yeni repository_creation:write izni yalnızca depo oluşturma yeteneğini verdiği için least privilege yaklaşımına uyuyor. Depo oluşturulduğunda onu oluşturan uygulamaya veya kullanıcıya depoya erişim veriliyor. Bu izni kullanan bir uygulamanın kurulumu için yine de kuruluş yöneticisinin onayı gerekiyor.
Depo oluşturma akışları için GitHub, kuruluş içinde oluşturma, şablondan oluşturma, mevcut kullanıcı için oluşturma, fork ile oluşturma ve GraphQL üzerinden oluşturma senaryolarının API dokümanlarını referans gösteriyor.
Kurulum kapsamını app veya fine-grained PAT ile yönetme
Kuruluş düzeyinde “bir kuruluma depo ekleme” API’si ve buna karşılık gelen kaldırma API’si artık GitHub Apps ve fine-grained PAT’leri destekliyor. Daha önce bu uç noktalar yalnızca kaba taneli (coarse-grained) repo kapsamıyla çalışıyordu.
Bu API’ler yeni depo düzeyindeki installation_repositories:write iznini kullanıyor. Bir depoda bu izne sahip olmak, çağrıyı yapan tarafın o depoyu kuruluştaki herhangi bir kuruluma eklemesine veya çıkarmasına imkan tanıyor. Çağrıyı yapan bir kullanıcıysa ek olarak kuruluş sahibi ya da söz konusu depoda yönetici olması gerekiyor.
Böylece kuruluşlar, hangi depoların hangi GitHub App’lere açık olacağını kontrol eden otomasyonları geniş yetkili bir yönetici PAT’ine bağımlı kalmadan kurabiliyor.
Depo yöneticileri onaylı app’leri kendi depolarına ekleyebiliyor
GitHub, kuruluş düzeyinde erişim isteyen uygulamaların depo yöneticisi tarafından depo bazında kurulmasını eskiden koşulsuz engelliyordu. Bu kısıt, uygulamanın kuruluşta zaten kurulu olduğu durumda gevşetildi. Kuruluş sahibi o kuruluş düzeyindeki erişimi bir kez onayladıysa depo yöneticileri mevcut kurulumu düzenleyip kendi depolarını uygulamaya ekleyebiliyor, ayrıca kuruluş sahibi onayı istenmiyor.
Uygulama kuruluş düzeyindeki erişime zaten sahip olduğu için aynı kuruluştaki başka bir depoya eklenmesi ne bu erişimi genişletiyor ne de depo yöneticisine ek ayrıcalık kazandırıyor; GitHub’ın gerekçesi bu.
Yeni repository_creation izninin eklenmesiyle birlikte kuruluş sahibi onayı gerektiren hassas izin kümeleri üçe çıktı:
- Tüm kuruluş düzeyindeki izinler
- Depo yönetimi (repository administration)
- Depo oluşturma (repository creation)
Depo yöneticilerinin kendi depolarına uygulama eklemesini tamamen engellemek isteyen kuruluşlar için GitHub, dokümantasyondaki “GitHub App kurulumunu kuruluş sahipleriyle sınırlama” bölümünü işaret ediyor.
offline_access ile kısa ömürlü token’lara kademeli geçiş
GitHub Apps artık OAuth uygulamalarında olduğu gibi offline_access kapsamını destekliyor. GitHub Apps varsayılan olarak kısa ömürlü, dönen (rotating) token’lar kullanıyor; ancak bazı geliştiriciler kolaylık olsun diye süre sonunu devre dışı bırakmış, sonradan yeniden etkinleştirmekte zorlanmıştı.
Bu destek, süresi dolan kullanıcı erişim token’larına kademeli geçişi mümkün kılıyor. Geliştiriciler token süre sonunu test ve aşamalı yayım için etkinleştirebiliyor, tüm kullanıcıları aynı anda süreli token’lara geçirip mevcut istemcileri bozmak zorunda kalmıyor.
offline_access talep edildiğinde uygulama, süresi dolan erişim token’ının yanında bir refresh token alıyor. Bu yalnızca ilgili kimlik doğrulamayı etkiliyor, gelecekteki oturumlara bir etkisi olmuyor. GitHub Apps tarafında scope parametresinin bunun dışında bir işlevi yok, izinler hala uygulama kaydında statik olarak seçiliyor.
GitHub, offline_access desteğinin GHES 3.23’te yer aldığını belirtiyor.
Private ve internal app’lerin detaylarını okuma
GitHub Apps artık “Get an app” API’sini kullanarak private ve internal GitHub App’lerin detaylarını çekebiliyor; bunun için ortak bir sahiplik ilişkisi bulunması gerekiyor. İzin verilen erişim desenleri şöyle:
- Public app’ler: Herhangi bir başka app detayları çekebilir. Önceden de mümkün olan erişim seviyesi buydu.
- Aynı kuruluştaki app’ler: Aynı sahibi paylaşıyorlarsa görünürlükten bağımsız olarak birbirlerinin detaylarını çekebilir.
- Aynı enterprise içindeki internal app’ler: Bir internal app’in detayları, kuruluş sınırlarını aşsa bile aynı enterprise içindeki başka bir app tarafından çekilebilir.
- Enterprise’dan kuruluşa erişim: Enterprise’a ait bir app, aynı enterprise içindeki kuruluşların sahip olduğu app’lerin detaylarını çekebilir.
Bu değişiklikle GitHub, kuruluşların ve enterprise’ların GitHub App denetim ve yönetim işlerini daha fazla otomatikleştirmesini hedefliyor.
GitHub Apps için ayrı bir Credentials sekmesi
GitHub App kimlik bilgileri artık uygulama yapılandırmasının geri kalanıyla aynı sayfada satır arasında değil, ayrı bir Credentials sekmesinde yönetiliyor. GitHub bu düzenlemenin kimlik bilgilerini bulmayı ve yönetmeyi kolaylaştırdığını, ayrıca planlanan workload federation kimlik bilgileri için yer açtığını belirtiyor.
GHES tarafında durum
Duyuruya göre bu iyileştirmeler GHES 3.24’te kullanılabilir olacak; tek istisna, GHES 3.23’e dahil edilen offline_access desteği. GitHub ayrıca geri bildirimleri GitHub Community üzerinden toplamayı sürdürüyor.
Kaynaklar ve İleri Okuma
- GitHub App improvements for least privilege and management (The GitHub Blog changelog)
- REST API: Repositories uç noktaları
- REST API: Repository forks (Enterprise Cloud)
- GraphQL referansı: Repositories
- REST API: GitHub App installations
- REST API: Apps (Get an app)
- OAuth App ve GitHub App kurulum taleplerini sınırlama
- Üçüncü taraf bir GitHub App’i kurma
- Kullanıcı erişim token’larını yenileme
- Bir GitHub App’i public veya private yapma
- GitHub Roadmap: workload federation
- GitHub Enterprise’a Üçüncü Parti App Kurulumu Geldi
- GitHub Apps Artık Enterprise Faturalama Verisine Erişebilir
- Least Privilege Ajanlar: Güvenliği Baştan Kurmanın Yeni Yolu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder