Anthos Service Mesh 1.13 はサポート期間が終了し、今後はサポートされません。以前のバージョンからのアップグレードをご覧ください。

最新のドキュメントを表示するか、他の利用可能なバージョンを選択します。

利用可能なバージョン

Anthos Service Mesh のユーザー認証の構成

Anthos Service Mesh のユーザー認証は、デプロイされたワークロードへのブラウザベースのエンドユーザー認証とアクセス制御のための統合ソリューションです。このソリューションにより、ユーザー認証の既存の ID プロバイダ（IDP）と統合できます。アクセス管理には、Istio API と認証ポリシーが使用されます。これは、Istio JSON Web Token（JWT）認証に代わる、ユーザーフレンドリーな代替手段です。

代表的な使用例は、従業員がウェブブラウザからアクセスできるように、組織が Anthos Service Mesh を使用して、ウェブアプリケーションをホストする場合です。また、組織では既存の ID プロバイダを使用してユーザー ID を管理する必要があります。Anthos Service Mesh のユーザー認証では、ユーザーは標準のウェブベースの OpenID Connect（OIDC）ログインと同意フローを使用して簡単に認証できます。ユーザーが認証されると、Anthos Service Mesh によって Istio の認証ポリシーが適用されます。認証が正常に完了すると、安全な認証情報形式で ID がワークロードに送信されます。

仕組み

Anthos Service Mesh のユーザー認証では、新しいコンポーネント authservice が導入されています。このコンポーネントは、すべての受信認証リクエストをインターセプトする外部承認サービスとして Envoy ベースの Ingress と統合します。authservice は OIDC プロトコルのクライアント側を実装し、ユーザーがブラウザからアプリケーションにアクセスできるようにします。この際、ユーザーはインタラクティブな認証および同意フローを完了して、有効期間の短いセッションを確立します。authservice は、OIDC 認証サーバーとして機能できる ID プロバイダと統合するための業界標準プロトコルを実装します。ユーザーが認証されると、主要な情報は RCToken に JWT 形式でカプセル化され、authservice によって署名されてから Ingress の Istio 認証レイヤに転送されます。このモデルは、メッシュへのトラフィックの境界アクセス制御を提供します。ユーザーがリソースへのアクセスを承認されている場合は、この RCToken もマイクロサービスに転送されるため、主要な情報を取得してきめ細かいアクセス制御を行えます。

次の図は、メッシュ内の authservice の場所と、Ingress、ワークロード、ユーザーのブラウザ、既存の IDP など、メッシュの他の部分との関連を示しています。

エンドユーザー認証

管理者は、Anthos Service Mesh インストール時にアドオンとして authservice をインストールできます。authservice をインストールすると、UserAuth カスタムリソースで定義されている OIDC エンドポイント構成と他の関連設定が読み取られます。管理者は、Anthos Service Mesh ExternalAuthorization API を使用して、auth_server を Ingress のフィルタとして構成できます。

ユーザー認証サービスをインストールする

次の手順では、authservice の構成方法について説明します。

前提条件

依存ツールのインストールとクラスタの検証の手順に沿って、次の操作を行います。

次の手順に沿って、前提条件を満たしていることを確認してください。

ユーザー認証オーバーレイを使用してインストールをカスタマイズする

ユーザー認証サービスをインストールするには、Anthos Service Mesh のインストールをカスタマイズして、メッシュレベルの外部承認プロバイダを追加する必要があります。

kpt v1+

サンプルのユーザー認証オーバーレイを取得し、メッシュにカスタマイズがある場合は更新します。このオーバーレイファイルをソースコントロール内で管理することをおすすめします。

curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.1.0/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml

kpt v1-

curl https://raw.githubusercontent.com/GoogleCloudPlatform/asm-user-auth/v1.0.1/overlay/user-auth-overlay.yaml > user-auth-overlay.yaml

オーバーレイを使用して Anthos Service Mesh をインストールするに沿って、Google 提供のスクリプトを使用し、ユーザー認証オーバーレイを使用して Anthos Service Mesh をインストールします。例:
```
./asmcli install \
  --project_id "PROJECT_ID" \
  --cluster_name "CLUSTER_NAME" \
  --cluster_location "CLUSTER_LOCATION" \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --custom_overlay user-auth-overlay.yaml
```
重要: 複数のオーバーレイを使用してインストール環境をカスタマイズする場合は、--custom_overlay オプションにはすべてのオーバーレイファイルが含まれます。
ユーザー認証の kpt パッケージが AuthorizationPolicy を作成し、pkg/ext-authz.yaml で指定された外部認証プロバイダを参照します。
asm-user-auth Namespace を作成してラベルを付けます。
```
kubectl create namespace asm-user-auth
kubectl label namespace asm-user-auth istio.io/rev=REVISION --overwrite
```
REVISION ラベルの値は kubectl get pod -n istio-system -L istio.io/rev で確認できます

