Oso Cloud'u Tiny satın aldı, ekibin büyük kısmı Temporal'a geçti; kullanıcılar göç seçeneklerini değerlendiriyor

Oso Cloud'un yeni sahibi var

Politikaları Polar dilinde yazılan yetkilendirme servisi Oso Cloud, dev.to'da yayımlanan bir yazıya göre Tiny tarafından satın alındı ve anlaşma 1 Ekim'de tamamlandı. Yazıya göre Oso, cloud ürününün normal şekilde çalışmaya devam edeceğini ve duyurudaki hiçbir şeyin müşterileri hemen göç etmeye zorlamadığını belirtti. Aynı zamanda Oso ekibinin büyük kısmı Temporal'da görevler üstlendi.

dev.to yazısı, kendini Permit'in pazarlama ekibinin bir üyesi olarak tanıtan biri tarafından kaleme alındı ve Permit rakip bir yetkilendirme ürünü satıyor; dolayısıyla göç tavsiyeleri bariz bir ticari çıkar taşıyor. Yine de, süreçle ilgili öneriler bir yetkilendirme sağlayıcısını yeniden değerlendiren herkes için büyük ölçüde geçerli.

Ekipler Polar politikalarını neden yeniden okuyor

Yazara göre birçok Oso kullanıcısı bu ay, satın alma haberinin ışığında yapılandırmalarını yeniden gözden geçiriyor. Yazarın belirttiğine göre atlanan adım en cazip olmayan adım: mevcut Polar politikalarını dışa aktarmak ve sağlayıcı değerlendirmelerine başlamadan önce her kuralı sınıflandırmak.

Önerilen sınıflandırma şöyle:

• Bir resource bloğu içinde roller atayan kurallar RBAC kapsamına girer.
• Varlıklar arasındaki ilişkilerden doğan roller ReBAC'tır; örneğin bir kullanıcının yalnızca üst bir kuruluşa üye olduğu için sahip olduğu repository-reader rolü. Böyle bir kuralı başka bir sisteme taşımak, arkasındaki ilişki verisini de göç etmeyi ya da sürekli senkronize etmeyi gerektirir.
• Kullanıcı veya kaynak özniteliklerini inceleyen koşullar ABAC'tır ve mimari bir karar dayatırlar: öznitelik verisi ya önceden senkronize edilebilir ya da her yetkilendirme kontrolüyle birlikte sağlanabilir.

Yazara göre list filtering, envanterde kendi başına bir kalem hak ediyor. Bir kullanıcının tek bir belgeyi açıp açamayacağına cevap vermek ile bir kullanıcının hangi belgeleri okuyabileceğine cevap vermek, bir yetkilendirme sistemini farklı şekillerde zorlar; bir yedek ürün ilki sorunsuz yürütürken ikincisinde zorlanabilir.

Kesme işleminden önce paralel çalıştırma

Yazının son önerisi hedef neresi olursa olsun geçerli: mevcut sistemi ve yedeği uzun bir süre yan yana çalıştırın, ikisinin ayrıştığı her durumu günlüğe kaydedin ve geçişi ancak ayrışma günlüğü sıfıra ulaştığında tamamlayın. Yazar ayrıca Permit'in bu politika kalıplarının daha kapsamlı bir eşleştirmesini kendi platformu için kod örnekleriyle yayımladığını belirtiyor.

Neden önemli

Yetkilendirme kararları, bir uygulamanın servis ettiği neredeyse her isteğin kritik yolunda yer alır; bu da yetkilendirme göçünü bir platform ekibinin girişebileceği en riskli refactor'lardan biri haline getirir. Mühendislik ekibinin büyük kısmının başka bir şirkete geçtiği bir sırada tamamlanan bir satın alma, günlük operasyonlar şimdilik değişmemiş olsa bile Oso Cloud müşterileri için uzun vadeli risk tablosunu değiştiriyor.

dev.to yazısından çıkan pratik ders bu olayın ötesine genelleniyor: politikalarınızı önce RBAC, ReBAC ve ABAC üzerinden sınıflandırın ve list filtering gereksinimlerinizi ayrıca kayıt altına alın; çünkü hangi ürünlerin sisteminize gerçekten uyabileceğini belirleyen şey bir özellik listesi değil, bu karışımdır. Akılda tutulması gereken bir uyarı: böyle anlarda en yüksek sesle duyurulan göç rehberliği genellikle ayrılan müşterileri kendine çekmeye çalışan satıcılardan gelir; bu nedenle buna göre tartılmalıdır.