Istio ile mikro hizmetlere geri dönelim. Bölüm 3

Not. tercüme: Birinci bölüm Bu seri, Istio'nun yeteneklerini tanımaya ve bunları çalışırken göstermeye adanmıştı. ikinci — ince ayarlanmış yönlendirme ve ağ trafiği yönetimi. Şimdi güvenlikten bahsedeceğiz: bununla ilgili temel işlevleri göstermek için yazar Auth0 kimlik hizmetini kullanıyor, ancak diğer sağlayıcılar da benzer şekilde yapılandırılabilir.

Istio'nun yeteneklerini göstermek için Istio'yu konuşlandırdığımız bir Kubernetes kümesi ve örnek bir mikro hizmet uygulaması olan Sentiment Analysis'i kurduk.

Istio ile hizmetlerimizi küçük tutabildik çünkü Yeniden Denemeler, Zaman Aşımları, Devre Kesiciler, İzleme, İzleme gibi katmanları uygulamaya ihtiyaç duymadık. Ayrıca gelişmiş test ve dağıtım tekniklerini de kullandık: A/B testi, yansıtma ve canary sunumları.

Yeni materyalde iş değerine giden yolda son katmanları ele alacağız: kimlik doğrulama ve yetkilendirme - ve Istio'da bu gerçek bir zevk!

Istio'da kimlik doğrulama ve yetkilendirme

Kimlik doğrulama ve yetkilendirmeden ilham alacağıma asla inanmazdım. Istio, bu konuları eğlenceli ve daha da önemlisi sizin için ilham verici hale getirmek için teknoloji açısından neler sunabilir?

Cevap basit: Istio, bu yeteneklerin sorumluluğunu hizmetlerinizden Envoy proxy'sine devreder. İstekler hizmetlere ulaştığında, zaten doğrulanmış ve yetkilendirilmişlerdir, dolayısıyla tek yapmanız gereken iş açısından yararlı kod yazmaktır.

Kulağa iyi geliyor? Haydi içeriye bir göz atalım!

Auth0 ile kimlik doğrulama

Kimlik ve erişim yönetimi sunucusu olarak deneme sürümü olan, kullanımı sezgisel olan ve hoşuma giden Auth0'ı kullanacağız. Ancak aynı prensipler diğerlerine de uygulanabilir. OpenID Connect uygulamaları: KeyCloak, IdentityServer ve diğerleri.

Başlamak için şuraya gidin: Auth0 Portalı hesabınızla bir kiracı oluşturun (kiracı - “kiracı”, mantıksal yalıtım birimi, daha fazla ayrıntı için bkz. belgeleme - yaklaşık. çeviri.) Ve git Uygulamalar > Varsayılan Uygulamaseçme domain, aşağıdaki ekran görüntüsünde gösterildiği gibi:

Bu etki alanını dosyada belirtin resource-manifests/istio/security/auth-policy.yaml (kaynak):

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: auth-policy
spec:
  targets:
  - name: sa-web-app
  - name: sa-feedback
  origins:
  - jwt:
      issuer: "https://{YOUR_DOMAIN}/"
      jwksUri: "https://{YOUR_DOMAIN}/.well-known/jwks.json"
  principalBinding: USE_ORIGIN

Böyle bir kaynakla Pilot (Istio'daki üç temel Kontrol Düzlemi bileşeninden biri - yaklaşık çeviri.) Envoy'u, istekleri hizmetlere iletmeden önce kimlik doğrulaması yapacak şekilde yapılandırır: sa-web-app и sa-feedback. Aynı zamanda yapılandırma, hizmet Elçilerine uygulanmaz. sa-frontend, ön ucu kimliği doğrulanmamış olarak bırakmamıza izin veriyor. İlkeyi uygulamak için şu komutu çalıştırın:

$ kubectl apply -f resource-manifests/istio/security/auth-policy.yaml
policy.authentication.istio.io “auth-policy” created

Sayfaya dönün ve talepte bulunun; bunun durumla bittiğini göreceksiniz 401 Yetkisiz. Şimdi ön uç kullanıcılarını Auth0 ile kimlik doğrulamaya yönlendirelim.

Auth0 ile isteklerin doğrulanması

Son kullanıcı isteklerini doğrulamak için Auth0'da kimliği doğrulanmış hizmetleri (incelemeler, ayrıntılar ve derecelendirmeler) temsil edecek bir API oluşturmanız gerekir. API oluşturmak için şuraya gidin: Auth0 Portalı > API'ler > API Oluştur ve formu doldurun:

Buradaki önemli bilgi şu Tanımlayıcı, bunu daha sonra komut dosyasında kullanacağız. Bunu şu şekilde yazalım:

• Seyirci: {YOUR_AUDIENCE}

İhtiyacımız olan geri kalan ayrıntılar Auth0 Portalı bölümünde yer almaktadır. Uygulamalar - seçme Test Uygulaması (API ile birlikte otomatik olarak oluşturulur).

Burada şunu yazacağız:

• domain: {YOUR_DOMAIN}
• Müşteri Kimliği: {YOUR_CLIENT_ID}

Şuraya kaydır: Test Uygulaması metin alanına İzin Verilen Geri Arama URL'leri (geri arama için çözümlenmiş URL'ler), burada kimlik doğrulama tamamlandıktan sonra çağrının gönderilmesi gereken URL'yi belirtiriz. Bizim durumumuzda:

