3.8. 네트워킹 구성
3.8.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.42.
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
OPTIONAL: 네트워크 정책으로 다중 테넌트 격리 구성을 적용한 경우
allow-from-openshift-apiserver
및allow-from-workspaces-namespaces
NetworkPolicies를openshift-devspaces
에도 적용해야 합니다.allow-from-openshift-apiserver
NetworkPolicy를 사용하면openshift-apiserver
네임스페이스에서devworkspace-webhook-server
로 들어오는 트래픽을 사용할 수 있습니다.allow-from-workspaces-namespaces
NetworkPolicy는 각 사용자 프로젝트에서che-gateway
Pod로 들어오는 트래픽을 허용합니다.예 3.43.
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
예 3.44.
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
- 3.2절. “프로젝트 구성”
- 네트워크 격리
- 네트워크 정책으로 다중 테넌트 격리 구성
3.8.2. Dev Spaces 호스트 이름 구성
다음 절차에서는 사용자 지정 호스트 이름을 사용하도록 OpenShift Dev Space를 구성하는 방법을 설명합니다.
사전 요구 사항
-
대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. CLI 시작하기를 참조하십시오. - 인증서 및 개인 키 파일이 생성됩니다.
개인 키 및 인증서 쌍을 생성하려면 다른 OpenShift Dev Spaces 호스트에 대해 동일한 CA(인증 기관)를 사용해야 합니다.
DNS 공급자에게 클러스터 인그레스에 대한 사용자 지정 호스트 이름을 가리키도록 요청합니다.
프로세스
OpenShift Dev Spaces용 프로젝트를 사전 생성합니다.
$ oc create project openshift-devspaces
TLS 시크릿을 생성합니다.
$ 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 시크릿 이름
CheCluster
사용자 정의 리소스를 구성합니다. 3.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: networking: hostname: <hostname> 1 tlsSecretName: <secret> 2
- OpenShift Dev Spaces가 이미 배포된 경우 모든 OpenShift Dev Spaces 구성 요소의 롤아웃이 완료될 때까지 기다립니다.
3.8.3. 신뢰할 수 없는 TLS 인증서 가져오기를 Dev Spaces
외부 서비스와의 OpenShift Dev Spaces 구성 요소 통신은 TLS로 암호화됩니다. 신뢰할 수 있는 CA(인증 기관)에서 서명한 TLS 인증서가 필요합니다. 따라서 다음과 같은 외부 서비스에서 사용하는 신뢰할 수 없는 모든 CA 체인으로 OpenShift Dev Space로 가져와야 합니다.
- 프록시
- ID 공급자(OIDC)
- 소스 코드 리포지토리 공급자(Git)
OpenShift Dev Spaces는 OpenShift Dev Spaces 프로젝트에서 레이블이 지정된 구성 맵을 TLS 인증서의 소스로 사용합니다. 구성 맵에는 각각 임의의 양의 인증서가 있는 임의의 양의 키가 있을 수 있습니다.
OpenShift 클러스터에 클러스터 전체 프록시 구성을 통해 추가된 클러스터 전체의 신뢰할 수 있는 CA 인증서가 포함된 경우 OpenShift Dev Spaces Operator는 해당 인증서를 탐지하고 config.openshift.io/inject-trusted-cabundle="true"
라벨을 사용하여 구성 맵에 자동으로 삽입합니다. 이 주석을 기반으로 OpenShift는 구성 맵의 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
구성 맵을 생성합니다.$ oc create configmap custom-ca-certificates \ --from-file=custom-ca-certificates.pem \ --namespace=openshift-devspaces
custom-ca-certificates
구성 맵에 레이블을 지정합니다.$ 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 구성 요소 롤아웃이 완료될 때까지 기다립니다.
- 변경 사항을 적용하려면 실행 중인 작업 공간을 다시 시작합니다.
검증 단계
구성 맵에 사용자 정의 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 Pod에
ca-certs-merged
구성 맵을 마운트하는 볼륨이 포함되어 있는지 확인합니다.$ 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
OpenShift Dev Spaces 서버 컨테이너에 사용자 정의 CA 인증서가 있는지 확인합니다. 이 명령은 사용자 정의 CA 인증서를 PEM 형식으로 반환합니다.
$ oc exec -t deploy/devspaces \ --namespace=openshift-devspaces \ -- cat /public-certs/custom-ca-certificates.pem
OpenShift Dev Spaces 서버 로그에서 가져온 인증서 수가 null이 아닌지 확인합니다.
$ oc logs deploy/devspaces --namespace=openshift-devspaces \ | grep custom-ca-certificates.pem
인증서의 SHA256 지문을 나열합니다.
$ for certificate in ca-cert*.pem ; do openssl x509 -in $certificate -digest -sha256 -fingerprint -noout | cut -d= -f2; done
OpenShift Dev Spaces 서버 Java truststore에 동일한 지문이 있는 인증서가 포함되어 있는지 확인합니다.
$ oc exec -t deploy/devspaces --namespace=openshift-devspaces -- \ keytool -list -keystore /home/user/cacerts \ | grep --after-context=1 custom-ca-certificates.pem
- 작업 공간을 시작하고, 생성된 프로젝트 이름(< workspace_namespace >)을 가져오고, 작업 공간이 시작될 때까지 기다립니다.
che-trusted-ca-certs
구성 맵에 사용자 정의 CA 인증서가 포함되어 있는지 확인합니다. 이 명령은 사용자 정의 CA 인증서를 PEM 형식으로 반환합니다.$ oc get configmap che-trusted-ca-certs \ --namespace=<workspace_namespace> \ --output='jsonpath={.data.custom-ca-certificates\.custom-ca-certificates\.pem}'
작업 공간 Pod가
che-trusted-ca-certs
구성 맵을 마운트하는지 확인합니다.$ 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
Universal-developer-image
컨테이너(또는 Workspace 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'
작업 공간 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 인증서가 있는지 확인합니다. 이 명령은 사용자 정의 CA 인증서를 PEM 형식으로 반환합니다.
$ oc exec <workspace_pod_name> \ --namespace=<workspace_namespace> \ -- cat /public-certs/custom-ca-certificates.custom-ca-certificates.pem
추가 리소스
3.8.4. 레이블 및 주석 추가
3.8.4.1. 라우터 공유에서 작동하도록 OpenShift 경로 구성
OpenShift 경로의 레이블, 주석 및 도메인이 라우터 분할에서 작동하도록 구성할 수 있습니다.
사전 요구 사항
-
OpenShift 클러스터에 대한 관리 권한이 있는 활성
oc
세션. OpenShift CLI 시작하기를 참조하십시오. -
DSC
. 1.2절. “dsc 관리 툴 설치” 을 참조하십시오.
프로세스
CheCluster
사용자 정의 리소스를 구성합니다. 3.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.spec: networking: labels: <labels> 1 domain: <domain> 2 annotations: <annotations> 3