要求認証

RequestAuthentication は、ワークロードでサポートされているリクエスト認証方式を定義します。設定された認証ルールに基づいて、リクエストに無効な認証情報が含まれている場合、リクエストは拒否されます。認証クレデンシャルが含まれていないリクエストは受け入れられますが、認証されたIDは持ちません。認証されたリクエストのみにアクセスを制限するには、認可ルールを साथに使用する必要があります。 例

• ラベルapp:httpbinを持つワークロードのすべてのリクエストにJWTを必須にする

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "issuer-foo"
    jwksUri: https://example.com/.well-known/jwks.json
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]

• ルート名前空間（デフォルトでは「istio-system」）のポリシーは、メッシュ内のすべての名前空間のワークロードに適用されます。次のポリシーは、すべてのワークロードが有効なJWTトークンを含むリクエストのみを受け入れるようにします。

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: req-authn-for-all
  namespace: istio-system
spec:
  jwtRules:
  - issuer: "issuer-foo"
    jwksUri: https://example.com/.well-known/jwks.json
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt-for-all
  namespace: istio-system
spec:
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]

• 次の例は、異なるhostに対して異なるJWT要件を設定する方法を示しています。 RequestAuthenticationは、issuer-fooまたはissuer-barのいずれかによって発行されたJWTを受け入れることができると宣言しています（公開鍵セットはOpenID Connectの仕様から暗黙的に設定されます）。

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  jwtRules:
  - issuer: "issuer-foo"
  - issuer: "issuer-bar"
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  rules:
  - from:
    - source:
        requestPrincipals: ["issuer-foo/*"]
    to:
    - operation:
        hosts: ["example.com"]
  - from:
    - source:
        requestPrincipals: ["issuer-bar/*"]
    to:
    - operation:
        hosts: ["another-host.com"]

• パスごとに異なる要件を設定するように、認可ポリシーを微調整できます。たとえば、/healthzを除くすべてのパスでJWTを要求するには、同じRequestAuthenticationを使用できますが、認可ポリシーは次のようになります。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  selector:
    matchLabels:
      app: httpbin
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]
  - to:
    - operation:
        paths: ["/healthz"]

[実験的] 派生したメタデータに基づくルーティングがサポートされるようになりました。プレフィックス「@」は、リクエストのヘッダーではなく、内部メタデータとの一致を示すために使用されます。現在、この機能は次のメタデータに対してのみサポートされています。

• request.auth.claims.{claim-name}[.{nested-claim}]*は、検証済みのJWTトークンから抽出されます。ネストされたクレーム名には、セパレータとして.または[]を使用します。例：request.auth.claims.sub、request.auth.claims.name.givenName、request.auth.claims[foo.com/name]。詳細については、JWTクレームベースのルーティングを参照してください。

JWTクレームメタデータとの一致の使用は、Gatewayでのみサポートされています。次の例を示します。

• JWTをデコードおよび検証するためのRequestAuthentication。これにより、@request.auth.claimsをVirtualServiceで使用できるようになります。
• リクエストに有効なプリンシパルがあるかどうかを確認するためのAuthorizationPolicy。これにより、リクエストにJWTが必要になります。
• 「sub」クレームに基づいてリクエストをルーティングするためのVirtualService。

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: jwt-on-ingress
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  jwtRules:
  - issuer: "example.com"
    jwksUri: https://example.com/.well-known/jwks.json
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  rules:
  - from:
    - source:
        requestPrincipals: ["*"]
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: route-jwt
spec:
  hosts:
  - foo.prod.svc.cluster.local
  gateways:
  - istio-ingressgateway
  http:
  - name: "v2"
    match:
    - headers:
        "@request.auth.claims.sub":
          exact: "dev"
    route:
    - destination:
        host: foo.prod.svc.cluster.local
        subset: v2
  - name: "default"
    route:
    - destination:
        host: foo.prod.svc.cluster.local
        subset: v1

RFC 7519で定義されている、認証用のJSON Webトークン（JWT）トークン形式。OAuth 2.0とOIDC 1.0を参照して、認証フロー全体でどのように使用されるかを確認してください。

例

https://example.comによって発行されたJWTの仕様。対象ユーザーのクレームは、bookstore_android.apps.example.comまたはbookstore_web.apps.example.comのいずれかである必要があります。トークンは、Authorizationヘッダー（デフォルト）に表示する必要があります。JSON Web Key Set（JWKS）は、OpenID Connectプロトコルに従って検出されます。

issuer: https://example.com
audiences:
- bookstore_android.apps.example.com
  bookstore_web.apps.example.com

この例では、デフォルト以外の場所（x-goog-iap-jwt-assertionヘッダー）にあるトークンを指定しています。また、JWKSを取得するURIを明示的に定義しています。

issuer: https://example.com
jwksUri: https://example.com/.secret/jwks.json
fromHeaders:
- "x-goog-iap-jwt-assertion"

audiences:
- bookstore_android.apps.example.com
  bookstore_web.apps.example.com

  fromHeaders:
  - name: x-jwt-assertion
    prefix: "Bearer "

  fromParams:
  - "my_token"

  from_cookies:
  - auth-token

  outputClaimToHeaders:
  - header: x-my-company-jwt-group
    claim: my-group
  - header: x-test-environment-flag
    claim: test-flag
  - header: x-jwt-claim-group
    claim: nested.key.group

このメッセージは、JWTトークンを抽出するヘッダーの場所を指定します。

このメッセージは、クレームをヘッダーにコピーするための詳細を指定します。