http://{EXTERNAL_IP}/callback

Ve için İzin Verilen Oturum Kapatma URL'leri (çıkış yapmak için izin verilen URL'ler) şunu ekleyin:

http://{EXTERNAL_IP}/logout

Ön yüze geçelim.

Ön uç güncellemesi

Şubeye geçiş auth0 depo [istio-mastery]. Bu dalda, kullanıcıları kimlik doğrulama için Auth0'a yönlendirmek ve diğer hizmetlere yapılan isteklerde JWT belirtecini kullanmak için ön uç kodu değiştirilir. İkincisi aşağıdaki gibi uygulanır (Uygulama.js):

analyzeSentence() {
    fetch('/sentiment', {
        method: 'POST',
        headers: {
            'Content-Type': 'application/json',
            'Authorization': `Bearer ${auth.getAccessToken()}` // Access Token
        },
        body: JSON.stringify({ sentence: this.textField.getValue() })
    })
        .then(response => response.json())
        .then(data => this.setState(data));
}

Auth0'da kiracı verilerini kullanacak şekilde ön ucu değiştirmek için sa-frontend/src/services/Auth.js ve yukarıda yazdığımız değerleri değiştirin (Auth.js):

const Config = {
    clientID: '{YOUR_CLIENT_ID}',
    domain:'{YOUR_DOMAIN}',
    audience: '{YOUR_AUDIENCE}',
    ingressIP: '{EXTERNAL_IP}' // Используется для редиректа после аутентификации
}

Uygulama hazır. Yapılan değişiklikleri oluştururken ve dağıtırken aşağıdaki komutlarda Docker ID'nizi belirtin:

$ docker build -f sa-frontend/Dockerfile 
 -t $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0 
 sa-frontend

$ docker push $DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

$ kubectl set image deployment/sa-frontend 
 sa-frontend=$DOCKER_USER_ID/sentiment-analysis-frontend:istio-auth0

Uygulamayı deneyin! Oturum açmanız (veya kaydolmanız) gereken Auth0'a yönlendirileceksiniz, ardından zaten kimliği doğrulanmış isteklerin yapılacağı sayfaya geri gönderileceksiniz. Yazının ilk bölümlerinde bahsettiğimiz komutları curl ile denerseniz aşağıdaki kodu alacaksınız. 401 Durum Kodu, isteğin yetkili olmadığının sinyalini verir.

Bir sonraki adıma geçelim: istekleri yetkilendirin.

Auth0 ile yetkilendirme

Kimlik doğrulama, kullanıcının kim olduğunu anlamamızı sağlar ancak neye erişime sahip olduklarını bilmek için yetkilendirme gerekir. Istio bunun için de araçlar sunuyor.

Örnek olarak iki kullanıcı grubu oluşturalım (aşağıdaki şemaya bakın):

• Üyeler (kullanıcılar) — yalnızca SA-WebApp ve SA-Frontend hizmetlerine erişimle;
• Moderatörler (moderatörler) — üç hizmetin tümüne erişim ile.

Yetki kavramı

Bu grupları oluşturmak için Auth0 Yetkilendirme uzantısını kullanacağız ve onlara farklı erişim düzeyleri sağlamak için Istio'yu kullanacağız.

Auth0 Yetkilendirmesinin kurulumu ve yapılandırılması

