5.8. 네트워킹 구성


5.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로 들어오는 트래픽을 허용합니다.

    예 5.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 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 프로젝트의 모든 포드를 선택합니다.
  • OPTIONAL: 네트워크 정책으로 다중 테넌트 격리 구성을 적용한 경우 allow-from-openshift-apiserverallow-from-workspaces-namespaces NetworkPolicies를 openshift-devspaces 에도 적용해야 합니다. allow-from-openshift-apiserver NetworkPolicy를 사용하면 openshift-apiserver 네임스페이스에서 devworkspace-webhook-server 로 들어오는 트래픽을 사용할 수 있습니다. allow-from-workspaces-namespaces NetworkPolicy는 각 사용자 프로젝트에서 che-gateway Pod로 들어오는 트래픽을 허용합니다.

    예 5.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 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 devworkspace-webhook-server Pod만 선택합니다.

    예 5.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 네임스페이스입니다. 기본값은 openshift-devspaces 입니다.
    2
    podSelector 는 OpenShift Dev Spaces 네임스페이스에서 모든 포드를 선택합니다.
  • 5.2절. “프로젝트 구성”
  • 네트워크 격리
  • 네트워크 정책으로 다중 테넌트 격리 구성

5.8.2. Dev Spaces 호스트 이름 구성

다음 절차에서는 사용자 지정 호스트 이름을 사용하도록 OpenShift Dev Space를 구성하는 방법을 설명합니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • 인증서 및 개인 키 파일이 생성됩니다.
중요

개인 키 및 인증서 쌍을 생성하려면 다른 OpenShift Dev Spaces 호스트에 대해 동일한 CA(인증 기관)를 사용해야 합니다.

중요

DNS 공급자에게 클러스터 인그레스에 대한 사용자 지정 호스트 이름을 가리키도록 요청합니다.

프로세스

  1. OpenShift Dev Spaces용 프로젝트를 사전 생성합니다.

    $ oc create project openshift-devspaces
    Copy to Clipboard Toggle word wrap
  2. TLS 시크릿을 생성합니다.

    $ 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 시크릿 이름
    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 시크릿 이름
  4. CheCluster 사용자 정의 리소스를 구성합니다. 5.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        hostname: <hostname>     
    1
    
        tlsSecretName: <secret>  
    2
    Copy to Clipboard Toggle word wrap
    1
    사용자 지정 Red Hat OpenShift Dev Spaces 서버 호스트 이름
    2
    TLS 시크릿 이름
  5. OpenShift Dev Spaces가 이미 배포된 경우 모든 OpenShift Dev Spaces 구성 요소의 롤아웃이 완료될 때까지 기다립니다.

5.8.3. 신뢰할 수 없는 TLS 인증서 가져오기를 Dev Spaces

외부 서비스와의 OpenShift Dev Spaces 구성 요소 통신은 TLS로 암호화됩니다. 신뢰할 수 있는 CA(인증 기관)에서 서명한 TLS 인증서가 필요합니다. 따라서 다음과 같은 외부 서비스에서 사용하는 신뢰할 수 없는 모든 CA 체인으로 OpenShift Dev Space로 가져와야 합니다.

  • 프록시
  • ID 공급자(OIDC)
  • 소스 코드 리포지토리 공급자(Git)

OpenShift Dev Spaces는 OpenShift Dev Spaces 프로젝트에서 레이블이 지정된 ConfigMap을 TLS 인증서의 소스로 사용합니다. ConfigMaps에는 각각 임의의 양의 인증서가 있는 임의의 양의 키가 있을 수 있습니다. 모든 인증서는 다음과 같이 마운트됩니다.

  • /public-certs location of OpenShift Dev Spaces 서버 및 대시보드 Pod
  • 작업 공간 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는 RHCOS(Red Hat Enterprise Linux CoreOS) 신뢰 번들을 마운트된 인증서에 자동으로 추가합니다.

사전 요구 사항

  • 대상 OpenShift 클러스터에 대한 관리 권한이 있는 활성 oc 세션. CLI 시작하기를 참조하십시오.
  • openshift-devspaces 프로젝트가 있습니다.
  • 가져올 각 CA 체인의 경우: PEM 형식의 루트 CA 및 중간 인증서의 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

5.8.4. 레이블 및 주석 추가

5.8.4.1. 라우터 공유에서 작동하도록 OpenShift 경로 구성

OpenShift 경로의 레이블, 주석 및 도메인이 라우터 분할에서 작동하도록 구성할 수 있습니다.

사전 요구 사항

프로세스

  • CheCluster 사용자 정의 리소스를 구성합니다. 5.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        labels: <labels> 
    1
    
        domain: <domain> 
    2
    
        annotations: <annotations> 
    3
    Copy to Clipboard Toggle word wrap
    1
    대상 Ingress 컨트롤러에서 서비스 경로 세트를 필터링하는 데 사용하는 레이블의 구조화되지 않은 키 값 맵입니다.
    2
    대상 Ingress 컨트롤러에서 서비스를 제공하는 DNS 이름입니다.
    3
    리소스와 함께 저장된 구조화되지 않은 키 값 맵입니다.

5.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

5.8.6. 프록시 구성

Red Hat OpenShift Dev Spaces에 대한 프록시를 구성하는 방법을 알아보십시오. 이 단계에는 프록시 자격 증명에 대한 Kubernetes 시크릿 생성 및 CheCluster 사용자 정의 리소스에서 필요한 프록시 설정을 구성하는 작업이 포함됩니다. 프록시 설정은 환경 변수를 통해 피연산자 및 작업 공간으로 전파됩니다.

OpenShift 클러스터에서는 프록시 설정을 구성할 필요가 없습니다. OpenShift Dev Spaces Operator는 OpenShift 클러스터 전체 프록시 구성을 자동으로 사용합니다. 그러나 CheCluster 사용자 정의 리소스에서 프록시 설정을 재정의할 수 있습니다.

프로세스

  1. (선택 사항) 프록시 서버의 사용자 및 암호가 포함된 openshift-devspaces 네임스페이스에 보안을 생성합니다. 시크릿에는 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&gt;을 사용하여 와일드카드 도메인을 지정합니다. OpenShift Dev Spaces Operator는 프록시가 아닌 호스트 목록에 .svc 및 Kubernetes 서비스 호스트를 자동으로 추가합니다. OpenShift에서 OpenShift Dev Spaces Operator는 클러스터 전체 프록시 구성의 비 프록시 호스트 목록과 사용자 정의 리소스를 결합합니다.
    중요

    일부 프록시 구성에서 localhost127.0.0.1 로 변환되지 않을 수 있습니다. 이 경우 localhost127.0.0.1 을 모두 지정해야 합니다.

    프록시 서버의 포트입니다.
    프록시 서버의 프로토콜 및 도메인입니다.

검증 단계

  1. 작업 공간 시작
  2. 작업 공간 Pod에 HTTP_PROXY,HTTPS_PROXY,http_proxyhttps_proxy 환경 변수가 포함되어 있으며 각각 < protocol > ://<user>:<password@<domain>:<port >로 설정되어 있는지 확인합니다.
  3. 작업 공간 포드에 NO_PROXYno_proxy 환경 변수가 포함되어 있으며 각각 프록시가 아닌 호스트의 쉼표로 구분된 목록으로 설정되어 있는지 확인합니다.
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat