Serving 暗号化の概要¶

警告

Knative Serving の暗号化機能である cluster-local-domain-tls および system-internal-tls は実験段階です。注意して使用してください。

Knative Serving の暗号化には 3 つの部分があります

クラスターの外部のイングレスレイヤー上の HTTPS (myapp-<namespace>.example.com のようなクラスター外部ドメイン)。
クラスターの内部のイングレスレイヤー上の HTTPS (myapp.<namespace>.svc.cluster.local のようなクラスターローカルドメイン)。
Knative 内部コンポーネント (ingress-controller、activator、queue-proxy) 間の HTTPS。

Overview of Knative encryption

注

現在、すべてのコントロールプレーンのトラフィック (Kubernetes PreStopHooks やメトリクスのようなメタデータを含む) は暗号化されていません。

詳細な構成要素¶

異なる部分は互いに独立しており、証明書に署名するために異なる認証局を使用できます。

External domain

証明書の CN/SAN には、myapp-<namespace>.example.com のような Knative Service の外部ドメインが含まれます。
証明書は、イングレスコントローラーの外部エンドポイントによって SNI を使用してホストされます。
呼び出し元は、証明書に署名した (外部) CA を信頼する必要があります (これは Knative の範囲外です)。
これらの証明書は、手動で提供されるか、自動証明書プロビジョニングを有効にすることで提供されます。

この機能の詳細については、外部ドメインの暗号化の構成を参照してください。

Cluster local domain

証明書の CN/SAN には、myapp.namespace.svc.cluster.local、myapp.namespace.svc、myapp.namespace のような Knative Service のクラスターローカルドメインが含まれます。
証明書は、イングレスコントローラーのクラスターローカルのエンドポイントによって SNI を使用してホストされます。
呼び出し元は、証明書に署名した CA を信頼する必要があります (これは Knative の範囲外です)。これを実行する 1 つのオプションは、cert-manager の trust-manager を使用することです。
証明書を作成するために、Knative は cert-manager および Knative cert-manager 統合に依存しています。この機能を動作させるには、これらをインストールして構成する必要があります。

この機能の詳細については、クラスターローカルドメインの暗号化の構成を参照してください。

Knative system internal

この構成が有効になっている場合、Knative システム内部コンポーネント (Ingress-Controller、Activator、Queue-Proxy) は TLS エンドポイントをホストしています。

証明書を作成するために、Knative は cert-manager および Knative cert-manager 統合に依存しています。この機能を動作させるには、これらをインストールして構成する必要があります。
特定の SAN は、各接続を検証するために使用されます。各コンポーネントは、証明書に署名した CA (場合によってはフルチェーン) を信頼する必要があります。このために、Knative システムコンポーネントは、提供された CABundle を消費して信頼します。CA バンドルは、クラスター管理者によって提供される必要があり、場合によっては cert-manager の trust-manager を使用して提供される必要があります。

この機能の詳細については、Knative システム内部の暗号化の構成を参照してください。