28.2. セキュリティー保護されたルート
セキュアなルートは、複数の TLS 終端タイプを使用してクライアントに証明書を提供できます。以下のセクションでは、カスタム証明書を使用して re-encrypt、edge、および passthrough ルートを作成する方法を説明します。
パブリックエンドポイントを使用して Microsoft Azure にルートを作成する場合、リソース名は制限されます。特定の用語を使用するリソースを作成することはできません。Azure が制限する語のリストは、Azure ドキュメントの Resolve reserved resource name errors を参照してください。
28.2.1. カスタム証明書を使用した re-encrypt ルートの作成
oc create route コマンドを使用し、カスタム証明書と共に reencrypt TLS termination を使用してセキュアなルートを設定できます。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および reencrypt TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。また、Ingress Controller がサービスの証明書を信頼できるように宛先 CA 証明書を指定する必要もあります。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、tls.key、cacert.crt、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のある Service リソースに置き換えます。www.example.com を適切な名前に置き換えます。
reencrypt TLS 終端およびカスタム証明書を使用してセキュアな
Routeリソースを作成します。$ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com
結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend spec: host: www.example.com to: kind: Service name: frontend tls: termination: reencrypt key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- destinationCACertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE-----他のオプションについては、
oc create route reencrypt --helpを参照してください。
28.2.2. カスタム証明書を使用した edge ルートの作成
oc create route コマンドを使用し、edge TLS termination とカスタム証明書を使用してセキュアなルートを設定できます。edge ルートの場合、Ingress Controller は、トラフィックを宛先 Pod に転送する前に TLS 暗号を終了します。ルートは、Ingress Controller がルートに使用する TLS 証明書およびキーを指定します。
前提条件
- PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
- 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
- 公開する必要のあるサービスが必要です。
パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。
$ openssl rsa -in password_protected_tls.key -out tls.key
手順
この手順では、カスタム証明書および edge TLS termination を使用して Route リソースを作成します。以下では、証明書/キーのペアが現在の作業ディレクトリーの tls.crt および tls.key ファイルにあることを前提としています。必要な場合には、証明書チェーンを完了するために CA 証明書を指定することもできます。tls.crt、tls.key、および (オプションで) ca.crt を実際のパス名に置き換えます。frontend を、公開する必要のあるサービスの名前に置き換えます。www.example.com を適切な名前に置き換えます。
edge TLS termination およびカスタム証明書を使用して、セキュアな
Routeリソースを作成します。$ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com
結果として生成される
Routeリソースを検査すると、以下のようになります。セキュアなルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: frontend spec: host: www.example.com to: kind: Service name: frontend tls: termination: edge key: |- -----BEGIN PRIVATE KEY----- [...] -----END PRIVATE KEY----- certificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE----- caCertificate: |- -----BEGIN CERTIFICATE----- [...] -----END CERTIFICATE-----他のオプションについては、
oc create route edge --helpを参照してください。
28.2.3. passthrough ルートの作成
oc create route コマンドを使用し、passthrough termination を使用してセキュアなルートを設定できます。passthrough termination では、暗号化されたトラフィックが TLS 終端を提供するルーターなしに宛先に直接送信されます。そのため、ルートでキーや証明書は必要ありません。
前提条件
- 公開する必要のあるサービスが必要です。
手順
Routeリソースを作成します。$ oc create route passthrough route-passthrough-secured --service=frontend --port=8080
結果として生成される
Routeリソースを検査すると、以下のようになります。passthrough termination を使用したセキュリティー保護されたルート
apiVersion: route.openshift.io/v1 kind: Route metadata: name: route-passthrough-secured 1 spec: host: www.example.com port: targetPort: 8080 tls: termination: passthrough 2 insecureEdgeTerminationPolicy: None 3 to: kind: Service name: frontend
宛先 Pod は、エンドポイントでトラフィックに証明書を提供します。これは、必須となるクライアント証明書をサポートするための唯一の方法です (相互認証とも呼ばれる)。
28.2.4. 外部管理証明書を使用したルートの作成
TLS シークレット内の外部証明書を使用してルートを保護する機能は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
ルート API の .spec.tls.externalCertificate フィールドを使用して、サードパーティーの証明書管理ソリューションで OpenShift Container Platform ルートを設定できます。シークレットを介して外部で管理されている TLS 証明書を参照できるため、手動での証明書管理が不要になります。外部で管理される証明書を使用するとエラーが減り、証明書の更新がよりスムーズに展開されるため、OpenShift ルーターは更新された証明書を迅速に提供できるようになります。
この機能は、エッジルートと再暗号化ルートの両方に適用されます。
前提条件
-
RouteExternalCertificateフィーチャーゲートを有効にする必要があります。 -
routes/custom-hostに対するcreateおよびupdate権限が必要です。 -
tls.keyキーとtls.crtキーの両方を含む、kubernetes.io/tlsタイプの PEM エンコード形式の有効な証明書/キーペアを含むシークレットが必要です。 - 参照されるシークレットは、保護するルートと同じ namespace に配置する必要があります。
手順
次のコマンドを実行して、シークレットと同じ namespace に
roleを作成し、ルーターサービスアカウントに読み取りアクセスを許可します。$ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \ 1 --namespace=<current-namespace> 2
次のコマンドを実行して、シークレットと同じ namespace に
rolebindingを作成し、ルーターサービスアカウントを新しく作成されたロールにバインドします。$ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace> 1- 1
- シークレットとルートの両方が存在する namespace を指定します。
次の例を使用して、
routeを定義し、証明書を含むシークレットを指定する YAML ファイルを作成します。セキュアなルートの YAML 定義
apiVersion: route.openshift.io/v1 kind: Route metadata: name: myedge namespace: test spec: host: myedge-test.apps.example.com tls: externalCertificate: name: <secret-name> 1 termination: edge [...] [...]- 1
- シークレットの実際の名前を指定します。
次のコマンドを実行して
routeリソースを作成します。$ oc apply -f <route.yaml> 1- 1
- 生成された YAML ファイル名を指定します。
シークレットが存在し、証明書/キーペアがある場合、すべての前提条件が満たされていれば、ルーターは生成された証明書を提供します。
.spec.tls.externalCertificate が指定されていないと、ルーターはデフォルトで生成された証明書を使用します。
.spec.tls.externalCertificate フィールドを使用する場合は、.spec.tls.certificate フィールドまたは .spec.tls.key フィールドを指定することはできません。
関連情報
- 外部で管理される証明書を使用したルートのトラブルシューティングについては、OpenShift Container Platform ルーター Pod のログでエラーを確認してください。Pod の問題の調査 を参照してください。
