사전 요구 사항

• PEM 인코딩 파일에 인증서/키 쌍이 있어야 합니다. 이때 인증서는 신뢰할 수 있는 인증 기관 또는 사용자 정의 PKI에서 구성한 신뢰할 수 있는 개인 인증 기관의 서명을 받은 인증서입니다.

• 인증서가 다음 요구 사항을 충족합니다.

  • 인증서가 Ingress 도메인에 유효해야 합니다.
  • 인증서는 subjectAltName 확장자를 사용하여 *.apps.ocp4.example.com과 같은 와일드카드 도메인을 지정합니다.

• IngressController CR이 있어야 합니다. 기본 설정을 사용할 수 있어야 합니다.

  $ oc --namespace openshift-ingress-operator get ingresscontrollers

  출력 예

  NAME      AGE
  default   10m

사전 요구 사항

• cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
• OpenShift CLI(oc)가 설치되어 있습니다.
• 이전에는 Ingress 컨트롤러에 대한 사용자 정의 기본 인증서를 구성했습니다.

절차

• 사용자 정의 인증서를 제거하고 AWS에서 Red Hat OpenShift Service와 함께 제공되는 인증서를 복원하려면 다음 명령을 입력합니다.

  $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
    --type json -p $'- op: remove\n  path: /spec/defaultCertificate'

  클러스터가 새 인증서 구성을 조정하는 동안 지연이 발생할 수 있습니다.

검증

• 원래 클러스터 인증서가 복원되었는지 확인하려면 다음 명령을 입력합니다.

  $ echo Q | \
    openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
    openssl x509 -noout -subject -issuer -enddate

  다음과 같습니다.

  <domain>

  클러스터의 기본 도메인 이름을 지정합니다.

  출력 예

  subject=CN = *.apps.<domain>
  issuer=CN = ingress-operator@1620633373
  notAfter=May 10 10:44:36 2023 GMT

검증

• 다음 명령을 실행하여 기본 Ingress 컨트롤러가 kube-state-metrics 쿼리에서 반환된 값과 일치하도록 확장되었는지 확인합니다.

  • grep 명령을 사용하여 Ingress 컨트롤러 YAML 파일에서 복제본을 검색합니다.

    $ oc get ingresscontroller/default -o yaml | grep replicas:

    출력 예

    replicas: 3

  • openshift-ingress 프로젝트에서 Pod를 가져옵니다.

    $ oc get pods -n openshift-ingress

    출력 예

    NAME                             READY   STATUS    RESTARTS   AGE
    router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
    router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
    router-default-7b5df44ff-wwsth   2/2     Running   0          66s

사전 요구 사항

• cluster-admin 권한이 있는 사용자로 로그인합니다.

• 수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. 사이드카 컨테이너에 로깅을 지정하려면 Container spec.logging.access.destination.type을 지정해야 합니다. 다음 예제는 Container 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Container

• 사이드카에 로그를 기록하도록 Ingress 컨트롤러를 구성하면 Operator는 Ingress 컨트롤러 Pod에 logs 라는 컨테이너를 만듭니다.

  $ oc -n openshift-ingress logs deployment.apps/router-default -c logs

  출력 예

  2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

• 수신 액세스 로깅을 구성하려면 spec.logging.access.destination을 사용하여 대상을 지정해야 합니다. Syslog 끝점 대상에 로깅을 지정하려면 spec.logging.access.destination.type에 대한 Syslog를 지정해야 합니다. 대상 유형이 Syslog인 경우, spec.logging.access.destination.syslog.endpoint를 사용하여 대상 끝점을 지정해야 하며 spec.logging.access.destination.syslog.facility를 사용하여 장치를 지정할 수 있습니다. 다음 예제는 Syslog 대상에 로그를 기록하는 Ingress 컨트롤러 정의입니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            port: 10514

  참고

  syslog 대상 포트는 UDP여야 합니다.

