Istio を使用したマイクロサービスに戻ります。 パート3

ノート。 翻訳。: 最初の部分 このシリーズは、Istio の機能を知り、実際にその機能をデモンストレーションすることに専念しました。 2番目の — 細かく調整されたルーティングとネットワーク トラフィック管理。次に、セキュリティについて説明します。それに関連する基本機能を示すために、作成者は Auth0 ID サービスを使用しますが、他のプロバイダーも同様の方法で構成できます。

Istio とサンプル マイクロサービス アプリケーションであるセンチメント分析をデプロイした Kubernetes クラスターをセットアップして、Istio の機能を実証しました。

Istio を使用すると、再試行、タイムアウト、サーキット ブレーカー、トレース、モニタリングなどのレイヤーを実装する必要がないため、サービスを小さく保つことができました。さらに、A/B テスト、ミラーリング、カナリア ロールアウトなどの高度なテストおよび展開手法を使用しました。

新しい資料では、ビジネス価値への道の最後のレイヤーである認証と認可を扱います。Istio ではこれが本当に楽しいのです。

Istio での認証と認可

まさか自分が認証と認可からインスピレーションを受けるとは思ってもいませんでした。これらのトピックを楽しく、さらにインスピレーションを与えるために、テクノロジーの観点から Istio は何を提供できるでしょうか?

答えは簡単です。Istio は、これらの機能に対する責任をサービスから Envoy プロキシに移します。リクエストがサービスに到達するまでに、リクエストはすでに認証および許可されているため、必要なのはビジネスに役立つコードを記述することだけです。

いいですね？中を覗いてみましょう！

Auth0による認証

ID とアクセス管理のサーバーとして、Auth0 を使用します。AuthXNUMX には試用版があり、直感的に使用でき、単純に気に入っています。ただし、同じ原則は他のものにも適用できます。 OpenID Connectの実装: KeyCloak、IdentityServer、その他多数。

