• 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.13.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.13.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.13.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.13.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 사양을 사용하여 하나의 네트워크 정책을 생성하는 것이 더 효과적일 수 있습니다. 예를 들어 다음 두 정책에는 다른 규칙이 있습니다.

  metadata:
   name: policy1
  spec:
   podSelector:
     matchLabels:
       role: db
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend
  
  metadata:
   name: policy2
  spec:
   podSelector:
     matchLabels:
       role: client
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend

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

  metadata:
   name: policy3
  spec:
   podSelector:
     matchExpressions:
       - {key: role, operator: In, values: [db, client]}
    ingress:
      - from:
         - podSelector:
             matchLabels:
               role: frontend

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

• 네트워크 정책 생성

사전 요구 사항

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

사전 요구 사항

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

사전 요구 사항

• 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가 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는 끝점의 트래픽에 대한 인증서를 제공해야 합니다. 현재 이 방법은 양방향 인증이라고도 하는 클라이언트 인증서도 지원할 수 있는 유일한 방법입니다.