• spec.logging.access.httpLogFormat을 지정하여 로그 형식을 사용자 정의할 수 있습니다. 다음 예제는 IP 주소 1.2.3.4 및 포트 10514를 사용하여 syslog 끝점에 로그하는 Ingress 컨트롤러 정의입니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            port: 10514
        httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

• Ingress 액세스 로깅을 비활성화하려면 spec.logging 또는 spec.logging.access를 비워 둡니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access: null

• spec.logging.access.destination.destination. type: Syslog를 사용하는 경우 spec.logging.access.destination. maxLength 를 사용합니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            maxLength: 4096
            port: 10514

• spec.logging.access.destination.destination. type: Container를 사용하는 경우 spec.logging.access.destination. maxLength 를 사용합니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Container
          container:
            maxLength: 8192

사전 요구 사항

• 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

절차

• 스레드 수를 늘리도록 Ingress 컨트롤러를 업데이트합니다.

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'

  참고

  많은 리소스를 실행할 수 있는 노드가 있는 경우 원하는 노드의 용량과 일치하는 라벨을 사용하여 spec.nodePlacement.nodeSelector를 구성하고 spec.tuningOptions.threadCount를 적절하게 높은 값으로 구성할 수 있습니다.

• 클라우드 공급자 로드 밸런서를 사용하거나 내부적으로 OpenShift Ingress 컨트롤러 로드 밸런서를 사용하여 외부에서 부하를 분산할 수 있습니다.
• 그래픽에 표시된 클러스터에 표시된 대로 로드 밸런서의 단일 IP 주소와 8080 및 4200과 같은 더 친숙한 포트를 사용할 수 있습니다.
• 외부 로드 밸런서의 트래픽은 Pod에서 전달되고 다운 노드의 인스턴스에 표시된 대로 로드 밸런서에 의해 관리됩니다. 구현 세부 사항은 Kubernetes 서비스 설명서를 참조하십시오.

사전 요구 사항

• OpenShift CLI(oc)를 설치합니다.
• cluster-admin 권한이 있는 사용자로 로그인합니다.

사전 요구 사항

• 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

절차

• 백엔드 상태 점검 간 간격을 변경하도록 Ingress 컨트롤러를 업데이트합니다.

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'

  참고

  단일 경로의 healthCheckInterval 을 재정의하려면 경로 주석 router.openshift.io/haproxy.health.check.interval을 사용합니다.

사전 요구 사항

• OpenShift CLI(oc)를 설치합니다.
• cluster-admin 권한이 있는 사용자로 로그인합니다.

사전 요구 사항

• 클러스터 관리자 권한이 있어야 합니다.

절차

• 다음 명령을 사용하여 ingresscontroller 리소스 변수의 .spec.routeAdmission 필드를 편집합니다.

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

  샘플 Ingress 컨트롤러 구성

  spec:
    routeAdmission:
      namespaceOwnership: InterNamespaceAllowed
  ...

  작은 정보

  다음 YAML을 적용하여 경로 승인 정책을 구성할 수 있습니다.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    routeAdmission:
      namespaceOwnership: InterNamespaceAllowed

사전 요구 사항

• OpenShift CLI(oc)가 설치되어 있습니다.
• cluster-admin 역할의 사용자로 AWS 클러스터의 Red Hat OpenShift Service에 액세스할 수 있습니다.

• Ingress 컨트롤러로 전달하기 전에 X-Forwarded-For 헤더를 각 요청에 삽입하는 외부 프록시를 구성합니다.

  헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 never 정책을 지정합니다. 그러면 Ingress 컨트롤러에서 헤더를 설정하지 않으며 애플리케이션은 외부 프록시에서 제공하는 헤더만 수신합니다.

• 외부 프록시에서 외부 클러스터 요청에 설정한 X-Forwarded-For 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성합니다.

  외부 프록시를 통과하지 않는 내부 클러스터 요청에 X-Forwarded-For 헤더를 설정하도록 Ingress 컨트롤러를 구성하려면 if-none 정책을 지정합니다. HTTP 요청에 이미 외부 프록시를 통해 설정된 헤더가 있는 경우 Ingress 컨트롤러에서 해당 헤더를 보존합니다. 요청이 프록시를 통해 제공되지 않아 헤더가 없는 경우에는 Ingress 컨트롤러에서 헤더를 추가합니다.

