4.8. ネットワークの設定


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

デフォルトでは、OpenShift クラスター内のすべての Pod は、異なる namespace にある場合でも相互に通信できます。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 namespace からユーザープロジェクト内のすべての Pod への受信トラフィックを許可します。

    例4.45 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
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    空の podSelector は、プロジェクト内のすべての Pod を選択します。
  • オプション: ネットワークポリシーによるマルチテナント分離の設定 を適用した場合は、allow-from-openshift-apiserver および allow-from-workspaces-namespaces NetworkPolicies も openshift-devspaces に適用する必要があります。allow-from-openshift-apiserver NetworkPolicy は、openshift-apiserver namespace から devworkspace-webhook-server への受信トラフィックを許可し、Webhook を有効にします。allow-from-workspaces-namespaces NetworkPolicy は、各ユーザープロジェクトから che-gateway Pod への受信トラフィックを許可します。

    例4.46 allow-from-openshift-apiserver.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-openshift-apiserver
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector:
        matchLabels:
          app.kubernetes.io/name: devworkspace-webhook-server   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  kubernetes.io/metadata.name: openshift-apiserver
      policyTypes:
        - Ingress
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    podSelector は、devworkspace-webhook-server Pod のみを選択します

    例4.47 allow-from-workspaces-namespaces.yaml

    apiVersion: networking.k8s.io/v1
    kind: NetworkPolicy
    metadata:
      name: allow-from-workspaces-namespaces
      namespace: openshift-devspaces   
    1
    
    spec:
      podSelector: {}   
    2
    
      ingress:
        - from:
            - podSelector: {}
              namespaceSelector:
                matchLabels:
                  app.kubernetes.io/component: workspaces-namespace
      policyTypes:
        - Ingress
    Copy to Clipboard Toggle word wrap
    1
    OpenShift Dev Spaces namespace。デフォルトは openshift-devspaces です。
    2
    空の podSelector は、OpenShift Dev Spaces namespace 内のすべての Pod を選択します。
  • 「プロジェクトの設定」
  • ネットワーク分離
  • ネットワークポリシーを使用したマルチテナント分離の設定

4.8.2. Dev Spaces ホスト名の設定

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

前提条件

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

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

重要

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

手順

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

    $ oc create project openshift-devspaces
    Copy to Clipboard Toggle word wrap
  2. TLS Secret を作成します。

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

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

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

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

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

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

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

  • OpenShift Dev Spaces サーバーおよびダッシュボード Pod の /public-certs
  • ワークスペース Pod の /etc/pki/ca-trust/extracted/pem

/etc/pki/ca-trust/extracted/pem への CA バンドルのマウントを無効にするように CheCluster カスタムリソースを設定します。以前のバージョンの動作を維持するために、証明書は /public-certs にマウントされます。

注記

パス /etc/pki/ca-trust/extracted/pem 配下の CA バンドルのマウントを無効にするように CheCluster カスタムリソースを設定します。この場合、証明書はパス /public-certs の下にマウントされます。

spec:
  devEnvironments:
    trustedCerts:
      disableWorkspaceCaBundleMount: true
Copy to Clipboard Toggle word wrap
重要

OpenShift クラスターでは、OpenShift Dev Spaces Operator により、マウントされた証明書に Red Hat Enterprise Linux CoreOS (RHCOS) トラストバンドルが自動的に追加されます。

前提条件

  • 宛先 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-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
    Copy to Clipboard Toggle word wrap
  2. 必要な TLS 証明書を使用して custom-ca-certificates ConfigMap を作成します。

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
    Copy to Clipboard Toggle word wrap
  3. custom-ca-certificates ConfigMap にラベルを付けます。

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

検証手順

  1. ConfigMap にカスタム 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
    Copy to Clipboard Toggle word wrap
  2. OpenShift Dev Spaces サーバーログで、インポートされた証明書の数が null でないことを確認します。

    oc logs deploy/devspaces --namespace=openshift-devspaces \
        | grep tls-ca-bundle.pem
    Copy to Clipboard Toggle word wrap
  3. ワークスペースを起動し、ワークスペースが作成されたプロジェクト名 (<workspace_namespace>) を取得し、ワークスペースが起動するまで待機します。
  4. ca-certs-merged ConfigMap にカスタム CA 証明書が含まれていることを確認します。このコマンドは、OpenShift Dev Spaces CA バンドル証明書を PEM 形式で返します。

    oc get configmap che-trusted-ca-certs \
        --namespace=<workspace_namespace> \
        --output='jsonpath={.data.tls-ca-bundle\.pem}'
    Copy to Clipboard Toggle word wrap
  5. ワークスペース Pod が ca-certs-merged ConfigMap をマウントすることを確認します。

    oc get pod \
        --namespace=<workspace_namespace> \
        --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \
        --output='jsonpath={.items[0:].spec.volumes[0:].configMap.name}' \
        | grep ca-certs-merged
    Copy to Clipboard Toggle word wrap
  6. ワークスペース Pod 名 <workspace_pod_name> を取得します。

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

    oc exec <workspace_pod_name> \
        --namespace=<workspace_namespace> \
        -- cat /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
    Copy to Clipboard Toggle word wrap