asm-user-auth Namespace に Istio ゲートウェイをインストールします。

kubectl apply -n asm-user-auth -f DIR_PATH/samples/gateways/istio-ingressgateway

OIDC クライアントの構成を準備する

次の手順で OIDC クライアント構成を設定します。このガイドでは Google を IDP として使用しますが、OIDC 認証をサポートする任意の IDP を使用できます。

Google Cloud コンソールで、[API とサービス] > [認証情報] に移動します。

[認証情報] に移動
[認証情報を作成] に移動し、[OAuth クライアント ID] を選択します。必要に応じて、[OAuth 同意画面] オプションを設定し、次のオプションを構成します。
- [アプリケーションの種類] を [ウェブアプリケーション] に設定します。
- [承認済みのリダイレクト URI] を https://<your-oidc-redirect-host>/<your-oidc-redirect-path> に設定します。たとえば、ローカルホストの場合、https://localhost:8443/_gcp_asm_authenticate に設定できます。
最後に [保存] をクリックします。

さらに、後で使用するために OIDC クライアントの構成を保存します。

export OIDC_CLIENT_ID='<your-client-id>'
export OIDC_CLIENT_SECRET='<your-client-secret>'
export OIDC_ISSUER_URI='https://accounts.google.com'
export OIDC_REDIRECT_HOST='https://localhost:8443'
export OIDC_REDIRECT_PATH='/_gcp_asm_authenticate'

`kpt` パッケージを入手する

公開リポジトリから推奨の authservice 構成をインストールするには、次の手順を行います。これらのコマンドは、最新の authservice コンテナを取得し、asm-user-auth 名前空間の Pod として起動します。また、すべてのリクエストをインターセプトするように Ingress を構成します。

kpt v1+

kpt パッケージを取得します。

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.1.0 .
cd asm-user-auth/

kpt v1-

kpt パッケージを取得します。

kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.0.1 .
cd asm-user-auth/

Ingress ゲートウェイのリダイレクト URL とシークレットを設定する

OAuth2 には、HTTPS で保護されたエンドポイントでホストされているリダイレクト URL が必要です。これらのコマンドはサンプル用途であり、Istio Ingress ゲートウェイの自己署名証明書を生成することで簡単に設定できます。

自己署名証明書を生成します。

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \
 -days 365 -nodes -subj '/CN=localhost'

HTTPS トラフィックをホストする Ingress ゲートウェイのシークレットを作成します。
```
kubectl create -n asm-user-auth secret tls userauth-tls-cert --key=key.pem \
--cert=cert.pem
```

暗号鍵と署名鍵を適用する

authservice が正しく動作するには、2 つの鍵セットが必要です。1 つ目は、暗号化と復号の対称鍵です。この鍵は、セッションの状態を Cookie として設定する前に、セッションの暗号化に使用します。

2 つ目は、公開鍵/秘密鍵のペアです。この鍵は、RCToken として JWT 形式で認証されたユーザー情報に署名するために使用されます。このペアの公開鍵は、サイドカーが JWT の検証に使用できる事前定義されたエンドポイントで公開されます。

ユーザー認証の kpt パッケージには、簡単に設定できるように 2 つのサンプルキーが含まれています。ただし、任意の鍵管理システムを使用して、これらの鍵を生成することもできます。

次の形式でセッション暗号鍵を準備します。または、cat ./samples/cookie_encryption_key.json で表示できる pkg のサンプルを使用します。

{
  "keys":[
     {
        "kty":"oct",
        "kid":"key-0",
        "K":"YOUR_KEY",
        "useAfter": 1612813735
     }
  ]
}

次のコマンドを使用して、テスト AES 鍵を生成できます。

openssl enc -aes-256-cbc -k mycustomkey -P -md sha1 | grep key

次の形式で RCToken 署名鍵を準備します。または、cat ./samples/rctoken_signing_key.json で表示できる pkg のサンプルを使用します。

{
  "keys":[
     {
        "kty":"RSA",
        "kid":"rsa-signing-key",
        "K":"YOUR_KEY",  # k contains a Base64 encoded PEM format RSA signing key.
        "useAfter": 1612813735  # unix timestamp
     }
  ]
}