• X-Forwarded-For 헤더를 삽입하는 애플리케이션별 외부 프록시를 구성합니다.

  다른 경로에 대한 정책에 영향을 주지 않으면서 애플리케이션 경로에 대한 헤더를 수정하지 않은 상태로 전달하도록 Ingress 컨트롤러를 구성하려면 애플리케이션 경로에 주석 haproxy.router.openshift.io/set-forwarded-headers: if-none 또는 haproxy.router.openshift.io/set-forwarded-headers: never를 추가하십시오.

  참고

  Ingress 컨트롤러에 전역적으로 설정된 값과 관계없이 경로별로 haproxy.router.openshift.io/set-forwarded-headers 주석을 설정할 수 있습니다.

• Ingress 컨트롤러에서 HTTP/2를 사용하려면 다음과 같이 oc annotate 명령을 입력합니다.

  $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

  <ingresscontroller_name>을 주석 처리할 Ingress 컨트롤러의 이름으로 변경합니다.

• 전체 클러스터에 HTTP/2를 사용하려면 oc annotate 명령을 입력합니다.

  $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

  작은 정보

  다음 YAML을 적용하여 주석을 추가할 수도 있습니다.

  apiVersion: config.openshift.io/v1
  kind: Ingress
  metadata:
    name: cluster
    annotations:
      ingress.operator.openshift.io/default-enable-http2: "true"

사전 요구 사항

• Ingress 컨트롤러가 생성되어 있습니다.

사전 요구 사항

• AWS 클러스터에 Red Hat OpenShift Service를 배포했습니다.
• oc 명령줄 인터페이스를 설치했습니다.

사전 요구 사항

• OpenShift CLI(oc)가 설치되어 있습니다.
• cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

• oc patch 명령을 입력하여 대문자로 작성할 HTTP 헤더를 지정합니다.

  1. oc patch 명령을 입력하여 HTTP host 헤더를 Host로 변경합니다.

     $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

  2. 애플리케이션 경로에 주석을 추가합니다.

     $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true

     그런 다음 Ingress 컨트롤러는 지정된 대로 host 요청 헤더를 조정합니다.

• Ingress 컨트롤러 YAML 파일을 구성하여 HeaderNameCaseAdjustments 필드를 사용하여 조정합니다.

  1. 다음 예제 Ingress 컨트롤러 YAML은 적절하게 주석이 달린 경로의 HTTP/1 요청에 대해 host 헤더를 Host로 조정합니다.

     Ingress 컨트롤러 YAML 예시

     apiVersion: operator.openshift.io/v1
     kind: IngressController
     metadata:
       name: default
       namespace: openshift-ingress-operator
     spec:
       httpHeaders:
         headerNameCaseAdjustments:
         - Host

  2. 다음 예제 경로에서는 haproxy.router.openshift.io/h1-adjust-case 주석을 사용하여 HTTP 응답 헤더 이름 대소문자 조정을 활성화합니다.

     경로 YAML의 예

     apiVersion: route.openshift.io/v1
     kind: Route
     metadata:
       annotations:
         haproxy.router.openshift.io/h1-adjust-case: true 1
       name: my-application
       namespace: my-application
     spec:
       to:
         kind: Service
         name: my-application

     1

     haproxy.router.openshift.io/h1-adjust-case를 true로 설정합니다.

사전 요구 사항

• 기본 통계 포트인 1936에 액세스하도록 방화벽을 구성했습니다.

사전 요구 사항

• 다음은 Ingress 컨트롤러를 이미 생성했다고 가정합니다.

프로세스

• HAProxy의 최대 연결 수를 변경하도록 Ingress 컨트롤러를 업데이트합니다.

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'

  주의

  spec.tuningOptions.maxConnections 값을 현재 운영 체제 제한보다 크게 설정하면 HAProxy 프로세스가 시작되지 않습니다. 이 매개변수에 대한 자세한 내용은 "Ingress Controller 구성 매개변수" 섹션의 표를 참조하십시오.

