このブログ アドレス: https://security.blog.csdn.net/article/details/130152887
1.認証サービス
1.1、JWT ベースの認証
マイクロサービス アーキテクチャでは、各サービスはステートレスであり、サーバーはクライアントのログイン ステータスを保存する必要があるため、従来のセッション認証方法はマイクロサービスでは適用できなくなりました。理想的な実装はステートレス ログインである必要があり、プロセスは通常次のとおりです。
1. クライアントが特定のサービスを要求し、サーバーがユーザーのログイン認証を実行します。
2. 認証に合格すると、サーバーはユーザーのログイン情報を暗号化してトークンを形成し、最終的にログイン資格情報としてクライアントに返します。
3. ステップ 2 の後、クライアントは要求するたびに認証トークンを保持する必要があります。
4. サーバーはトークンを復号化し、有効かどうかを判定し、有効な場合は認証に合格し、そうでない場合は失敗メッセージを返します。
ステートレス ログインは JWT で実現できます。JWT は JSON スタイルの軽量な認証および承認仕様であり、上記のプロセスで説明したトークンです。主に分散シナリオで使用されます。JWT トークンには機密性の高いユーザー情報が含まれることに注意してください。 、バイパスを防ぐために、JWTトークンは署名メカニズムを採用しています。さらに、送信には暗号化プロトコルが必要です。
1.2. Istio ベースの認証
Istio の基本的な知識は、以前に書かれたブログ投稿を参照できます: https://security.blog.csdn.net/article/details/128449214
Istio には、トランスポート認証とリクエストレベル認証の 2 つの主な認証タイプがあります。
1.送信認証
トランスポート認証は Istio の認証タイプで、主にマイクロサービス アプリケーション アーキテクチャでサービス間認証に使用され、接続されたクライアントを検証できます。このタイプの認証のために、Istio は以下の機能を提供する相互 TLS ソリューションを提供します。
1. サービス間の通信セキュリティを確保します。
2. 鍵と証明書を自動的に生成、配布、ローテーションするための鍵管理システムを提供します。
3. 各サービスにそのロールを表す ID を提供し、クラスタ間の相互運用性を有効にします。
具体的には、トランスポート認証ポリシーを使用して、Istio のサービスの認証要件を指定できます。たとえば、名前空間レベルの TLS 認証ポリシーでは、特定の名前空間内の Pod 間のすべてのアクセスで TLS 暗号化を使用し、Pod レベルの TLS 認証を使用する必要があることを指定できます。ポリシーは、特定の Pod へのアクセス時に TLS 暗号化が必要であることを指定できます。
2. リクエストレベル認証
リクエスト レベル認証は、Istio の認証タイプです。主にエンド ユーザーの認証に使用されます。送信認証との主な違いは、リクエスト レベル認証は主に、サービスではなく、サービスを要求するときにユーザーが保持する資格情報を検証するために使用されることです。サービスへの認証です。
要求レベルの認証は、主に JWT メカニズムを通じて実装されます。従来のセッション認証方式と比較して, 最大の違いは, 認証情報がクライアント側に保存されることです. 認証情報がサーバー側に保存されなくなったため, ステートレスマイクロサービスシナリオに非常に適しており, 簡単な目的を達成します.拡張。
Istio の JWT 認証は、主に JWKS に依存しています。JWKS は、JWT の検証に使用される公開鍵を含む一連の鍵です。実際のアプリケーション シナリオでは、O&M 担当者は、サービスの JWT 認証ポリシーをデプロイすることで、要求レベルの認証を実装します。
JWT 認証戦略のコア構成を以下に示します。
// issuer：代表发布JWT的发行者
issuer: https://example.com
// jwksUri：JWKS获取的地址，本地或远程均可，用于验证JWT的签名
jwksUri: https://example.com/.well-known/jwks.json
// triggerRules：triggerRules为使用JWT验证请求的规则触发列表，如果满足匹配规则就进行JWT验证
triggerRules:
- excludedPaths:
// 对于任何带有/status/前缀的请求路径，除了/status/version以外，都需要JWT认证
- exact: /status/version
includedPaths:
- prefix: /status/
JWT 認証ポリシーの展開が完了した後、特定のサービスに対する新しい外部リクエストがあった場合、リクエスト レベル認証は、ポリシーの内容に従って、リクエストで運ばれたトークン (Token) を検証します。ポリシーの内容に一致しない場合、認証失敗が返されます。それ以外の場合、認証は成功します。
2. Istio ベースのアクセス制御
2.1. Istio 認可
Istio 承認プロセスは次のように要約できます。
管理者は yaml ファイルを使用して Istio 承認ポリシーを指定し、それを Istiod のコア コンポーネントにデプロイします. Istiod は、API サーバー コンポーネントを介して承認ポリシーの変更を監視します. 変更がある場合は、新しいポリシーを取得します. Istiod は送信しますサービスのサイドカー エージェントへの承認ポリシー。各サイドカー プロキシには、エンジンの実行時にリクエストを承認する承認エンジンが含まれています。
写真のように:
以下は、Istio 承認ポリシーの例です。
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: httpbin-policy
namespace: foo
spec:
selector:
matchLabels:
app: httpbin
action: ALLOW
rules:
- from:
- source:
principals: ["cluster.local/ns/default/sa/sleep"]
to:
- operation:
methods: ["GET"]
paths: ["/info*"]
when:
- key: request.auth.claims[iss]
values: ["https://foo.com"]
app:httpbinこの承認ポリシーの意味は、次のとおりです。foo 名前空間にこのラベルを含む Pod を除外し、これらの Pod に送信されたリクエストを照合し、一致した場合は現在のリクエストを解放します。
マッチング ルールは次のとおりです。リクエストを開始するポッドのサービス アカウントは である必要がありcluster.local/ns/default/sa/sleep、リクエストは HTTP プロトコルを使用し、リクエストの特定のメソッド タイプは GET であり、リクエストの URL は であり、/info*リクエストにはhttps://foo.comによって発行された有効な JWT トークン。
この例から、承認ポリシーには主に次の部分が含まれていることがわかります。
name : 認可ポリシー自体を識別するためにのみ使用され、ルールの照合と実行には影響しない認可ポリシーの名前; namespace
:現在のポリシー オブジェクトが配置されている名前空間。このフィールドを使用して設定できます。さまざまなスコープの承認ポリシー;
セレクター: ラベルを使用して、現在の承認ポリシーが適用されるポッドを選択します。最終的にこれらのルールは Envoy ルールに変換され、サーバー上の Envoy プロキシによって実行されるため、サーバー上のポッドがここに設定されていることに注意してください; action : ALLOW (デフォルト値) または DENY にすることができます; rules : ルールに
一致する
場合、マッチングが成功すると、対応するアクションが実行されます。
2.2. 認可ポリシーのマッチングアルゴリズム
特定のリクエストに対して、対応する認証戦略が特定のマッチング アルゴリズムに従って実行されます。
1. いずれかの DENY 認可ポリシーが現在のリクエストと一致する場合、現在のリクエストは拒否されます;
2. 現在の Pod について、ALLOW 認可ポリシーがない場合、現在のリクエストは許可されます;
3. いずれかの ALLOW 認可ポリシーが一致する場合、現在のリクエストは許可されます現在の要求、次に現在の要求を解放する;
4. 現在の要求を拒否する;
つまり、ALLOW ポリシーと DENY ポリシーの両方が同じポッドで動作する場合、DENY ポリシーが最初に実行され、他の ALLOW ルールは無視されます。