Cloudflare, Cloudflare Access for Workers’ı kullanıma sunduğunu duyurdu. Bu araç seti, bir Access politikasının doğrudan bir Worker uygulamasına veya hesap içindeki tüm Workers uygulamalarına bağlanmasını sağlıyor. Bu bağlantı sayesinde uygulamalar varsayılan olarak şirketin oturum açma sisteminin arkasına alınıyor; böylece her geliştiricinin erişim kontrollerini ayrı ayrı yapılandırmayı hatırlamasına gerek kalmıyor.
Bu adım, çalışanların yapay zekâ araçlarının desteğiyle uygulamalar oluşturup daha hızlı yayımlayabilmesi çerçevesinde geliyor. Cloudflare, bu hızın dahili uygulamaların veya özel verilerin yanlışlıkla genel internette yayımlanmasına da yol açabileceğini düşünüyor. Bu nedenle şirket, yeni araçları Workers üzerinde barındırılan uygulamaların korunmasını dağıtım sürecinin bir parçası hâline getirecek şekilde tasarladı.
Erişim yönteminden bağımsız uygulama koruması
Access bir Worker üzerinde etkinleştirildiğinde Cloudflare, herhangi bir isteğin uygulama koduna ulaşmasından önce kimlik doğrulamasını zorunlu kılıyor. Bu durum, kullanıcı uygulamaya özel bir alan adı, yol, workers.dev alt alan adı veya önizleme adresi üzerinden erişse de geçerli oluyor.
Daha önce Access yapılandırması ana bilgisayar adı düzeyinde yapılıyordu. Bu da kullanıcının Worker’a erişebileceği her alan adı için ayrı politikalar oluşturulması anlamına geliyordu. Yeni bir özel alan adı eklemek, önce politikanın güncellenmesini gerektiriyordu; aksi hâlde bu alan adına kimlik doğrulaması olmadan erişilebiliyordu. Artık politika doğrudan Worker’a bağlanıyor ve buna bağlı alan adları ile URL’ler otomatik olarak korunuyor.
Koruma kapsamı ihtiyaca göre seçilebiliyor:
- Önizlemeler için kullanılan workers.dev adresleri veya özel alan adları dâhil olmak üzere yalnızca önizleme adreslerinin korunması.
- Özel alan adlarını, yolları, workers.dev alan adlarını ve önizleme adreslerini kapsayacak şekilde uygulamayla ilişkili tüm ana bilgisayar adlarının korunması.
Hesap düzeyinde varsayılan politika
Çok sayıda Workers uygulamasını yöneten ekipler, Access politikasını hesap düzeyinde bir kez yapılandırabiliyor. Böylece tüm mevcut ve gelecekteki uygulamalar oluşturuldukları andan itibaren özel hâle geliyor. Ayrıca politikanın önizleme trafiğini, üretim trafiğini veya her ikisini kapsayıp kapsamayacağı belirlenebiliyor.
Yalnızca önizlemeler seçeneği, üretim ortamında herkese açık tutulması istenen ancak geliştirme sürümlerinin açığa çıkmasının engellenmek istendiği uygulamalar için uygun olabilir. Cloudflare ayrıca, herkese açık olması gereken belirli bir Worker için hesap politikasının geçersiz kılınmasına olanak tanıyor.
Kapsamlı bir politikaya ihtiyaç duymayanlar ise Access’i doğrudan tek bir Worker üzerinde uygulayabiliyor. Worker arayüzündeki yeni Access sekmesi, uygulama için geçerli politikaları gösteriyor. Birden fazla politika bulunduğunda daha özel olan politika öncelik kazanıyor. Sıralama şu şekilde: ana bilgisayar adı politikaları, ardından Worker politikaları ve son olarak hesap politikaları.
Kullanıcı kimliğinin uygulama kodu içinde kullanılması
Access ayrıca her isteği uygulamaya gönderen kullanıcının e-posta adresi, adı ve grupları dâhil olmak üzere kimliğinin öğrenilmesini sağlıyor. Cloudflare, bu verilerin içeriği kişiselleştirmek, yetkilendirmeleri uygulamak veya her kullanıcı için etkinlik kaydı tutmak amacıyla kullanılabileceğini belirtiyor.
Kimlik bilgileri Worker’a ait ctx bağlam nesnesinde, özellikle ctx.access üzerinden görünüyor. Uygulama, kimliği doğrulanmış kullanıcının kimliğini almak için ctx.access.getIdentity() çağrısını kullanabiliyor. Böylece JSON Web Token doğrulamasını; token’ı ayrıştırma, imzasını doğrulama ve taleplerini çıkarma gibi işlemlerle manuel olarak gerçekleştirmeye gerek kalmıyor.
Access, kuruluşun mevcut kimlik sağlayıcısının bağlanmasını destekliyor. Ayrıca erişim belirli e-posta adreslerine, e-posta alan adlarına veya gruplara göre sınırlandırılabiliyor. Temsilciler için erişim, hizmet token’ları aracılığıyla verilebiliyor.
Yerel test ve dahili platformlar
Kimlik davranışı, kimliği doğrulanmış bir kullanıcıyı taklit etmek üzere wrangler.jsonc dosyasına Access yapılandırması eklenerek wrangler dev ile yerel olarak test edilebiliyor. Böylece geliştirici, yapılandırmadaki e-posta adresini değiştirip dağıtımdan önce her kullanıcı için uygun içeriğin görüntülendiğini doğrulayabiliyor.
Cloudflare ayrıca sürükle ve bırak yöntemiyle statik sitelerin yayımlanmasını sağlayan, açık kaynaklı bir dahili platform örneği sundu. Bu platformda yayımlanan her Worker varsayılan olarak özel hâle geliyor. Bu mimari, Workers for Platforms’tan yararlanıyor. Buna göre bir ad alanı içindeki uygulamaların trafiği, dağıtılmış tek bir Worker üzerinden geçiyor. Access politikası bu Worker’a uygulandığında, onun üzerinden yayımlanan uygulamalar varsayılan olarak özel hâle geliyor.
Kullanılabilirlik ve teknik yapı
Özellik artık kontrol paneli üzerinden herkesin kullanımına sunuldu. Başlangıç için Cloudflare Access for Workers belgeleri de sağlanıyor. Yeni özellik, Rust kullanılarak oluşturulan ve Cloudflare’ın uç altyapısında çalışan modüler bir ara proxy olan FL2’ye dayanıyor.
Access’i ana bilgisayar adı yerine Worker düzeyinde etkinleştirebilmek için Cloudflare, Workers yönlendirmesini yürütülmesinden ayırdı ve yönlendirme mantığını Access’ten önceki bir aşamaya taşıdı. Şirket, iyi tanımlanmış modüllere ve sıralı aşamalara sahip FL2 sisteminin bu değişikliği yönetmesine yardımcı olduğunu belirtiyor. Her bölüm girdilerini ve çıktılarını sabit biçimde ilan ediyor; bu da yeniden yapılandırma sırasında derleyicinin aşamalar arasındaki hatalı etkileşimleri tespit etmek için kullanılmasını sağladı.