次のコマンドを使用して、テスト 256 ビット RSA 秘密鍵を生成できます。

openssl genpkey -algorithm RSA -out rsa_private.pem -pkeyopt rsa_keygen_bits:256

authservice が独自のファイルシステムにマウントする Kubernetes Secret を作成します。

kubectl create secret generic secret-key  \
    --from-file="session_cookie.key"="./samples/cookie_encryption_key.json" \
    --from-file="rctoken.key"="./samples/rctoken_signing_key.json"  \
    --namespace=asm-user-auth

ユーザー認証サービスをデプロイする

次のコマンドは、ユーザー認証サービスとデプロイを asm-user-auth 名前空間に作成します。

kpt v1+

ユーザー認証の構成に必要な値を設定します。クライアント ID とシークレットは Kubernetes Secret として保存されるため、Base64 を使用してエンコードします。使用可能なすべてのセッターを表示するには、公開リポジトリにアクセスしてください。

kpt fn eval pkg --image gcr.io/kpt-fn/apply-setters:v0.2 --truncate-output=false -- \
  client-id="$(echo -n ${OIDC_CLIENT_ID} | base64 -w0)" \
  client-secret="$(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)" \
  issuer-uri="${OIDC_ISSUER_URI}" \
  redirect-host="${OIDC_REDIRECT_HOST}" \
  redirect-path="${OIDC_REDIRECT_PATH}"

kpt v1-

ユーザー認証の構成に必要な値を設定します。クライアント ID とシークレットは Kubernetes Secret として保存されるため、Base64 を使用してエンコードします。使用可能なすべてのセッターを表示するには、Kptfile にアクセスします。

kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientID $(echo -n ${OIDC_CLIENT_ID} | base64 -w0)
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.clientSecret $(echo -n ${OIDC_CLIENT_SECRET} | base64 -w0)
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.issuerURI ${OIDC_ISSUER_URI}
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIHost ${OIDC_REDIRECT_HOST}
kpt cfg set pkg anthos.servicemesh.user-auth.oidc.redirectURIPath ${OIDC_REDIRECT_PATH}

kpt パッケージを適用します。

# Remove the potential alpha version CRD if exists.
kubectl delete crd userauthconfigs.security.anthos.io
kubectl apply -f ./pkg/asm_user_auth_config_v1beta1.yaml
kubectl apply -f ./pkg

authservice は UserAuthConfig CRD を使用してエンドユーザー認証を行います。UserAuthConfig は実行時に構成可能で、authservice の動作を変更し、任意の OIDC 認証サーバーのエンドポイントで構成するように更新できます。

cat pkg/user_auth_config.yaml でファイルを表示できます。これには次のフィールドが含まれます。

kpt v1+

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # kpt-set: ${ca-cert}
      issuerURI: "<your issuer uri>"  # kpt-set: ${issuer-uri}
      proxy: ""  # kpt-set: ${proxy}
      oauthCredentialsSecret:
        name: "oauth-secret"  # kpt-set: ${secret-name}
        namespace: "asm-user-auth"  # kpt-set: ${secret-namespace}
      redirectURIHost: ""  # kpt-set: ${redirect-host}
      redirectURIPath: "/_gcp_asm_authenticate"  # kpt-set: ${redirect-path}
      scopes: ""  # kpt-set: ${scopes}
      groupsClaim: ""  # kpt-set: ${groups}
  outputJWTAudience: "test_audience"  # kpt-set: ${jwt-audience}

kpt v1-

apiVersion: security.anthos.io/v1beta1
kind: UserAuthConfig
metadata:
  name: user-auth-config
  namespace: asm-user-auth
spec:
  authentication:
    oidc:
      certificateAuthorityData: ""  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.certificateAuthorityData"}
      oauthCredentialsSecret:
        name: "oauth-secret"  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.oauthCredentialsSecret.name"}
        namespace: "asm-user-auth"  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.oauthCredentialsSecret.namespace"}
      issuerURI: "<your issuer uri>"  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.issuerURI"}
      proxy: ""  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.proxy"}
      redirectURIHost: ""  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.redirectURIHost"}
      redirectURIPath: "/_gcp_asm_authenticate"  # {"$ref":"#/definitions/io.k8s.cli.setters.anthos.servicemesh.user-auth.oidc.redirectURIPath"}
  outputJWTAudience: "test_audience"

user_auth_config.yaml フィールドの詳細については、ユーザー認証構成の詳細をご覧ください。