4.8.4. ラベルとアノテーションの追加

4.8.4.1. ルーターのシャード化と連携するように OpenShift ルートを設定

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

前提条件

手順

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

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    Copy to Clipboard Toggle word wrap
    1
    ターゲット Ingress Controller が一連のルートをフィルター処理してサービスを提供するために使用する、ラベルの構造化されていないキー値マップ。
    2
    ターゲット Ingress Controller が提供する DNS 名。
    3
    リソースと共に格納される構造化されていないキー値マップ。

4.8.5. ワークスペースエンドポイントのベースドメインの設定

ワークスペースエンドポイントのベースドメインを設定する方法を説明します。デフォルトでは、ベースドメインは OpenShift Dev Spaces Operator により自動的に検出されます。これを変更するには、CheCluster カスタムリソースで CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX プロパティーを設定する必要があります。

spec:
  components:
    cheServer:
      extraProperties:
        CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX: "<...>" 
1
Copy to Clipboard Toggle word wrap
1
ワークスペースエンドポイントのベースドメイン (例: my-devspaces.example.com)。

手順

  1. ワークスペースエンドポイントのベースドメインを設定します。

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"extraProperties":
                    {"CHE_INFRA_OPENSHIFT_ROUTE_HOST_DOMAIN__SUFFIX": "my-devspaces.example.com"}}}}}'
    Copy to Clipboard Toggle word wrap

4.8.6. プロキシーの設定

Red Hat OpenShift Dev Spaces のプロキシーを設定する方法を説明します。この手順では、プロキシー認証情報用の Kubernetes シークレットを作成し、必要なプロキシー設定を CheCluster カスタムリソースで設定します。プロキシー設定は、環境変数を通じてオペランドとワークスペースに伝播されます。

OpenShift クラスターでは、プロキシー設定を指定する必要はありません。OpenShift Dev Spaces Operator により、OpenShift クラスター全体のプロキシー設定が自動的に使用されます。ただし、このプロキシー設定は、CheCluster カスタムリソースでプロキシー設定を指定することでオーバーライドできます。

手順

  1. (オプション) プロキシーサーバーのユーザー名とパスワードを含むシークレットを openshift-devspaces namespace に作成します。シークレットには app.kubernetes.io/part-of=che.eclipse.org ラベルが必要です。プロキシーサーバーが認証を要求しない場合は、このステップをスキップします。

    oc apply -f - <<EOF
    kind: Secret
    apiVersion: v1
    metadata:
      name: devspaces-proxy-credentials
      namespace: openshift-devspaces
      labels:
        app.kubernetes.io/part-of: che.eclipse.org
    type: Opaque
    stringData:
      user: <user>          
    1
    
      password: <password>  
    2
    
    EOF
    Copy to Clipboard Toggle word wrap
    1
    プロキシーサーバーのユーザー名。
    2
    プロキシーサーバーのパスワード。
  2. CheCluster カスタムリソースで次のプロパティーを設定して、プロキシーを設定するか、OpenShift クラスターのクラスター全体のプロキシー設定をオーバーライドします。

    oc patch checluster/devspaces \
        --namespace openshift-devspaces \
        --type='merge' -p \
    '{"spec":
        {"components":
            {"cheServer":
                {"proxy":
                    {"credentialsSecretName" : "<secretName>",                      
    1
    
                     "nonProxyHosts"         : ["<host_1>"],                        
    2
    
                     "port"                  : "<port>",                            
    3
    
                     "url"                   : "<protocol>://<domain>"}}}}}'    
    4
    Copy to Clipboard Toggle word wrap
    1
    前のステップで作成した認証情報シークレットの名前。
    2
    プロキシーを使用せずに直接アクセスできるホストのリスト。ワイルドカードドメインを指定するには、.<DOMAIN> という形式を使用します。OpenShift Dev Spaces Operator により、.svc および Kubernetes サービスのホストが、非プロキシーホストのリストに自動的に追加されます。OpenShift では、OpenShift Dev Spaces Operator がクラスター全体のプロキシー設定の非プロキシーホストリストをカスタムリソースと組み合わせます。
    重要

    プロキシー設定によっては、localhost127.0.0.1 に変換されないことがあります。その場合、localhost127.0.0.1 の両方を指定する必要があります。

    プロキシーサーバーのポート。
    プロキシーサーバーのプロトコルとドメイン。

検証手順

  1. ワークスペースを起動します。
  2. ワークスペース Pod に HTTP_PROXYHTTPS_PROXYhttp_proxy、および https_proxy 環境変数が含まれており、それぞれに <protocol>://<user>:<password@<domain>:<port> が設定されていることを確認します。
  3. ワークスペース Pod に NO_PROXY および no_proxy 環境変数が含まれており、それぞれに非プロキシーホストのコンマ区切りリストが設定されていることを確認します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat