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.43
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
オプション: ネットワークポリシーによるマルチテナント分離の設定 を適用した場合は、
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.44
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
例4.45
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
- 「プロジェクトの設定」
- ネットワーク分離
- ネットワークポリシーを使用したマルチテナント分離の設定
4.8.2. Dev Spaces ホスト名の設定
この手順では、カスタムホスト名を使用するように OpenShift Dev Space を設定する方法を説明します。
前提条件
-
宛先 OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。CLI の使用方法 を参照してください。 - 証明書とプライベートキーファイルが生成されます。
秘密鍵と証明書のペアを生成するには、他の OpenShift Dev Spaces ホストと同じ認証局 (CA) を使用する必要があります。
DNS プロバイダーに対し、カスタムホスト名をクラスター Ingress を参照するよう要求します。
手順
OpenShift Dev Spaces のプロジェクトを作成します。
$ oc create project openshift-devspaces
TLS Secret を作成します。
$ oc create secret TLS <tls_secret_name> \ 1 --key <key_file> \ 2 --cert <cert_file> \ 3 -n openshift-devspaces
シークレットに必要なラベルを追加します。
$ oc label secret <tls_secret_name> \ 1 app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
- 1
- TLS Secret 名
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: networking: hostname: <hostname> 1 tlsSecretName: <secret> 2
- 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 には、それぞれ任意の数の証明書と、任意の数の鍵を指定できます。Operator は、すべての ConfigMaps を ca-certs-merged
という単一の ConfigMaps にマージし、これを OpenShift Dev Spaces サーバー、ダッシュボード、およびワークスペース Pod にボリュームとしてマウントします。デフォルトでは、Operator は ca-certs-merged
ConfigMap を 2 つのロケーション (/public-certs
と /etc/pki/ca-trust/extracted/pem
) でユーザーのワークスペースにマウントします。/etc/pki/ca-trust/extracted/pem
ディレクトリーは、システムが、Red Hat で信頼できる認証局 (CentOS、Fedora など) に展開した CA 証明書を保存する場所です。CLI ツールは、ユーザーのワークスペースを起動して実行すると、システムで信頼される場所からの証明書を自動的に使用します。
OpenShift クラスターにクラスター全体の信頼できる CA 証明書が クラスター全体のプロキシー設定 を通じて追加されている場合、OpenShift Dev Spaces Operator はそれらを検出し、config.openshift.io/inject-trusted-cabundle="true"
ラベルを付けた ConfigMap に自動的に注入します。このアノテーションに基づいて、OpenShift は ConfigMap の ca-bundle.crt
キー内にクラスター全体で信頼される CA 証明書を自動的に注入します。
前提条件
手順
インポートするすべての CA チェーン PEM ファイルを
custom-ca-certificates.pem
ファイルに連結し、Java トラストストアと互換性のない戻り文字を削除します。$ cat ca-cert-for-devspaces-*.pem | tr -d '\r' > custom-ca-certificates.pem
必要な TLS 証明書を使用して
custom-ca-certificates
ConfigMap を作成します。$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
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
- 以前にデプロイされていない場合は、OpenShift Dev Spaces をデプロイします。それ以外の場合は、OpenShift Dev Spaces コンポーネントのロールアウトが完了するまで待ちます。
- 変更を有効にするには、実行中のワークスペースを再起動します。
検証手順
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
OpenShift Dev Spaces サーバーログで、インポートされた証明書の数が null でないことを確認します。
$ oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep tls-ca-bundle.pem
- ワークスペースを開始し、これが作成されたプロジェクト名 <workspace_namespace> を取得して、ワークスペースが開始されるのを待ちます。
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}'
ワークスペース 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
ワークスペース Pod 名 <workspace_pod_name> を取得します。
$ oc get pod \ --namespace=<workspace_namespace> \ --selector='controller.devfile.io/devworkspace_name=<workspace_name>' \ --output='jsonpath={.items[0:].metadata.name}' \
ワークスペースコンテナーにカスタム CA 証明書があることを確認します。このコマンドは、OpenShift Dev Spaces CA バンドル証明書を PEM 形式で返します。
$ oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/tls-ca-bundle.pem
関連情報
4.8.4. ラベルとアノテーションの追加
4.8.4.1. ルーターのシャード化と連携するように OpenShift ルートを設定
OpenShift Route が ルーターのシャード化 と連携するようにラベル、アノテーション、およびドメインを設定できます。
前提条件
-
OpenShift クラスターへの管理権限を持つアクティブな
oc
セッション。OpenShift CLI のスタートガイド を参照してください。 -
dsc
。「dsc 管理ツールのインストール」 を参照してください。
手順
CheCluster
カスタムリソースを設定します。「CLI を使用して CheCluster カスタムリソースの設定」 を参照してください。spec: networking: labels: <labels> 1 domain: <domain> 2 annotations: <annotations> 3