インストール後のタスクを行う

前述のインストール手順が完了した後は、以下のタスクが必要になります。

アプリケーションのユーザー認証を有効にする

このセクションでは、例として httpbin を使用して、ユーザー認証を有効にする方法について説明します。

Anthos Service Mesh ユーザー認証では、CUSTOM タイプの認証ポリシーを使用して OIDC フローをトリガーします。

Istio ゲートウェイをインストールした後、それを構成し、上記で作成した TLS 証明書 userauth-tls-cert を使用して HTTPS トラフィックを処理するようにします。以下は、インストールされた pkg/gateway.yaml 構成です。

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: userauth
  namespace: asm-user-auth
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: userauth-tls-cert
---
# This ensures the OIDC endpoint has at least some route defined.
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: userauth-oidc
  namespace: asm-user-auth
spec:
  gateways:
  - userauth
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /status
    - uri:
        prefix: "your-oidc-redirect-path"
    name: user-auth-route
    route:
    - destination:
        host: authservice
        port:
          number: 10004

デプロイで istio-proxy 自動インジェクションを有効にするには、default 名前空間にラベルを付けます。
```
kubectl label namespace default istio.io/rev=REVISION --overwrite
```

httpbin を default 名前空間にデプロイします。

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml -n default

httpbin を更新して、このゲートウェイを使って HTTPS トラフィックを処理し、ポート転送を使用してローカルでアプリケーションにアクセスします。
```
kubectl apply -f./samples/httpbin-route.yaml -n default
kubectl port-forward service/istio-ingressgateway 8443:443 -n asm-user-auth
```
ポート 8443 の Ingress ゲートウェイが localhost に転送され、アプリケーションはローカルでアクセス可能になります。

ユーザー認証を確認する

httpbin は 2 つのパスを提供します。/ip は一般公開され、/headers はエンドユーザーが構成済みの IDP を介してログインする必要があります。

https://localhost:8443/ip にアクセスして、/ip に直接アクセスできることを確認します。
https://localhost:8443/headers にアクセスして、OIDC ログインページが表示されることを確認します。
ログイン後、[次へ] をクリックして、/headers ページにリダイレクトすることを確認します。

認証ポリシーを構成する

前の手順で構成を完了すると、各ユーザーはウェブベースの認証フローにリダイレクトされます。フローが完了すると、authservice によって JWT 形式の RCToken が生成されます。これを使用して、認証されたユーザー情報が転送されます。

Ingress で Istio の認証ポリシーを追加して、認証されたユーザーごとに認証チェックが行われるようにします。
```
kubectl apply -f ./samples/httpbin-authz.yaml -n asm-user-auth
```

httpbin-authz.yaml ファイルは、Ingress ゲートウェイを構成して authservice が発行した RC トークンを検証し、JWT にオーディエンスや発行者などの目的のフィールドが含まれている場合にのみ承認します。

次の認証ポリシーの例をご覧ください。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-rc-token
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  action: ALLOW
  rules:
  - to:
    - operation:
        paths: ["/ip"]
  - to:
    when:
    - key: request.auth.claims[iss]
      values:
      - authservice.asm-user-auth.svc.cluster.local
    - key: request.auth.claims[aud]
      values:
      - test_audience
    - key: request.auth.claims[sub]
      values:
      - allowed_user_sub_1  # Change this with the "sub" claim in the RC token. Wildcard '*' will match everything.

環境固有の設定を構成する

前のステップでは、簡単にセットアップするため、localhost と自己署名 HTTPS 証明書を使用しました。本番環境用に使用する場合は、example.com などの実際のドメインを使用します。

また、certificateAuthorityData に目的のルート証明書コンテンツがあることを確認します。たとえば、IdP がシステムのルート証明書で信頼されている場合は空のままにできます。HTTPS 接続を終端する HTTPS プロキシがある場合は、プロキシのルート証明書に設定する必要があります。

鍵の管理とローテーションを行う

authservice で使用されるキーのセットは 2 つあります。各鍵を個別にローテーションできます。ただし、鍵をローテーションする前に、ローテーションの仕組みを理解しておくことが重要です。

どちらの鍵も JSON 形式です。useAfter フィールドには、鍵の使用が開始されると考えられる期間のタイムスタンプを指定します。鍵のローテーション中は、JSON に古い鍵と新しい鍵の両方を含める必要があります。たとえば、次の例では、new-key はタイムスタンプ 1712813735 の後にのみ使用されます。