• Pod에서 전송한 멀티 캐스트 패킷은 NetworkPolicy 오브젝트에 관계없이 프로젝트의 다른 모든 Pod로 전달됩니다. Pod는 유니 캐스트를 통해 통신할 수 없는 경우에도 멀티 캐스트를 통해 통신할 수 있습니다.
• 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 프로젝트 간에 통신을 허용하는 NetworkPolicy 오브젝트가 있더라도 다른 프로젝트의 Pod로 전달되지 않습니다.

• Pod에서 전송한 멀티 캐스트 패킷은 프로젝트의 다른 모든 Pod로 전달됩니다.
• 한 프로젝트에서 Pod가 전송한 멀티 캐스트 패킷은 각 프로젝트가 함께 결합되고 각 참여 프로젝트에서 멀티 캐스트가 활성화된 경우에만 다른 프로젝트의 Pod로 전달됩니다.

사전 요구 사항

• OpenShift CLI(oc)를 설치합니다.
• cluster-admin 또는 dedicated-admin 역할이 있는 사용자로 클러스터에 로그인해야 합니다.

절차

• 다음 명령을 실행하여 프로젝트에 대한 멀티 캐스트를 활성화합니다. 멀티 캐스트를 활성화하려는 프로젝트의 네임스페이스로 <namespace>를 바꿉니다.

  $ oc annotate netnamespace <namespace> \
      netnamespace.network.openshift.io/multicast-enabled=true

사전 요구 사항

• 클러스터가 설치되고 있는 VPC에서 프록시에 액세스할 수 있는지 확인했습니다. VPC의 프라이빗 서브넷에서도 프록시에 액세스할 수 있어야 합니다.

절차

• 클러스터를 생성할 때 프록시 구성을 지정합니다.

  $ rosa create cluster \
   <other_arguments_here> \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
   --no-proxy example.com 8

  1 4 6

  additional-trust-bundle-file,http-proxy, https-proxy 인수는 모두 선택 사항입니다.

  2

  http-proxy 또는 https-proxy 인수 없이 additional-trust-bundle-file 인수를 사용하면 신뢰 저장소에 신뢰 번들이 추가되고 클러스터 시스템 송신 트래픽을 확인하는 데 사용됩니다. 이 시나리오에서는 프록시와 함께 사용할 번들이 구성되지 않았습니다.

  3

  additional-trust-bundle-file 인수는 모두 서로 연결된 PEM 인코딩 X.509 인증서 번들을 가리키는 파일 경로입니다. additionalTrustBundle 매개변수는 RHCOS 신뢰 번들의 기관에서 프록시의 ID 인증서를 서명하지 않는 한 필요합니다. 추가 프록시 구성은 필요하지 않아도 추가 CA는 필요한 MITM 투명 프록시 네트워크를 사용한다면 MITM CA 인증서를 제공해야 합니다.

  5 7

  http-proxy 및 https-proxy 인수는 유효한 URL을 가리켜야 합니다.

  8

  프록시를 제외할 대상 도메인 이름, IP 주소 또는 네트워크 CIDR의 쉼표로 구분된 목록입니다.

  하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.com은 x.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. networking.machineNetwork[].cidr 필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.

  httpProxy와 httpsProxy 필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.

사전 요구 사항

• AWS 클러스터에 Red Hat OpenShift Service가 있어야 합니다.
• 클러스터는 VPC에 배포되어 있습니다.

검증

• 네트워킹 페이지의 VPC(Virtual Private Cloud) 섹션에서 클러스터의 프록시 구성이 예상대로 구성되어 있는지 확인합니다.

사전 요구 사항

• 설치 호스트에 최신 ROSA(rosa) 및 OpenShift(oc) CLI를 설치하고 구성했습니다.
• VPC에 배포된 ROSA 클러스터가 있습니다.