始めるには、にアクセスしてください Auth0 ポータル アカウントを使用してテナントを作成します (テナント - 「テナント」、分離の論理単位、詳細については、 ドキュメンテーション — 約翻訳） そしてに行きます アプリケーション > デフォルトのアプリ選択 ドメイン以下のスクリーンショットに示すように、

ファイル内でこのドメインを指定します resource-manifests/istio/security/auth-policy.yaml (ソースコード):

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

このようなリソースを使用して、パイロットは (Istio の 3 つの基本的なコントロール プレーン コンポーネントの 1 つ - おおよその翻訳) リクエストをサービスに転送する前に認証するように Envoy を構成します。 sa-web-app и sa-feedback。同時に、構成はサービス Envoy には適用されません。 sa-frontendこれにより、フロントエンドを認証されないままにすることができます。ポリシーを適用するには、次のコマンドを実行します。

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

ページに戻ってリクエストを実行します。リクエストが次のステータスで終了することがわかります。 401未承認。次に、フロントエンド ユーザーを Auth0 で認証するようにリダイレクトしましょう。

Auth0 によるリクエストの認証

エンド ユーザーのリクエストを認証するには、認証されたサービス (レビュー、詳細、評価) を表す API を Auth0 で作成する必要があります。 API を作成するには、次の場所に移動します。 Auth0 ポータル > API > API の作成 そしてフォームに記入してください:

ここで重要な情報は、 識別するこれは、スクリプトの後半で使用します。次のように書き留めてみましょう。

• Audience: {YOUR_AUDIENCE}

必要な残りの詳細は、Auth0 ポータルのセクションにあります。 アプリケーション - 選択する テストアプリケーション (API とともに自動的に作成されます)。

ここでは次のように書きます。

• ドメイン: {あなたのドメイン}
• クライアントID: {YOUR_CLIENT_ID}

までスクロールします テストアプリケーション テキストフィールドへ 許可されるコールバック URL (コールバックの解決された URL)。認証の完了後に呼び出しを送信する URL を指定します。私たちの場合は次のようになります。

http://{EXTERNAL_IP}/callback

そして 許可されるログアウト URL (ログアウト用に許可される URL) を追加します。

http://{EXTERNAL_IP}/logout

フロントエンドに移りましょう。

フロントエンドのアップデート

ブランチに切り替える auth0 リポジトリ [istio-mastery]。このブランチでは、認証のためにユーザーを Auth0 にリダイレクトし、他のサービスへのリクエストで JWT トークンを使用するようにフロントエンド コードが変更されています。後者は次のように実装されます(App.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 でテナント データを使用するようにフロントエンドを切り替えるには、次のコマンドを開きます。 sa-frontend/src/services/Auth.js その中で上で書いた値を置き換えます(認証.js):

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

アプリケーションの準備ができました。加えられた変更をビルドしてデプロイするときに、以下のコマンドで Docker ID を指定します。

$ 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

アプリを試してみましょう！ Auth0 にリダイレクトされ、そこでログイン (または登録) する必要があります。その後、すでに認証されたリクエストが行われるページに戻ります。記事の最初の部分で説明したコマンドをcurlで試すと、次のコードが得られます。 401 ステータスコード、リクエストが承認されていないことを示します。

次のステップに進み、リクエストを承認しましょう。

Auth0による認可

認証によりユーザーが誰であるかを理解できますが、ユーザーが何にアクセスできるかを知るには承認が必要です。 Istio はこのためのツールも提供しています。

例として、2 つのユーザー グループを作成してみましょう (下の図を参照)。

• メンバー （ユーザー） — SA-WebApp および SA-Frontend サービスへのアクセスのみ。
• モデレーター (司会者) — 3 つのサービスすべてにアクセスできます。

認可の概念

これらのグループを作成するには、Auth0 Authorization 拡張機能を使用し、Istio を使用してさまざまなレベルのアクセスを提供します。

Auth0 認可のインストールと構成

Auth0 ポータルで、拡張機能 (拡張機能) をインストールしてください Auth0 認可。インストール後、次の場所に移動します 認可の延長、そこに - 右上をクリックして適切なメニュー オプションを選択して、テナントの構成に移動します （構成）。グループをアクティブ化する （グループ） そして「ルールの公開」ボタンをクリックします (公開ルール).

グループを作成する

認証拡張で、次の場所に移動します。 グループ そしてグループを作成します モデレーター。認証されたすべてのユーザーを通常のユーザーとして扱うため、追加のグループを作成する必要はありません。

グループを選択 モデレーター、нажмитена メンバーを追加, メインアカウントを追加します。アクセスが確実に拒否されるように、一部のユーザーをグループなしのままにしておきます。 (新しいユーザーは、次の方法で手動で作成できます) Auth0 ポータル > ユーザー > ユーザーの作成.)

アクセストークンにグループクレームを追加

ユーザーはグループに追加されましたが、この情報はアクセス トークンにも反映される必要があります。 OpenID Connect に準拠し、同時に必要なグループを返すには、トークンに独自の追加を行う必要があります。 カスタムクレーム。 Auth0 ルールを通じて実装されます。

ルールを作成するには、Auth0 ポータルに移動して、 キャンペーンのルール、нажмитена ルールの作成 テンプレートから空のルールを選択します。

以下のコードをコピーし、新しいルールとして保存します グループクレームの追加 (namespacedGroup.js):

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

注意: このコードは、認可拡張機能で定義された最初のユーザー グループを取得し、それをカスタム クレームとしてアクセス トークンに追加します (Auth0 で必要な名前空間の下)。

ページに戻る キャンペーンのルール 2 つのルールが次の順序で記述されていることを確認します。

• auth0-認可拡張子
• グループクレームの追加

グループフィールドはルールを非同期的に受信するため、順序は重要です。 auth0-認可拡張子 その後、2 番目のルールによってクレームとして追加されます。結果は次のようなアクセス トークンになります。

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

ここで、ユーザー アクセスをチェックするように Envoy プロキシを構成する必要があります。ユーザー アクセスに対して、グループは要求からプルされます (https://sa.io/group) 返されたアクセス トークンに含まれます。これは、この記事の次のセクションのトピックです。

Istio での認可構成

認証が機能するには、Istio の RBAC を有効にする必要があります。これを行うには、次の構成を使用します。

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" 

説明：

• 1 - フィールドにリストされているサービスと名前空間に対してのみ RBAC を有効にします。 Inclusion;
• 2 — 当社のサービスのリストを記載します。

次のコマンドを使用して構成を適用しましょう。

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

すべてのサービスに役割ベースのアクセス制御が必要になりました。つまり、すべてのサービスへのアクセスが禁止され、応答が返されます。 RBAC: access denied。次に、許可されたユーザーにアクセスを許可しましょう。

一般ユーザーのアクセス構成

すべてのユーザーは SA-Frontend サービスおよび SA-WebApp サービスにアクセスできる必要があります。次の Istio リソースを使用して実装されます。

• サービスロール — ユーザーが持つ権利を決定します。
• サービスロールバインディング — この ServiceRole が誰に属するかを決定します。

一般ユーザーに対しては、特定のサービスへのアクセスを許可します (サービスロール.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: ["*"]

そして、 regular-user-binding ServiceRole をすべてのページ訪問者に適用します (通常のユーザーサービスロールバインディング.yaml):

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

「すべてのユーザー」とは、認証されていないユーザーも SA WebApp にアクセスできることを意味しますか?いいえ、ポリシーは JWT トークンの有効性をチェックします。

設定を適用しましょう。

$ 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

モデレーターのアクセス構成

モデレーターに対しては、すべてのサービスへのアクセスを有効にしたいと考えています (mod-サービス-ロール.yaml):

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

ただし、そのような権利は、アクセス トークンにクレームが含まれているユーザーにのみ必要です。 https://sa.io/group 意味のある 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" 

設定を適用しましょう。

$ 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

エンボイのキャッシュのため、認可ルールが有効になるまでに数分かかる場合があります。これにより、ユーザーとモデレータに異なるレベルのアクセス権を与えることができます。

この部分の結論

しかし真剣に考えてみると、認証と認可に対する、これよりもシンプルで、手間がかからず、スケーラブルで安全なアプローチを見たことがありますか?

サービスへのエンド ユーザー アクセスの認証と認可をきめ細かく制御するために必要な Istio リソースは 3 つだけ (RbacConfig、ServiceRole、ServiceRoleBinding) でした。

さらに、当社は特使サービスを通じてこれらの問題に対処し、次のことを達成しました。

• セキュリティ上の問題やバグを含む可能性のある汎用コードの量を削減します。
• 1 つのエンドポイントが外部からアクセス可能であることが判明し、それを報告するのを忘れるという愚かな状況の数を減らします。
• 新しい役割や権利が追加されるたびにすべてのサービスを更新する必要がなくなります。
• 新しいサービスがシンプル、安全、高速であることを保証します。

出力

Istio を使用すると、チームはサービスにオーバーヘッドを追加することなく、サービスをマイクロ ステータスに戻すことなく、ビジネス クリティカルなタスクにリソースを集中させることができます。

この記事 (3 部構成) では、実際のプロジェクトで Istio を始めるための基本的な知識と既製の実践的な手順を提供しました。

翻訳者からの追伸

私たちのブログもお読みください:

• 「Istio でマイクロサービスに戻る」: パート 1 (主な機能の紹介), パート 2 (ルーティング、トラフィック制御);
• «Conduit - Kubernetes 用の軽量サービス メッシュ";
• «サービス メッシュとは何ですか? [マイクロサービスを備えたクラウド アプリケーションに] サービス メッシュが必要な理由は何ですか?'。

出所： habr.com