6.3. イメージコントローラー設定パラメーター
ingresscontrollers.operator.openshift.io
リソースは以下の設定パラメーターを提供します。
パラメーター | 説明 |
---|---|
|
空の場合、デフォルト値は |
|
|
|
設定されていない場合、デフォルト値は
|
|
シークレットには以下のキーおよびデータが含まれる必要があります: *
設定されていない場合、ワイルドカード証明書は自動的に生成され、使用されます。証明書は Ingress コントーラーの 使用中の証明書 (生成されるか、ユーザー指定の場合かを問わない) は OpenShift Container Platform のビルトイン OAuth サーバーに自動的に統合されます。 |
|
|
|
|
|
設定されていない場合は、デフォルト値が使用されます。 注記
nodePlacement: nodeSelector: matchLabels: kubernetes.io/os: linux tolerations: - effect: NoSchedule operator: Exists |
|
これが設定されていない場合、デフォルト値は
Ingress コントローラーの最小の TLS バージョンは 重要
HAProxy Ingress コントローラーイメージは TLS
また、Ingress Operator は TLS
OpenShift Container Platform ルーターは、TLS_AES_128_CCM_SHA256、TLS_CHACHA20_POLY1305_SHA256、TLS_AES_256_GCM_SHA384、および TLS_AES_128_GCM_SHA256 を使用する TLS 注記
設定されたセキュリティープロファイルの暗号および最小 TLS バージョンが |
|
|
|
|
|
デフォルトでは、ポリシーは
|
すべてのパラメーターはオプションです。
6.3.1. Ingress コントローラーの TLS セキュリティープロファイル
TLS セキュリティープロファイルは、サーバーに接続する際に接続クライアントが使用できる暗号を規制する方法をサーバーに提供します。
6.3.1.1. TLS セキュリティープロファイルについて
TLS (Transport Layer Security) セキュリティープロファイルを使用して、さまざまな OpenShift Container Platform コンポーネントに必要な TLS 暗号を定義できます。OpenShift Container Platform の TLS セキュリティープロファイルは、Mozilla が推奨する設定 に基づいています。
コンポーネントごとに、以下の TLS セキュリティープロファイルのいずれかを指定できます。
プロファイル | 説明 |
---|---|
| このプロファイルは、レガシークライアントまたはライブラリーでの使用を目的としています。このプロファイルは、Old 後方互換性 の推奨設定に基づいています。
注記 Ingress コントローラーの場合、TLS の最小バージョンは 1.0 から 1.1 に変換されます。 |
| このプロファイルは、大多数のクライアントに推奨される設定です。これは、Ingress コントローラーおよびコントロールプレーンのデフォルトの TLS セキュリティープロファイルです。このプロファイルは、Intermediate 互換性 の推奨設定に基づいています。
|
| このプロファイルは、後方互換性を必要としない Modern のクライアントでの使用を目的としています。このプロファイルは、Modern 互換性 の推奨設定に基づいています。
注記
OpenShift Container Platform 4.6、4.7、および 4.8 では、 重要
|
| このプロファイルを使用すると、使用する TLS バージョンと暗号を定義できます。 警告
無効な設定により問題が発生する可能性があるため、 注記
OpenShift Container Platform ルーターは、Red Hat 分散の OpenSSL デフォルトセットの TLS |
事前定義されたプロファイルタイプのいずれかを使用する場合、有効なプロファイル設定はリリース間で変更される可能性があります。たとえば、リリース X.Y.Z にデプロイされた Intermediate プロファイルを使用する仕様がある場合、リリース X.Y.Z+1 へのアップグレードにより、新規のプロファイル設定が適用され、ロールアウトが生じる可能性があります。
6.3.1.2. Ingress コントローラーの TLS セキュリティープロファイルの設定
Ingress コントローラーの TLS セキュリティープロファイルを設定するには、IngressController
カスタムリソース (CR) を編集して、事前定義済みまたはカスタムの TLS セキュリティープロファイルを指定します。TLS セキュリティープロファイルが設定されていない場合、デフォルト値は API サーバーに設定された TLS セキュリティープロファイルに基づいています。
Old
TLS のセキュリティープロファイルを設定するサンプル IngressController
CR
apiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: old: {} type: Old ...
TLS セキュリティープロファイルは、Ingress コントローラーの TLS 接続の最小 TLS バージョンと TLS 暗号を定義します。
設定された TLS セキュリティープロファイルの暗号と最小 TLS バージョンは、Status.Tls Profile
配下の IngressController
カスタムリソース (CR) と Spec.Tls Security Profile
配下の設定された TLS セキュリティープロファイルで確認できます。Custom
TLS セキュリティープロファイルの場合、特定の暗号と最小 TLS バージョンは両方のパラメーターの下に一覧表示されます。
HAProxy Ingress コントローラーイメージは TLS 1.3
をサポートしません。Modern
プロファイルには TLS 1.3
が必要であることから、これはサポートされません。Ingress Operator は Modern
プロファイルを Intermediate
に変換します。また、Ingress Operator は TLS 1.0
の Old
または Custom
プロファイルを 1.1
に変換し、TLS 1.3
の Custom
プロファイルを 1.2
に変換します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。
手順
openshift-ingress-operator
プロジェクトのIngressController
CR を編集して、TLS セキュリティープロファイルを設定します。$ oc edit IngressController default -n openshift-ingress-operator
spec.tlsSecurityProfile
フィールドを追加します。Custom
プロファイルのサンプルIngressController
CRapiVersion: operator.openshift.io/v1 kind: IngressController ... spec: tlsSecurityProfile: type: Custom 1 custom: 2 ciphers: 3 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES128-GCM-SHA256 minTLSVersion: VersionTLS11 ...
- 変更を適用するためにファイルを保存します。
検証
IngressController
CR にプロファイルが設定されていることを確認します。$ oc describe IngressController default -n openshift-ingress-operator
出力例
Name: default Namespace: openshift-ingress-operator Labels: <none> Annotations: <none> API Version: operator.openshift.io/v1 Kind: IngressController ... Spec: ... Tls Security Profile: Custom: Ciphers: ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 Min TLS Version: VersionTLS11 Type: Custom ...
6.3.2. Ingress コントローラーエンドポイントの公開ストラテジー
NodePortService
エンドポイントの公開ストラテジー
NodePortService
エンドポイントの公開ストラテジーは、Kubernetes NodePort サービスを使用して Ingress コントローラーを公開します。
この設定では、Ingress コントローラーのデプロイメントはコンテナーのネットワークを使用します。NodePortService
はデプロイメントを公開するために作成されます。特定のノードポートは OpenShift Container Platform によって動的に割り当てられますが、静的ポートの割り当てをサポートするために、管理される NodePortService
のノードポートフィールドへの変更が保持されます。
図6.1 NodePortService の図
前述の図では、OpenShift Container Platform Ingress NodePort エンドポイントの公開戦略に関する以下のような概念を示しています。
- クラスターで利用可能なノードにはすべて、外部からアクセス可能な独自の IP アドレスが割り当てられています。クラスター内で動作するサービスは、全ノードに固有の NodePort にバインドされます。
-
たとえば、クライアントが図中の IP アドレス
10.0.128.4
に接続してダウンしているノードに接続した場合に、ノードポートは、サービスを実行中で利用可能なノードにクライアントを直接接続します。このシナリオでは、ロードバランシングは必要ありません。イメージが示すように、10.0.128.4
アドレスがダウンしており、代わりに別の IP アドレスを使用する必要があります。
Ingress Operator は、サービスの .spec.ports[].nodePort
フィールドへの更新を無視します。
デフォルトで、ポートは自動的に割り当てられ、各種の統合用のポート割り当てにアクセスできます。ただし、既存のインフラストラクチャーと統合するために静的ポートの割り当てが必要になることがありますが、これは動的ポートに対応して簡単に再設定できない場合があります。静的ノードポートとの統合を実行するには、管理対象のサービスリソースを直接更新できます。
詳細は、NodePort
についての Kubernetes サービスについてのドキュメント を参照してください。
HostNetwork
エンドポイントの公開ストラテジー
HostNetwork
エンドポイントの公開ストラテジーは、Ingress コントローラーがデプロイされるノードポートで Ingress コントローラーを公開します。
HostNetwork
エンドポイント公開ストラテジーを持つ Ingress コントローラーには、ノードごとに単一の Pod レプリカのみを設定できます。n のレプリカを使用する場合、それらのレプリカをスケジュールできる n 以上のノードを使用する必要があります。各 Pod はスケジュールされるノードホストでポート 80
および 443
を要求するので、同じノードで別の Pod がそれらのポートを使用している場合、レプリカをノードにスケジュールすることはできません。