{
   "keys":[
      {
         "kty":"RSA",
         "kid":"old-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1612813735, # unix timestamp
      }
      {
      "kty":"RSA",
         "kid":"new-key",
         "K":"...", # k contains a Base64 encoded PEM format RSA signing key.
         "useAfter": 1712813735, # unix timestamp
      }
   ]
}

Anthos Service Mesh では、ブラウザの Cookie に保存されるセッションデータを暗号化するために対称鍵を使用します。既存のセッションの有効性を確保するため、authservice は鍵セット内のすべての鍵で復号を試みます。ローテーション時には、authservice は新しいセッションの暗号化に新しい鍵を使用し、引き続き古い鍵による復号を試みます。

公開鍵/秘密鍵ペアは、RCToken の署名に使用されます。公開鍵は、JWT 検証のために istiod によってサイドカーに送信されます。authservice が新しい秘密鍵を使用して RCToken に署名する前に、サイドカーが新しい公開鍵を受け取ることが重要です。この目的を達成するため、authservice は、鍵が追加された直後に公開鍵の公開を開始します。ただし、その鍵を使用して RCToken に署名するまではかなりの時間待機します。

要約すると、鍵のローテーションを行うときは、次のことをおすすめします。

定期的に、または必要に応じて、鍵のローテーションを実行します。
JSON 形式で、現在の鍵と新しい鍵の両方を指定します。新しい鍵は、将来のタイムスタンプに関連付ける必要があります。タイムスタンプは現在の時刻の少なくとも数時間前に指定することをおすすめします。
新しい鍵が使用された後でもサービスが正常であるかをモニタリングし確認します。新しい鍵が使用されてから 1 日以上待ってから、次の手順に進みます。
JSON エントリから古い鍵を削除します。今後それらの鍵は不要です。

ユーザー認証構成の詳細

次の表に、CRD の各フィールドの説明を示します。

フィールド名	説明
`authentication.oidc`	このセクションには、OIDC エンドポイントの構成と、OIDC フローで使用されるパラメータが含まれます。
`authentication.oidc.certificateAuthorityData`	これは、OIDC 認証サーバーまたは HTTPS プロキシのドメイン（存在する場合）の SSL ルート証明書です。
`authentication.oidc.oauthCredentialsSecret`	Secret は、JSON ペイロードに OAuth2 OIDC の client_id と client_secret を含む Kubernetes Opaque タイプのシークレットを参照します。
`authentication.oidc.issuerURI`	出力 RCToken の発行者として使用する URI。
`authentication.oidc.proxy`	OIDC IDP へのプロキシサーバー（該当する場合）。形式 http://user:password@10.10.10.10:8888.
`authentication.oidc.redirectURIHost`	OAuth 終了 URI に使用するホスト。空白のままにすると、ターゲット URL からのホストが使用され、リダイレクト URI が動的に構成されます。この値は、より高いレベルのドメインでユーザー認証 SSO セッションが必要な場合に使用できます。たとえば、profile.example.com/ と admin.example.com/ の間で SSO を有効にするには、この値を example.com に設定します。これにより、すべてのサブドメイン間で共有されるユーザー認証セッションを example.com で確立できます。注: 同じメッシュから複数のドメイン（example1.com と example2.com）が提供されている場合、この機能は使用できないため、空白のままにすることをおすすめします。
`authentication.oidc.redirectURIPath`	`authservice` が OAuth フローを終了するエンドポイントのパス。`authentication.oidc.clientID` の承認サーバーで、この URI パスとホストを承認済みのリダイレクト URI として登録する必要があります。また、この URI は、`authservice` が有効になっている同じサービスメッシュと Ingress から提供される必要があります。
`authentication.oidc.scopes`	認証リクエストでリクエストする必要がある OAuth スコープ。「openid」スコープに加えてリクエストされているアクセス権限を指定するために使用する識別子のカンマ区切りリスト。例: "groups,allatclaim"。
`authentication.oidc.groupsClaim`	`idtoken` にグループクレームが含まれている場合は、このフィールドを使用して名前を指定します。指定すると、サービスは、このリクエストのデータを出力 RCToken の `groups` クレームに渡します。このクレームには、文字列のカンマ区切りリストを含める必要があります。例: ["group1", "group2"]。
`authentication.outputJWTAudience`	`authservice` によって生成された RCToken の対象デバイス。サイドカーは、この対象デバイス値に対して受信 RCToken を検証できます。

ユーザー認証のアップグレード

