Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

19.2. セキュリティー保護されたルート

セキュアなルートは、複数の TLS 終端タイプを使用してクライアントに証明書を提供できます。以下のセクションでは、カスタム証明書を使用して re-encrypt、edge、および passthrough ルートを作成する方法を説明します。

重要

パブリックエンドポイントを使用して Microsoft Azure にルートを作成する場合、リソース名は制限されます。特定の用語を使用するリソースを作成することはできません。Azure が制限する語のリストは、Azure ドキュメントの Resolve reserved resource name errors を参照してください。

19.2.1. カスタム証明書を使用した re-encrypt ルートの作成

oc create route コマンドを使用し、カスタム証明書と共に reencrypt TLS termination を使用してセキュアなルートを設定できます。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • PEM エンコードされたファイルの別の宛先 CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。
注記

パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。

Copy to Clipboard Toggle word wrap 
$ 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 リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ 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 定義

    Copy to Clipboard Toggle word wrap 
    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 を参照してください。

19.2.2. カスタム証明書を使用した edge ルートの作成

oc create route コマンドを使用し、edge TLS termination とカスタム証明書を使用してセキュアなルートを設定できます。edge ルートの場合、Ingress Controller は、トラフィックを宛先 Pod に転送する前に TLS 暗号を終了します。ルートは、Ingress Controller がルートに使用する TLS 証明書およびキーを指定します。

前提条件

  • PEM エンコードされたファイルに証明書/キーのペアが必要です。ここで、証明書はルートホストに対して有効となっています。
  • 証明書チェーンを完了する PEM エンコードされたファイルの別の CA 証明書が必要です。
  • 公開する必要のあるサービスが必要です。
注記

パスワードで保護されるキーファイルはサポートされません。キーファイルからパスフレーズを削除するには、以下のコマンドを使用します。

Copy to Clipboard Toggle word wrap 
$ 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 リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

    結果として生成される Route リソースを検査すると、以下のようになります。

    セキュアなルートの YAML 定義

    Copy to Clipboard Toggle word wrap 
    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 を参照してください。

19.2.3. passthrough ルートの作成

oc create route コマンドを使用し、passthrough termination を使用してセキュアなルートを設定できます。passthrough termination では、暗号化されたトラフィックが TLS 終端を提供するルーターなしに宛先に直接送信されます。そのため、ルートでキーや証明書は必要ありません。

前提条件

  • 公開する必要のあるサービスが必要です。

手順

  • Route リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

    結果として生成される Route リソースを検査すると、以下のようになります。

    passthrough termination を使用したセキュリティー保護されたルート

    Copy to Clipboard Toggle word wrap 
    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

    1
    オブジェクトの名前で、63 文字に制限されます。
    2
    termination フィールドを passthrough に設定します。これは、必要な唯一の tls フィールドです。
    3
    オプションの insecureEdgeTerminationPolicy。唯一有効な値は None、Redirect、または空の値です (無効にする場合)。

    宛先 Pod は、エンドポイントでトラフィックに証明書を提供します。これは、必須となるクライアント証明書をサポートするための唯一の方法です (相互認証とも呼ばれる)。

19.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 に配置する必要があります。

手順

  1. 次のコマンドを実行して、シークレットと同じ namespace に role を作成し、ルーターサービスアカウントに読み取りアクセスを許可します。

    Copy to Clipboard Toggle word wrap 
    $ oc create role secret-reader --verb=get,list,watch --resource=secrets --resource-name=<secret-name> \
    1 
    
--namespace=<current-namespace>
    2
    1
    シークレットの実際の名前を指定します。
    2
    シークレットとルートの両方が存在する namespace を指定します。

  2. 次のコマンドを実行して、シークレットと同じ namespace に rolebinding を作成し、ルーターサービスアカウントを新しく作成されたロールにバインドします。

    Copy to Clipboard Toggle word wrap 
    $ oc create rolebinding secret-reader-binding --role=secret-reader --serviceaccount=openshift-ingress:router --namespace=<current-namespace>
    1
    1
    シークレットとルートの両方が存在する namespace を指定します。

  3. 次の例を使用して、route を定義し、証明書を含むシークレットを指定する YAML ファイルを作成します。

    セキュアなルートの YAML 定義

    Copy to Clipboard Toggle word wrap 
    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
    シークレットの実際の名前を指定します。

  4. 次のコマンドを実行して route リソースを作成します。

    Copy to Clipboard Toggle word wrap 
    $ 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 の問題の調査 を参照してください。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.