Mikro hizmetler kullanıcı mı olmalı?

Mikro hizmetlerin sınırlı izinlere sahip olmasını sağlarken, kullanıcıları bir mikro hizmet mimarisinde yetkilendirmenin en iyi yolunu belirlemeye çalışıyoruz. Mimarimiz, JWT jetonlarının yayınlanması için merkezi bir yetkilendirme hizmeti kullanmaktadır.

Aşağıdaki gereksinimlere sahibiz:

1. Kullanıcılar belirli rolleri yerine getirmekle sınırlı olmalıdır. örneğin bir kullanıcı yalnızca sahip olduğu içeriği oluşturabilmeli / değiştirebilmeli / okuyabilmelidir.

2. Mikro hizmetler yalnızca gereksinim duydukları izinlerle sınırlı olmalıdır. örneğin, yalnızca başka bir hizmetten veri okuması gereken bir mikro hizmetin, söz konusu hizmete veri yazması açıkça yasaklanmalıdır.

Örnek olarak, kullanıcıların bir resim deposu hizmetine resim yükleyebileceği bir sistemimiz olduğunu varsayalım. Resimleri otomatik olarak bir konumla etiketleyen bir etiketleme hizmetimiz var. Kullanıcılar sadece kendi resimlerini CRUD. Etiketleme hizmeti, resim deposu hizmetinden herhangi bir görüntüyü okuyabilir, ancak değiştiremez / silemez.

JWT jetonlarını kullanarak yukarıdakilere ulaşmanın iyi bir yolu nedir? Tartıştığımız bazı çözümler:

1. Resim saklama hizmeti, biri harici olarak kullanılabilen (kullanıcı CRUD erişimi veren) ve biri dahili olarak kullanılabilen (dahili salt okunur erişim sağlayan) 2 API sunar. Esnek görünmüyor - başka bir dahili hizmetin tüm görüntülere okuma / yazma erişimi gerektirmesi gerekiyorsa (örneğin, müstehcen görüntüleri otomatik olarak silen)?

2. Kullanıcının JWT'sinde, biri CRUD_OwnImages, diğeri READ_ForAnalysis olmak üzere iki izin ayarladık. Etiketleme hizmeti, kullanıcının READ_ForAnalysis izinlerine sahip olup olmadığını görebilir ve varsa uygun isteği yapabilir. Kullanıcının kendi resimlerinde CRUD işlemleri için CRUD_OwnImages olup olmadığını kontrol eden başka bir mikro hizmetimiz var. Bu, kullanıcının ihtiyaç duyduğu eylemlerle sınırlı olmasını sağlamak için her bir mikro hizmetin sorumluluğunu üstlenir. Görüntü deposunun bu mikroişlemi bu yaklaşımla kısıtlamanın bir yolu yoktur, bu nedenle potansiyel olarak kesintili ve hataya yatkındır.

3. Etiketleme mikro hizmetini, READ_ForAnalysis ile izin olarak kendi kullanıcısına veriyoruz. Daha sonra, etiketleme hizmeti resim deposundan resim istediğinde, bunlara erişim izni verilir, ancak bunların değiştirilmesi yasaktır. Kullanıcının kullanıcısı yalnızca CRUD_OwnImages iznine sahiptir, bu nedenle yalnızca ön ucundan resimlerini alabilir ve bunlara erişebilir. Başka bir hizmetin tüm verilere CRUD ihtiyacı varsa, ona CRUD_AllData veya benzeri bir şey verebiliriz. Her hizmetin artık kendi verilerinden (bu mantığın birden çok hizmette çoğaltılmasından ziyade) sorumlu olması nedeniyle bu yaklaşımı seviyoruz, ancak hizmet hem kullanıcı izinleri hem de mikro hizmet izinleri gerektiriyorsa ne olur? İki JWT jetonunu (hem kullanıcının hem de mikro hizmetin) güvenli bir şekilde gönderebilir miyiz? İzinleri güvenli bir şekilde birleştirmenin ve göndermenin bir yolu var mı? Örneğin

Kullanıcı bilgilerinin daha aşağı yönde (2 veya 3 mikro servis uzakta) gerekli olması durumunda sorun daha da kötüleşir. Kendilerini ihtiyaç duydukları eylemlerle sınırlamanın ve bunu açık hale getirmemenin bireysel mikro hizmetlere bağlı olduğunu varsayıyor muyuz?

Genel olarak, mümkün olduğunca çok sayıda işlem gerçek bir insan kullanıcıya bağlanmalıdır. İnsanları doğru bir şekilde kimlik doğrulaması yapmaya zorlar, tek bir tutarlı yetkilendirme stratejisi için zorlar ve uyumlu bir denetim izi sağlamanın önemli bir parçasıdır.

Ve genel olarak, mikro hizmetlerle üç tür senaryo var:

1. Kullanıcı içeri girer, bir fotoğraf yükler ve etiketlenmesi gerekir. Harika. Fotoğraf hizmeti, JWT boyunca etiketleme hizmetine geçebilir (veya bağımlılığınızın yönüne bağlı olarak tersi) ve kullanıcı alt işlemi yapma haklarından yoksunsa, uygun eylemi gerçekleştirirsiniz (fotoğrafı etiketsiz olarak yükleyebilirsiniz) , belki hatayı döndürün, belki başka bir şey).

2. Kullanıcı içeri girer, bir fotoğraf yükler ve etiketlenmesi gerekir ... ancak şimdi değil. Güzel. Fotoğrafı artık normal şekilde ele alıyorsunuz. Daha sonra, etiketleme gerçekleştiğinde (olay / mesaj işleme, CQRS stili komut işleme, bazı periyodik iş işleme, her ne olursa olsun) etiketleme hizmeti kullanıcıyı taklit eder (büyük olasılıkla yetkiden özel bir JWT istemek için paylaşılan bir sır kullanarak) ve sonra orijinal istek sahibi adına alt işlem (tüm izinleri ve sınırlamaları dahil). Bu yöntem, işler düzgün gitmezse kullanıcıya geri hata vermenin zor olduğu asenkron işlemlerle ilgili normal bir soruna sahiptir, ancak bu modeli çapraz servis işlemleri için kullanıyorsanız, bunu zaten çözmüşsünüzdür.

3. Bazı alt sistemlerin bir kullanıcının bağlamı dışında bir şeyler yapması gerekir. Belki eski görüntüleri arşivlemek için her gece bir işiniz var. Belki de etiketlerinizin birleştirilmesi gerekir ... Bu durumda, muhtemelen bu aktörlerin her birinin sınırlı izinleri ve denetim izi için benzersiz bir kimliği olan kendi sahte kullanıcılarına sahip olmasını istersiniz.

Hangisini kullanmanız senaryo, ihtiyaçlarınıza ve risk toleransınıza bağlı olarak değişecektir. Ve elbette, bunlar sadece eksik geniş kapsamlı genellemeler dizisidir.

Ancak genel olarak, mikro hizmetlerin kendileri mümkünse kullanıcı olmamalıdır.