Auth0 portalında uzantılara gidin (uzantıları) ve yükleyin Auth0 Yetkilendirmesi. Kurulumdan sonra şu adrese gidin: Yetki Uzantısı, ve orada - sağ üst köşeye tıklayarak ve uygun menü seçeneğini seçerek kiracının yapılandırmasına gidin (Konfigürasyon). Grupları etkinleştir (Gruplar) ve kuralı yayınla düğmesine tıklayın (Kural yayınla).

Gruplar oluşturun

Yetkilendirme Uzantısında şuraya gidin: Gruplar ve bir grup oluştur Moderatörler. Kimliği doğrulanmış tüm kullanıcılara normal kullanıcılar gibi davranacağımızdan onlar için ek bir grup oluşturmaya gerek yoktur.

Bir grup seçin Moderatörler, Basmak Üye ekle, ana hesabınızı ekleyin. Erişimlerinin reddedildiğinden emin olmak için bazı kullanıcıları herhangi bir grup olmadan bırakın. (Yeni kullanıcılar manuel olarak oluşturulabilir. Auth0 Portalı > Kullanıcılar > Kullanıcı Oluştur.)

Erişim Belirteci'ne Grup Talebi Ekle

Kullanıcılar gruplara eklenmiştir ancak bu bilgilerin erişim belirteçlerine de yansıtılması gerekir. OpenID Connect'e uymak ve aynı zamanda ihtiyacımız olan grupları geri döndürmek için tokenin kendi tokenını eklemesi gerekecek özel talep. Auth0 kuralları aracılığıyla uygulanır.

Bir kural oluşturmak için Auth0 Portalına gidin. kurallar, Basmak Kural koy ve şablonlardan boş bir kural seçin.

Aşağıdaki kodu kopyalayıp yeni kural olarak kaydedin Grup Talebi Ekle (namespacedGroup.js):

function (user, context, callback) {
    context.accessToken['https://sa.io/group'] = user.groups[0];
    return callback(null, user, context);
}