절차

• 클러스터 구성을 편집하여 클러스터 전체 프록시 세부 정보를 추가하거나 업데이트합니다.

  $ rosa edit cluster \
   --cluster $CLUSTER_NAME \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
    --no-proxy example.com 8

  1 4 6

  additional-trust-bundle-file,http-proxy, https-proxy 인수는 모두 선택 사항입니다.

  2

  http-proxy 또는 https-proxy 인수 없이 additional-trust-bundle-file 인수를 사용하면 신뢰 저장소에 신뢰 번들이 추가되고 클러스터 시스템 송신 트래픽을 확인하는 데 사용됩니다. 이 시나리오에서는 프록시와 함께 사용할 번들이 구성되지 않았습니다.

  3

  additional-trust-bundle-file 인수는 모두 서로 연결된 PEM 인코딩 X.509 인증서 번들을 가리키는 파일 경로입니다. additionalTrustBundle 매개변수는 RHCOS 신뢰 번들의 기관에서 프록시의 ID 인증서를 서명하지 않는 한 필요합니다. 추가 프록시 구성은 필요하지 않아도 추가 CA는 필요한 MITM 투명 프록시 네트워크를 사용한다면 MITM CA 인증서를 제공해야 합니다.

  참고

  클러스터에서 프록시 또는 추가 신뢰 번들 구성을 직접 변경하지 않아야 합니다. 이러한 변경 사항은 ROSA CLI(rosa) 또는 Red Hat OpenShift Cluster Manager를 사용하여 적용해야 합니다. 클러스터에 직접 변경한 모든 변경 사항은 자동으로 취소됩니다.

  5 7

  http-proxy 및 https-proxy 인수는 유효한 URL을 가리켜야 합니다.

  8

  프록시를 제외할 대상 도메인 이름, IP 주소 또는 네트워크 CIDR의 쉼표로 구분된 목록입니다.

  하위 도메인과 일치하려면 도메인 앞에 .을 입력합니다. 예를 들어, .y.com은 x.y.com과 일치하지만 y.com은 일치하지 않습니다. *를 사용하여 모든 대상에 대해 프록시를 바이패스합니다. networking.machineNetwork[].cidr 필드에 의해 정의된 네트워크에 포함되어 있지 않은 작업자를 설치 구성에서 확장하려면 연결 문제를 방지하기 위해 이 목록에 해당 작업자를 추가해야 합니다.

  httpProxy와 httpsProxy 필드가 모두 설정되지 않은 경우 이 필드는 무시됩니다.

사전 요구 사항

• 클러스터 관리자 권한이 있어야합니다.
• ROSA CLI(rosa)를 설치했습니다.

절차

• 프록시를 수정하려면 rosa edit 명령을 사용합니다. 클러스터에서 프록시를 지우려면 빈 문자열을 --http-proxy 및 --https-proxy 인수에 전달해야 합니다.

  $ rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""

  참고

  프록시 인수 중 하나만 사용할 수 있지만 빈 필드는 무시되므로 --http-proxy 및 --https-proxy 인수 모두에 빈 문자열을 전달해도 문제가 발생하지 않습니다.

  출력 예

  I: Updated cluster <cluster_name>

검증

• rosa describe 명령을 사용하여 클러스터에서 프록시가 제거되었는지 확인할 수 있습니다.

  $ rosa describe cluster -c <cluster_name>

  제거하기 전에 프록시 IP가 프록시 섹션에 표시됩니다.

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  프록시를 제거하면 프록시 섹션이 제거됩니다.

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Additional trust bundle:    REDACTED

사전 요구 사항

• 클러스터 관리자 권한이 있어야합니다.
• ROSA CLI(rosa)를 설치했습니다.
• 클러스터에 인증 기관이 추가되었습니다.

절차

• rosa edit 명령을 사용하여 CA 신뢰 번들을 수정합니다. 클러스터에서 신뢰 번들을 지우려면 빈 문자열을 --additional-trust-bundle-file 인수로 전달해야 합니다.

  $ rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""

  출력 예

  I: Updated cluster <cluster_name>

