追加の承認ポリシーが有効になっている場合に、Knativeサービスへのリクエストを有効にする¶

アクティベーターやオートスケーラーコンポーネントなどのKnative Servingシステムポッドは、デプロイされたKnativeサービスへのアクセスが必要です。Istioの承認ポリシーなどの追加のセキュリティ機能を設定した場合は、これらのシステムポッドがKnativeサービスにアクセスできるようにする必要があります。

始める前に¶

Istio AuthorizationPolicyを使用するには、次の前提条件を満たしている必要があります。

Knative IngressにはIstioを使用する必要があります。ネットワーク層のインストールを参照してください。
Istioサイドカーの注入を有効にする必要があります。Istioドキュメントを参照してください。

Knativeでの相互TLS¶

Knativeのリクエストはアクティベーターを経由してルーティングされることが多いため、相互TLSを使用する際にはいくつかの考慮事項があります。

Knative request flow

一般的に、相互TLSはIstioのドキュメントのように通常どおり設定できます。ただし、アクティベーターがKnativeサービスのリクエストパスに含まれる可能性があるため、サイドカーを注入する必要があります。これを行う最も簡単な方法は、`knative-serving`名前空間にラベルを付けることです。

kubectl label namespace knative-serving istio-injection=enabled

アクティベーターが注入されていない場合

PERMISSIVEモードでは、アクティベーターによって転送された場合、期待される`X-Forwarded-Client-Cert`ヘッダーなしでリクエストが表示されます。

$ kubectl exec deployment/httpbin -c httpbin -it -- curl -s http://httpbin.knative.svc.cluster.local/headers
{
  "headers": {
    "Accept": "*/*",
    "Accept-Encoding": "gzip",
    "Forwarded": "for=10.72.0.30;proto=http",
    "Host": "httpbin.knative.svc.cluster.local",
    "K-Proxy-Request": "activator",
    "User-Agent": "curl/7.58.0",
    "X-B3-Parentspanid": "b240bdb1c29ae638",
    "X-B3-Sampled": "0",
    "X-B3-Spanid": "416960c27be6d484",
    "X-B3-Traceid": "750362ce9d878281b240bdb1c29ae638",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-Internal": "true"
  }
}

STRICTモードでは、リクエストは単に拒否されます。

リクエストがアクティベーターによって転送されるタイミングを理解するには、ターゲットバースト容量のドキュメントを参照してください。

これは、多くのIstio AuthorizationPolicyが期待どおりに動作しないことを意味します。たとえば、特定のソースからのリクエストをKnativeサービスに許可するルールを設定した場合、アクティベーターによって転送されたリクエストは拒否されます。

たとえば、次のポリシーは、`serving-tests`名前空間内のポッド内からのリクエストを、`serving-tests`名前空間内の他のポッドに許可します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-serving-tests
 namespace: serving-tests
spec:
 action: ALLOW
 rules:
 - from:
   - source:
      namespaces: ["serving-tests"]

アクティベーターによって転送された場合、ここでリクエストは失敗します。これは、宛先サービスのIstioプロキシがリクエストのソース名前空間を`knative-serving`（アクティベーターの名前空間）として認識するためです。

現在、これを回避する最も簡単な方法は、たとえば、前述のポリシーのリストに`knative-serving`名前空間を追加することによって、`knative-serving`名前空間からのリクエストを明示的に許可することです。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: allow-serving-tests
 namespace: serving-tests
spec:
 action: ALLOW
 rules:
 - from:
   - source:
      namespaces: ["serving-tests", "knative-serving"]

ヘルスチェックとメトリクスの収集¶

アプリケーションパスを許可することに加えて、システムポッドからアプリケーションへのヘルスチェックとメトリクスの収集を許可するようにIstio AuthorizationPolicyを設定する必要があります。パスによってシステムポッドからのアクセスを許可できます。

パスによるシステムポッドからのアクセスの許可¶

Knativeシステムポッドは、次のパスを使用してアプリケーションにアクセスします。

/metrics
/healthz

`/metrics`パスは、オートスケーラーポッドがメトリクスを収集することを許可します。`/healthz`パスは、システムポッドがサービスをプローブすることを許可します。

AuthorizationPolicyに`/metrics`と`/healthz`パスを追加するには

次の例を使用して、AuthorizationPolicyのYAMLファイルを作成します。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allowlist-by-paths
  namespace: serving-tests
spec:
  action: ALLOW
  rules:
  - to:
    - operation:
        paths:
        - /metrics   # The path to collect metrics by system pod.
        - /healthz   # The path to probe by system pod.

次のコマンドを実行してYAMLファイルを適用します。
```
kubectl apply -f <filename>.yaml
```
ここで、``は前の手順で作成したファイル名です。