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

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

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

3.8.2. Dev Spaces 호스트 이름 구성

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

사전 요구 사항

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

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

중요

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

프로세스

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

    $ oc create project openshift-devspaces
  2. TLS 시크릿을 생성합니다.

    $ oc create secret TLS <tls_secret_name> \ 1
    --key <key_file> \ 2
    --cert <cert_file> \ 3
    -n openshift-devspaces
    1
    TLS 시크릿 이름
    2
    개인 키가 있는 파일
    3
    인증서가 있는 파일
  3. 보안에 필요한 레이블을 추가합니다.

    $ oc label secret <tls_secret_name> \ 1
    app.kubernetes.io/part-of=che.eclipse.org -n openshift-devspaces
    1
    TLS 시크릿 이름
  4. CheCluster 사용자 정의 리소스를 구성합니다. 3.1.2절. “CLI를 사용하여 CheCluster 사용자 정의 리소스 구성”을 참조하십시오.

    spec:
      networking:
        hostname: <hostname>     1
        tlsSecretName: <secret>  2
    1
    사용자 지정 Red Hat OpenShift Dev Spaces 서버 호스트 이름
    2
    TLS 시크릿 이름
  5. 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 인증서를 자동으로 삽입합니다.

사전 요구 사항

  • 대상 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
  2. 필요한 TLS 인증서를 사용하여 custom-ca-certificates 구성 맵을 생성합니다.

    $ oc create configmap custom-ca-certificates \
        --from-file=custom-ca-certificates.pem \
        --namespace=openshift-devspaces
  3. 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
  4. 이전에 배포되지 않은 경우 OpenShift Dev Spaces를 배포합니다. 그렇지 않으면 OpenShift Dev Spaces 구성 요소 롤아웃이 완료될 때까지 기다립니다.
  5. 변경 사항을 적용하려면 실행 중인 작업 공간을 다시 시작합니다.

검증 단계

  1. 구성 맵에 사용자 정의 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 구성 맵을 마운트하는 볼륨이 포함되어 있는지 확인합니다.

    $ 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 truststore에 동일한 지문이 있는 인증서가 포함되어 있는지 확인합니다.

    $ 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 구성 맵에 사용자 정의 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 구성 맵을 마운트하는지 확인합니다.

    $ 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 컨테이너(또는 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'
  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.8.4. 레이블 및 주석 추가

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

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

사전 요구 사항

프로세스

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

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

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.