3.7. ネットワークの設定

3.7.1. ネットワークポリシーの設定

デフォルトでは、OpenShift クラスター内のすべての Pod は、異なる名前空間にある場合でも相互に通信できます。OpenShift Dev Spaces のコンテキストでは、これにより、あるユーザープロジェクトのワークスペース Pod が別のユーザープロジェクトの別のワークスペース Pod にトラフィックを送信できるようになります。

セキュリティーのために、NetworkPolicy オブジェクトを使用してマルチテナント分離を設定し、すべての着信通信をユーザープロジェクト内の Pod に制限することができます。ただし、OpenShift Dev Spaces プロジェクトの Pod は、ユーザープロジェクトの Pod と通信できる必要があります。

前提条件

  • OpenShift クラスターには、マルチテナント分離などのネットワーク制限があります。

手順

  • allow-from-openshift-devspaces NetworkPolicy を各ユーザープロジェクトに適用します。allow-from-openshift-devspaces NetworkPolicy は、OpenShift Dev Spaces 名前空間からユーザープロジェクト内のすべての Pod への受信トラフィックを許可します。

    例3.34 allow-from-openshift-devspaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
        name: allow-from-openshift-devspaces
    spec:
        ingress:
        - from:
            - namespaceSelector:
                matchLabels:
                    kubernetes.io/metadata.name: openshift-devspaces   1
        podSelector: {}   2
        policyTypes:
        - Ingress
    1
    OpenShift Dev Spaces 名前空間。デフォルトは openshift-devspaces です。
    2
    空の podSelector は、プロジェクト内のすべての Pod を選択します。

3.7.2. Dev Spaces ホスト名の設定

この手順では、カスタムホスト名を使用するように OpenShift Dev Space を設定する方法を説明します。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照してください。
  • 証明書とプライベートキーファイルが生成されます。
重要

秘密鍵と証明書のペアを生成するには、他の OpenShift Dev Spaces ホストと同じ認証局 (CA) を使用する必要があります。

重要

DNS プロバイダーに対し、カスタムホスト名をクラスター Ingress を参照するよう要求します。

手順

  1. OpenShift Dev Spaces のプロジェクトを作成します。

    $ oc create project openshift-devspaces
  2. TLS Secret を作成します。

    $ oc create secret TLS <tls_secret_name> \ 1
    --key <key_file> \ 2
    --cert <cert_file> \ 3
    -n openshift-devspaces
    1
    TLS Secret 名
    2
    プライベートキーを含むファイル
    3
    証明書を含むファイル
  3. シークレットに必要なラベルを追加します。

    $ oc label secret <tls_secret_name> \ 1
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    1
    TLS Secret 名
  4. CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」を参照してください。

    spec:
      networking:
        hostname: <hostname>     1
        tlsSecretName: <secret>  2
    1
    カスタム Red Hat OpenShift Dev Spaces サーバーのホスト名
    2
    TLS Secret 名
  5. OpenShift Dev Spaces がすでにデプロイされている場合は、すべての OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。

3.7.3. 信頼されていない TLS 証明書を Dev Spaces にインポートする

外部サービスとの OpenShift Dev Spaces コンポーネントの通信は、TLS で暗号化されます。信頼できる認証局 (CA) によって署名された TLS 証明書が必要です。したがって、以下のような外部サービスで使用されていて、信頼されていない CA チェーンをすべて OpenShift Dev Spaces にインポートする必要があります。

  • プロキシー
  • ID プロバイダー (OIDC)
  • ソースコードリポジトリープロバイダー (Git)

OpenShift Dev Spaces は、OpenShift Dev Spaces プロジェクトのラベル付き ConfigMap を TLS 証明書のソースとして使用します。ConfigMap には、それぞれ任意の数の証明書と、任意の数の鍵を指定できます。

注記

OpenShift クラスターにクラスター全体の信頼できる CA 証明書が クラスター全体のプロキシー設定 を通じて追加されている場合、OpenShift DevSpaces Operator はそれらを検出し、config.openshift.io/inject-trusted-cabundle="true" ラベルを ConfigMap につけて自動的に挿入します。このアノテーションに基づいて、OpenShift は Config Map の ca-bundle.crt キー内にクラスター全体で信頼される CA 証明書を自動的に挿入します。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照してください。
  • openshift-devspaces プロジェクトが存在する。
  • インポートする CA チェーンごとに root CA と中間証明書がある (PEM 形式、ca-cert-for-devspaces-<count>.pem ファイル)。

手順

  1. インポートするすべての CA チェーン PEM ファイルを custom-ca-certificates.pem ファイルに連結し、Java トラストストアと互換性のない戻り文字を削除します。

    $ cat ca-cert-for-{prod-id-short}-*.pem | tr -d '\r' > custom-ca-certificates.pem
  2. 必要な TLS 証明書を使用して custom-ca-certificates Config Map を作成します。

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
  3. custom-ca-certificates Config Map にラベルを付けます。

    $ oc label configmap custom-ca-certificates \
        app.kubernetes.io/component=ca-bundle \
        app.kubernetes.io/part-of=che.eclipse.org \
        --namespace=openshift-devspaces
  4. 以前にデプロイされていない場合は、OpenShift Dev Spaces をデプロイします。それ以外の場合は、OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。
  5. 変更を有効にするには、実行中のワークスペースを再起動します。

検証手順

  1. Config Map にカスタム CA 証明書が含まれていることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

    $ oc get configmap \
        --namespace=openshift-devspaces \
        --output='jsonpath={.items[0:].data.custom-ca-certificates\.pem}' \
        --selector=app.kubernetes.io/component=ca-bundle,app.kubernetes.io/part-of=che.eclipse.org
  2. OpenShift Dev Spaces Pod に、ca-certs-merged Config Mapをマウントするボリュームが含まれていることを確認します。

    $ oc get pod \
        --selector=app.kubernetes.io/component=devspaces \
        --output='jsonpath={.items[0].spec.volumes[0:].configMap.name}' \
        --namespace=openshift-devspaces \
        | grep ca-certs-merged
  3. OpenShift Dev Spaces サーバーコンテナーにカスタム CA 証明書があることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

    $ oc exec -t deploy/devspaces \
        --namespace=openshift-devspaces \
        -- cat /public-certs/custom-ca-certificates.pem
  4. OpenShift Dev Spaces サーバーログで、インポートされた証明書の数が null でないことを確認します。

    $ oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep custom-ca-certificates.pem
  5. 証明書の SHA256 フィンガープリントを一覧表示します。

    $ for certificate in ca-cert*.pem ;
      do openssl x509 -in $certificate -digest -sha256 -fingerprint -noout | cut -d= -f2;
      done
  6. OpenShift Dev Spaces サーバーの Java トラストストアに同じフィンガープリントを持つ証明書が含まれていることを確認します。

    $ oc exec -t deploy/devspaces --namespace=openshift-devspaces -- \
        keytool -list -keystore /home/user/cacerts \
        | grep --after-context=1 custom-ca-certificates.pem
  7. ワークスペースを開始し、これが作成されたプロジェクト名 <workspace_namespace> を取得して、ワークスペースが開始されるのを待ちます。
  8. che-trusted-ca-certs Config Mapにカスタム CA 証明書が含まれていることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

    $ oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.custom-ca-certificates\.custom-ca-certificates\.pem}'
  9. ワークスペース Pod が che-trusted-ca-certs Config Mapをマウントすることを確認します。

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep che-trusted-ca-certs
  10. Universal-developer-image コンテナー (またはワークスペース devfile で定義されたコンテナー) が che-trusted-ca-certs ボリュームをマウントしていることを確認します。

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.containers[0:]}' \
        | jq 'select (.volumeMounts[].name == "che-trusted-ca-certs") | .name'
  11. ワークスペース Pod 名 <workspace_pod_name> を取得します。

    $ oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].metadata.name}' \
  12. ワークスペースコンテナーにカスタム CA 証明書があることを確認します。このコマンドは、カスタム CA 証明書を PEM 形式で返します。

    $ oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /public-certs/custom-ca-certificates.custom-ca-certificates.pem

3.7.4. OpenShift ルートの設定

組織で必要な場合は、OpenShift Route のラベルとアノテーションを設定できます。

前提条件

  • 宛先 OpenShift クラスターへの管理権限を持つアクティブな oc セッション。CLI の使用方法 を参照してください。
  • OpenShift で実行される OpenShift Dev Spaces のインスタンス。

手順

  • CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」を参照してください。

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_INFRA_KUBERNETES_INGRESS_LABELS: <labels> 1
            CHE_INFRA_KUBERNETES_INGRESS_ANNOTATIONS__JSON: "<annotations>" 2
        networking:
          labels: <labels> 3
          annotations: <annotations> 4
    1 3
    OpenShift Route のラベルのコンマ区切りリスト: key1=value1,key2=value2
    2 4
    JSON 形式の OpenShift Route のアノテーション: {"key1": "value1", "key2" : "value2"}

3.7.5. OpenShift ルートの設定

OpenShift Route が ルーターのシャード化 と連携するようにラベル、アノテーション、およびドメインを設定できます。

前提条件

手順

  • CheCluster カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」を参照してください。

    spec:
      components:
        cheServer:
          extraProperties:
            CHE_INFRA_OPENSHIFT_ROUTE_LABELS: <labels> 1
            CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: <domain> 2
        networking:
          labels: <labels> 3
          domain: <domain> 4
          annotations: <annotations> 5
    1 3
    ターゲット Ingress コントローラーがルートからサービスのセットをフィルターリングする時に使用するラベルのコンマ区切りリスト。
    2 4
    ターゲット Ingress コントローラーが提供する DNS 名。
    5
    リソースと共に格納される構造化されていないキー値マップ。