Cloudflare, AI agentlerine en az yetki ilkesine uygun erişim için Worker başına roller ekledi

Cloudflare, Workers için ince ayarlı yetkilendirme ekledi

Cloudflare, Workers için kaynak düzeyinde yetkilendirme özelliğini kullanıma sundu; böylece hesap sahipleri bir ekip arkadaşına, CI pipeline'ına veya AI agent'ine hesaptaki başka hiçbir şeyi açığa çıkarmadan tek bir uygulamaya erişim verebiliyor. Cloudflare blog'una göre bu özellik bugünden itibaren tüm müşterilerin kullanımına sunuldu.\n Şirket bu değişikliği Developer Platform üzerinde kimin ve neyin geliştirme yaptığındaki dönüşüm çerçevesinde konumlandırıyor. Agentler giderek daha fazla uygulama dağıtıp hata ayıkladıkça, hesap genelindeki geniş kapsamlı kimlik bilgileri bir risk haline geliyor: ihtiyacından fazla erişimi olan bir agent, üretim ortamında istenmeyen değişiklikler yapabilir. Yetkileri tek bir Worker ile sınırlamak, bu etki alanını kontrol altına almayı amaçlıyor.

Dört yeni rol

Güncelleme, kaynak bazında uygulanabilen dört rol getiriyor:

• Metadata Read-Only: Temelindeki ürün içeriğine erişim olmadan kaynak listelerini, ayarları ve metrikler, loglar ve trace'ler gibi gözlemlenebilirlik verilerini görüntüler. Kaynak kodu açığa çıkarmadan hata ayıklama için uygun.
• Content Read-Only: Worker kodu veya D1 veritabanı içeriği gibi ürün içeriğini okur, ancak değiştiremez veya dağıtamaz. Kod incelemesi için uygun.
• Editor: İçeriği okuyup yazabilir ve ayarları güncelleyebilir, ancak kaynak oluşturamaz veya silemez. İnsanlar, agentler veya CI/CD sistemleri tarafından yapılan dağıtımlar için uygun.
• Admin: Yeniden adlandırma, silme ve erişim verme dahil kaynak üzerinde tam kontrol sağlar, ancak yine de tek bir Worker ile sınırlıdır.

Cloudflare, iki uç nokta yerine bilinçli olarak dört seviyede karar verdiğini belirtiyor. Çok geniş roller yöneticileri aşırı yetki vermeye zorlar ve en az yetki ilkesini zayıflatır; uzun bir bireysel izin listesi ise hangilerinin verilmesi gerektiğini bilebilmeyi zorlaştırır. Bu dört rol, pratik güven seviyeleriyle eşleşiyor: içeriği görmeden hata ayıklama, değiştirmeden okuma, silmeden değiştirme ve tam yönetim.

Kapsamlar, kullanıcılar ve API token'ları

Her rol üç kapsamdan birinde uygulanabilir: tüm Developer Platform, tüm Workers gibi tek bir ürün veya tek bir Worker gibi tek bir kaynak. Erişim bir kullanıcıya atanabilir — bu durumda kullanıcı dashboard'a giriş yaptığında yalnızca kendisine verilen Worker'ı görür — veya aynı kapsamlamayla bir API token'ına gömülebilir; agentler için öngörülen yol bu.

Cloudflare, bunun önemli olduğu çeşitli iş akışlarını ele alıyor. Tek bir Worker'a kapsamlı bir agent, GraphQL API üzerinden analytics sorgulayabilir, log ve trace'leri inceleyebilir; ancak bu istekler yalnızca erişebildiği Worker'lara ait verileri döndürür ve agent hiçbir zaman kaynak kodu görmez. Bir kod inceleme agent'i, değişiklik dağıtamadan bir Worker'ın kodunu okuyabilir. Bir CI/CD pipeline'ı, tek bir Worker'a kapsamlı bir Editor token'ı tutabilir; böylece sızan veya hatalı yapılandırılmış bir token yine de dağıtım yapabilir ama uygulamayı silemez veya hesaptaki diğer Worker'lara dokunamaz.

Routes ve Durable Objects Worker'ı takip eder

İki uç durum özel işlem görüyor. Bir Worker'a hangi host name'lerin ulaşacağını belirleyen Routes ve Custom Domains değiştirilirse üretim trafiğini yönlendirebilir veya bozabilir; bu yüzden bunları değiştirmek, geniş kapsamlı zone erişimi yerine hem Worker'a Editor erişimi hem de zone için Workers Routes iznini gerektirir. Route bir kez yapılandırıldıktan sonra, dağıtım bu bağlantıyı değiştirmediği sürece, zone'a hiçbir erişim olmadan Worker'ın yeni sürümleri dağıtılabilir; yani bir CI sistemi, domain, veritabanı veya depolama izinlerini de tutmadan kod yayınlayabilir.

Durable Objects kendi başına rol taşımaz; erişim, onları uygulayan Worker'dan türetilir. Metadata Read-Only, bir Durable Object'in metriklerini, loglarını ve trace'lerini açığa çıkarır ama depolanan verilerini göstermez — bunun için Editor rolü gerekir, çünkü Durable Objects Data Studio bu verileri doğrudan sorgulayıp değiştirebilir.

İnsanlar ve agentler için daha iyi hata mesajları

Dar yetkiler kaçınılmaz olarak reddedilen işlemlere yol açar. Cloudflare API'leri artık yalın bir 403 Forbidden döndürmek yerine, işlemin tam olarak hangi izni gerektirdiğini açıklayan dokümantasyona yönlendiriyor; böylece hem mühendisler hem de agentler neyin eksik olduğunu anlayıp talep edebilir.

Şirket ayrıca aynı rol modelini D1, R2 ve KV dahil diğer Developer Platform ürünlerine genişletmeyi planlıyor ve metadata ile içerik arasındaki ayrımın sürdürüleceğini, örneğin birinin bir veritabanının satırlarını okumadan ayarlarını inceleyebileceğini belirtiyor.

Neden önemli

En az yetki ilkesi her zaman bir güvenlik gerekliliği olmuştur, ancak AI agentleri bunu operasyonel olarak acil hale getiriyor: Hesap genelinde kimlik bilgileriyle donatılmış otonom bir sistem, dalgın bir insanın yapacağından çok daha fazlası üzerinde harekete geçebilir. Cloudflare'ın bu hamlesi, erişim kontrolünü yalnızca insanlar için değil, agentler ve pipeline'lar için de boyutlandırılmış bir şeye dönüştürüyor ve kaynak bazlı API token'ı yaklaşımı, diğer platformların da muhtemelen kopyalayacağı bir şablon. İyileştirilmiş 403 yanıtları ise küçük ama anlamlı bir detay; çünkü hangi izne sahip olmadığını okuyabilen agentler çoğu zaman sessizce başarısız olmak yerine kendini düzeltebiliyor.