검증

• rosa describe 명령을 사용하여 신뢰 번들이 클러스터에서 제거되었는지 확인할 수 있습니다.

  $ rosa describe cluster -c <cluster_name>

  제거하기 전에 보안 목적으로 해당 값을 수정하고 추가 신뢰 번들 섹션이 표시됩니다.

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  프록시를 제거하면 추가 신뢰 번들 섹션이 제거됩니다.

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>

• 모든 트래픽 거부:

  기본적으로 프로젝트를 거부하려면 모든 Pod와 일치하지만 트래픽을 허용하지 않는 NetworkPolicy 오브젝트를 추가합니다.

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: deny-by-default
  spec:
    podSelector: {}
    ingress: []

• AWS Ingress 컨트롤러의 Red Hat OpenShift Service의 연결만 허용합니다.

  프로젝트에서 AWS Ingress 컨트롤러의 Red Hat OpenShift Service의 연결만 허용하도록 하려면 다음 NetworkPolicy 오브젝트를 추가합니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress

• 프로젝트 내 Pod 연결만 허용:

  Pod가 동일한 프로젝트 내 다른 Pod의 연결은 수락하지만 다른 프로젝트에 속하는 Pod의 기타 모든 연결을 거부하도록 하려면 다음 NetworkPolicy 오브젝트를 추가합니다.

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}

• Pod 레이블을 기반으로 하는 HTTP 및 HTTPS 트래픽만 허용:

  특정 레이블(다음 예에서 role=frontend)을 사용하여 Pod에 대한 HTTP 및 HTTPS 액세스만 활성화하려면 다음과 유사한 NetworkPolicy 오브젝트를 추가합니다.

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-http-and-https
  spec:
    podSelector:
      matchLabels:
        role: frontend
    ingress:
    - ports:
      - protocol: TCP
        port: 80
      - protocol: TCP
        port: 443

• 네임스페이스와 Pod 선택기를 모두 사용하여 연결 수락:

  네임스페이스와 Pod 선택기를 결합하여 네트워크 트래픽을 일치시키려면 다음과 유사한 NetworkPolicy 오브젝트를 사용하면 됩니다.

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-pod-and-namespace-both
  spec:
    podSelector:
      matchLabels:
        name: test-pods
    ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              project: project_name
          podSelector:
            matchLabels:
              name: test-pods

• 분리해야 하는 포드 그룹을 포함하도록 네임스페이스를 사용하여 OVS 흐름 규칙의 수를 줄입니다.

  namespaceSelector 또는 빈 podSelector를 사용하여 전체 네임스페이스를 선택하는 NetworkPolicy 오브젝트는 네임스페이스의 VXLAN 가상 네트워크 ID(VNID)와 일치하는 단일 OVS 흐름 규칙만 생성합니다.

• 원래 네임스페이스에서 분리할 필요가 없는 포드를 유지하고, 분리해야 하는 포드를 하나 이상의 네임스페이스로 이동합니다.
• 분리된 포드에서 허용하려는 특정 트래픽을 허용하도록 추가 대상의 네임스페이스 간 네트워크 정책을 생성합니다.

• 동일한 spec.podSelector 사양이 있는 네트워크 정책의 경우 수신 또는 송신 규칙의 서브 세트가 있는 여러 네트워크 정책보다 여러 수신 또는 송신 규칙이 있는 하나의 네트워크 정책을 사용하는 것이 더 효율적입니다.