Dikkat: Bu kod, Yetkilendirme Uzantısında tanımlanan ilk kullanıcı grubunu alır ve bunu özel bir talep olarak erişim belirtecine ekler (Auth0'ın gerektirdiği şekilde ad alanı altında).

Sayfaya dön kurallar ve aşağıdaki sırayla yazılmış iki kuralınız olup olmadığını kontrol edin:

• auth0-yetkilendirme-uzantısı
• Grup Talebi Ekle

Grup alanı kuralı eşzamansız olarak aldığından sıra önemlidir auth0-yetkilendirme-uzantısı ve bundan sonra ikinci kural tarafından iddia olarak eklenir. Sonuç şuna benzer bir erişim belirtecidir:

{
 "https://sa.io/group": "Moderators",
 "iss": "https://sentiment-analysis.eu.auth0.com/",
 "sub": "google-oauth2|196405271625531691872"
 // [сокращено для наглядности]
}

Artık grubun talepten çekileceği kullanıcı erişimini kontrol etmek için Envoy proxy'sini yapılandırmanız gerekiyor (https://sa.io/group) döndürülen erişim belirtecinde. Bu makalenin bir sonraki bölümünün konusu.

Istio'da yetkilendirme yapılandırması

Yetkinin çalışması için Istio için RBAC'ı etkinleştirmeniz gerekir. Bunu yapmak için aşağıdaki yapılandırmayı kullanacağız:

apiVersion: "rbac.istio.io/v1alpha1"
kind: RbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'                     # 1
  inclusion:
    services:                                   # 2
    - "sa-frontend.default.svc.cluster.local"
    - "sa-web-app.default.svc.cluster.local"
    - "sa-feedback.default.svc.cluster.local" 

Açıklama:

• 1 — RBAC'yi yalnızca alanda listelenen hizmetler ve ad alanları için etkinleştirin Inclusion;
• 2 — hizmetlerimizin bir listesini listeliyoruz.

Aşağıdaki komutla konfigürasyonu uygulayalım:

$ kubectl apply -f resource-manifests/istio/security/enable-rbac.yaml
rbacconfig.rbac.istio.io/default created

Artık tüm hizmetler Rol Tabanlı Erişim Kontrolü gerektiriyor. Başka bir deyişle, tüm hizmetlere erişim yasaktır ve yanıt verilmesiyle sonuçlanacaktır. RBAC: access denied. Şimdi yetkili kullanıcılara erişime izin verelim.

Normal kullanıcılar için erişim yapılandırması

Tüm kullanıcıların SA-Frontend ve SA-WebApp hizmetlerine erişimi olmalıdır. Aşağıdaki Istio kaynakları kullanılarak uygulanmıştır:

• Hizmet Rolü — kullanıcının sahip olduğu hakları belirler;
• HizmetRol Bağlama — bu ServiceRole'un kime ait olduğunu belirler.

Sıradan kullanıcılar için belirli hizmetlere erişime izin vereceğiz (hizmet rolü.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: regular-user
  namespace: default
spec:
  rules:
  - services: 
    - "sa-frontend.default.svc.cluster.local" 
    - "sa-web-app.default.svc.cluster.local"
    paths: ["*"]
    methods: ["*"]

Ve aracılığıyla regular-user-binding ServiceRole'u tüm sayfa ziyaretçilerine uygulayın (normal-kullanıcı-hizmet-rolü-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: regular-user-binding
  namespace: default
spec:
  subjects:
  - user: "*"
  roleRef:
    kind: ServiceRole
    name: "regular-user"

"Tüm kullanıcılar", kimliği doğrulanmamış kullanıcıların da SA Web Uygulamasına erişebileceği anlamına mı geliyor? Hayır, politika JWT tokeninin geçerliliğini kontrol edecektir.

Yapılandırmaları uygulayalım:

$ kubectl apply -f resource-manifests/istio/security/user-role.yaml
servicerole.rbac.istio.io/regular-user created
servicerolebinding.rbac.istio.io/regular-user-binding created

Moderatörler için erişim yapılandırması

Moderatörler için tüm hizmetlere erişimi etkinleştirmek istiyoruz (mod-service-role.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: mod-user
  namespace: default
spec:
  rules:
  - services: ["*"]
    paths: ["*"]
    methods: ["*"]

Ancak bu tür hakları yalnızca erişim belirtecinde hak talebi bulunan kullanıcılar için istiyoruz https://sa.io/group anlamı olan Moderators (mod-service-role-binding.yaml):

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: mod-user-binding
  namespace: default
spec:
  subjects:
  - properties:
      request.auth.claims[https://sa.io/group]: "Moderators"
  roleRef:
    kind: ServiceRole
name: "mod-user" 

Yapılandırmaları uygulayalım:

$ kubectl apply -f resource-manifests/istio/security/mod-role.yaml
servicerole.rbac.istio.io/mod-user created
servicerolebinding.rbac.istio.io/mod-user-binding created

Elçilerin önbelleğe alınması nedeniyle yetkilendirme kurallarının yürürlüğe girmesi birkaç dakika sürebilir. Daha sonra kullanıcıların ve moderatörlerin farklı erişim düzeylerine sahip olmasını sağlayabilirsiniz.

Bu kısımla ilgili sonuç

Gerçekten de, kimlik doğrulama ve yetkilendirmeye yönelik daha basit, zahmetsiz, ölçeklenebilir ve güvenli bir yaklaşım gördünüz mü?

Hizmetlere son kullanıcı erişiminin kimlik doğrulaması ve yetkilendirilmesi üzerinde ayrıntılı kontrol elde etmek için yalnızca üç Istio kaynağı (RbacConfig, ServiceRole ve ServiceRoleBinding) gerekliydi.

Ayrıca elçilik hizmetlerimiz kapsamında bu konuları da ele alarak şunları başardık:

• güvenlik sorunları ve hatalar içerebilecek genel kod miktarının azaltılması;
• bir uç noktaya dışarıdan erişilebildiği ve bunu bildirmeyi unuttuğu aptalca durumların sayısının azaltılması;
• her yeni rol veya hak eklendiğinde tüm hizmetleri güncelleme ihtiyacını ortadan kaldırır;
• yeni hizmetlerin basit, güvenli ve hızlı kalmasını sağlıyoruz.

Aviator apk

Istio, hizmetlerin yükünü artırmadan ekiplerin kaynaklarını iş açısından kritik görevlere odaklamasına ve bunları mikro duruma döndürmesine olanak tanır.

Makale (üç bölüm halinde), gerçek projelerde Istio'yu kullanmaya başlamak için temel bilgileri ve hazır pratik talimatları sağladı.

çevirmenden PS

Blogumuzda da okuyun:

• "Istio ile mikro hizmetlere geri dön": 1. bölüm (ana özelliklere giriş), bölüm 2 (yönlendirme, trafik kontrolü);
• «Conduit - Kubernetes için hafif servis ağı";
• «Hizmet ağı nedir ve neden buna ihtiyacım var [mikro hizmetlere sahip bir bulut uygulaması için]?'.

Kaynak: habr.com