ユーザー認証パッケージには、新しいユーザー認証バージョン用の更新されたバイナリが含まれているため、再度インストールします。
```
kpt pkg get https://github.com/GoogleCloudPlatform/asm-user-auth.git/@v1.2.0 .
cd asm-user-auth/
```

OIDC クライアントの構成を保存します。

export OIDC_CLIENT_ID=CLIENT_ID
export OIDC_CLIENT_SECRET=CLIENT_SECRET
export OIDC_ISSUER_URI=ISSUER_URI
export OIDC_REDIRECT_HOST=REDIRECT_HOST
export OIDC_REDIRECT_PATH=REDIRECT_PATH

ユーザー認証サービスをデプロイして、新しいバージョンにアップグレードします。

マルチクラスタデプロイ

Anthos Service Mesh のユーザー認証では、マルチクラスタのデプロイをサポートしています。前記のように、各クラスタにユーザー認証をデプロイする必要があります。UserAuth カスタムリソース、OIDC クライアントシークレット、暗号鍵などのユーザー認証構成は、すべて各クラスタに複製する必要があります。

デフォルトでは、Ingress ゲートウェイはいずれかの authservice インスタンスへの認証リクエストを負荷分散します。宛先ルールを使用すると、同じクラスタ内の authservice にリクエストを送信し、他のクラスタの authservice にのみフェイルオーバーするように Ingress ゲートウェイを構成できます。

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: authservice-fail-over
  namespace: asm-user-auth
spec:
  host: authservice.asm-user-auth.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
        - from:  us-east
          to: us-west
        - from: us-west
          to: us-east

他の構成と同様に、各クラスタで構成する必要があります。

トラブルシューティング

IDP へのネットワークアクセス。

考えられるログ: error: TLS handshake failed.。

istio-proxy コンテナから IDP 発行者 URI への curl を実行して確認します。接続できない場合は、クラスタのファイアウォールルールまたは他のネットワーク構成を確認します。
ルート CA 証明書。

考えられるログ: error: The server's TLS certificate did not match expectations. または error: TLS handshake failed.。

certificateAuthorityData が正しいルート CA 証明書を保持していることを確認します。HTTPS トラフィックを終了する HTTPS プロキシが存在しない場合は、IDP のルート CA 証明書を保持することになります。存在する場合は、代わりにプロキシを保持することになります。
リダイレクトパスの構成。

考えられる動作: OIDC 認証フロー中に 404 エラーページが表示される。

ユーザー認証は、path 属性を使用せずに「Set-Cookie」ヘッダーを返します。デフォルトでは、ブラウザはリクエスト URL のディレクトリを Cookie パス（パスに関連する Cookie のスコープ）として使用します。そのため、意図している場合を除き、リダイレクトパスに「/」を含めないことをおすすめします。

よくある質問

ユーザー認証を有効にした Anthos Service Mesh をアップグレードするにはどうすればよいですか？

Anthos Service Mesh のアップグレードプロセスに従って、コマンドラインで --custom_overlay user-auth-overlay.yaml を asmcli install に追加してオーバーレイファイルを指定します。
authservice にはどれくらいのリソースをプロビジョニングすればよいですか。また、1 秒間に処理できるリクエスト数はどれくらいですか。

デフォルトでは、authservice は 2.0 vCPU、256Mi メモリで構成されています。このような構成では、authservice は 1 秒あたり 500 件のリクエストを処理できます。大量のリクエストを処理するには、CPU を追加する必要があります。CPU は、そのリクエストの処理能力にほぼ比例します。また、認証サービスの複数のレプリカを構成して、水平方向のスケーラビリティを高めることもできます。

Anthos Service Mesh のユーザー認証の構成

仕組み

ユーザー認証サービスをインストールする

前提条件

ユーザー認証オーバーレイを使用してインストールをカスタマイズする

kpt v1+

kpt v1-

OIDC クライアントの構成を準備する

kpt パッケージを入手する

kpt v1+

kpt v1-

Ingress ゲートウェイのリダイレクト URL とシークレットを設定する

暗号鍵と署名鍵を適用する

ユーザー認証サービスをデプロイする

kpt v1+

kpt v1-

kpt v1+

kpt v1-

インストール後のタスクを行う

アプリケーションのユーザー認証を有効にする

ユーザー認証を確認する

認証ポリシーを構成する

環境固有の設定を構成する

鍵の管理とローテーションを行う

ユーザー認証構成の詳細

ユーザー認証のアップグレード

マルチクラスタ デプロイ

トラブルシューティング

よくある質問

`kpt` パッケージを入手する

マルチクラスタデプロイ