• podSelector 또는 namespaceSelector 사양을 기반으로 하는 모든 수신 또는 송신 규칙은 수신 또는 송신 규칙에서 선택한 네트워크 정책 + Pod 수에 비례하여 OVS 흐름 수를 생성합니다. 따라서 모든 Pod에 대해 개별 규칙을 생성하는 대신 하나의 규칙에서 필요한 만큼의 Pod를 선택할 수 있는 podSelector 또는 namespaceSelector 사양을 사용하는 것이 좋습니다.

  예를 들어 다음 정책에는 두 개의 규칙이 있습니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: test-network-policy
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
    - from:
      - podSelector:
          matchLabels:
            role: backend

  다음 정책은 다음과 같은 두 가지 규칙을 나타냅니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: test-network-policy
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector:
          matchExpressions:
          - {key: role, operator: In, values: [frontend, backend]}

  spec.podSelector 사양에 동일한 지침이 적용됩니다. 다른 네트워크 정책에 대해 동일한 수신 또는 송신 규칙이 있는 경우 공통 spec.podSelector 사양을 사용하여 하나의 네트워크 정책을 생성하는 것이 더 효과적일 수 있습니다. 예를 들어 다음 두 정책에는 다른 규칙이 있습니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy1
  spec:
    podSelector:
      matchLabels:
        role: db
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
  ---
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy2
  spec:
    podSelector:
      matchLabels:
        role: client
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend

  다음 네트워크 정책은 다음과 같은 두 가지 규칙을 나타냅니다.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy3
  spec:
    podSelector:
      matchExpressions:
      - {key: role, operator: In, values: [db, client]}
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend

  이 최적화는 여러 개의 선택기만 하나의 선택기로 표시되는 경우에만 적용할 수 있습니다. 선택기가 다른 레이블을 기반으로 하는 경우 이 최적화를 적용하지 못할 수 있습니다. 이러한 경우 네트워크 정책 최적화에 새로운 레이블을 적용하는 것이 좋습니다.

• 네트워크 정책 생성

사전 요구 사항

• OpenShift Cluster Manager 에 로그인했습니다.
• AWS 클러스터에서 Red Hat OpenShift Service를 생성하셨습니다.
• 클러스터의 ID 공급자를 구성했습니다.
• 구성된 ID 공급자에 사용자 계정을 추가했습니다.
• Red Hat OpenShift Service on AWS 클러스터 내에 프로젝트를 생성하셨습니다.

사전 요구 사항

• OpenShift Cluster Manager 에 로그인했습니다.
• AWS 클러스터에서 Red Hat OpenShift Service를 생성하셨습니다.
• 클러스터의 ID 공급자를 구성했습니다.
• 구성된 ID 공급자에 사용자 계정을 추가했습니다.
• 네트워크 정책을 생성했습니다.

사전 요구 사항

• OpenShift Cluster Manager 에 로그인했습니다.
• AWS 클러스터에서 Red Hat OpenShift Service를 생성하셨습니다.
• 클러스터의 ID 공급자를 구성했습니다.
• 구성된 ID 공급자에 사용자 계정을 추가했습니다.

사전 요구 사항

• 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인 또는 OpenShift SDN 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다. 이 모드는 OpenShift SDN의 기본값입니다. 이 모드는 OpenShift SDN의 기본값입니다.
• OpenShift CLI(oc)를 설치합니다.
• admin 권한이 있는 사용자로 클러스터에 로그인합니다.

사전 요구 사항

• ROSA CLI(rosa)를 설치합니다.
• 클러스터 관리자로 클러스터에 로그인합니다.

프로세스

• 하나 이상의 송신 IP 주소를 호스팅할 수 있도록 노드에 레이블을 지정하려면 다음 명령을 입력합니다.

  $ rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="

  중요

  이 명령은 machinepool의 모든 흥미로운 노드 레이블을 대체합니다. 기존 노드 레이블이 유지되도록 --labels 필드에 원하는 라벨을 포함해야 합니다.

• 송신 IP 할당

사전 요구 사항

• OpenShift CLI(oc)를 설치합니다.
• 관리자로 로그인되어 있습니다.
• 포트 및 포트의 트래픽을 수신하는 TCP 엔드포인트를 노출하는 웹 애플리케이션이 있습니다.

검증

• 생성한 경로 리소스가 있는지 확인하려면 다음 명령을 실행합니다.

  $ oc get routes -o yaml <name of resource> 1

  1

  이 예제에서 경로 이름은 hello-openshift 입니다.

사전 요구 사항

• 실행 중인 클러스터에 배포된 Ingress 컨트롤러가 필요합니다.

• 경로당 HSTS 활성화
• 라우팅당 HSTS 비활성화
• 도메인당 HSTS 시행, 도메인 집합 또는 도메인과 함께 네임스페이스 라벨 사용

사전 요구 사항

• OpenShift CLI(oc)가 설치되어 있습니다.
• 프로젝트 관리자로 AWS 클러스터의 Red Hat OpenShift Service에 로그인되어 있습니다.
• 포트에서 트래픽을 수신하는 포트와 HTTP 또는 TLS 끝점을 노출하는 웹 애플리케이션이 있습니다.

사전 요구 사항

• 노출하려는 서비스가 있습니다.
• OpenShift CLI(oc)에 액세스할 수 있습니다.

검증

• 다음 명령을 실행하여 AWS의 Red Hat OpenShift Service가 Ingress 오브젝트에 대한 예상 경로를 생성했는지 확인합니다.

  $ oc get routes -o yaml

  출력 예

  apiVersion: v1
  items:
  - apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend-j9sdd 1
      ...
    spec:
    ...
      tls: 2
        insecureEdgeTerminationPolicy: Redirect
        termination: edge 3
    ...

  1

  경로 이름에는 Ingress 오브젝트의 이름과 임의의 접미사가 포함됩니다.

  2

  기본 인증서를 사용하려면 경로에서 spec.certificate 를 지정하지 않아야 합니다.

  3

  경로는 엣지 종료 정책을 지정해야 합니다.

사전 요구 사항

• PEM 인코딩 파일에 인증서/키 쌍이 있고, 인증서가 경로 호스트에 유효할 수 있습니다.
• 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
• PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
• 노출하려는 서비스가 있어야 합니다.

사전 요구 사항

• PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
• 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
• PEM 인코딩 파일에 별도의 대상 CA 인증서가 있어야 합니다.
• 노출하려는 서비스가 있어야 합니다.

• 재암호화 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

  $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

  생성된 Route 리소스는 다음과 유사합니다.

  보안 경로의 YAML 정의

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: reencrypt
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      destinationCACertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  자세한 옵션은 oc create route reencrypt --help를 참조하십시오.

사전 요구 사항

• PEM 인코딩 파일에 인증서/키 쌍이 있고 해당 인증서가 경로 호스트에 유효해야 합니다.
• 인증서 체인을 완성하는 PEM 인코딩 파일에 별도의 CA 인증서가 있을 수 있습니다.
• 노출하려는 서비스가 있어야 합니다.

• 엣지 TLS 종료 및 사용자 정의 인증서를 사용하여 보안 Route 리소스를 생성합니다.

  $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

  생성된 Route 리소스는 다음과 유사합니다.

  보안 경로의 YAML 정의

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: edge
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  추가 옵션은 oc create route edge --help를 참조하십시오.

사전 요구 사항

• 노출하려는 서비스가 있어야 합니다.

프로세스

• Route 리소스를 생성합니다.

  $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

  생성된 Route 리소스는 다음과 유사합니다.

  패스스루 종료를 사용하는 보안 경로

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: route-passthrough-secured 1
  spec:
    host: www.example.com
    port:
      targetPort: 8080
    tls:
      termination: passthrough 2
      insecureEdgeTerminationPolicy: None 3
    to:
      kind: Service
      name: frontend

  1

  63자로 제한되는 개체의 이름입니다.

  2

  termination 필드는 passthrough로 설정됩니다. 이 필드는 유일한 필수 tls 필드입니다.

  3

  insecureEdgeTerminationPolicy는 선택 사항입니다. 비활성화경우 유효한 값은 None, Redirect 또는 빈 값입니다.

  대상 Pod는 끝점의 트래픽에 대한 인증서를 제공해야 합니다. 현재 이 방법은 양방향 인증이라고도 하는 클라이언트 인증서도 지원할 수 있는 유일한 방법입니다.