Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

네트워크 보안

OpenShift Container Platform 4.18

OpenShift Container Platform에서 네트워크 트래픽 보안 및 네트워크 정책 적용

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 네트워크 정책 및 송신 방화벽과 같은 네트워크 보안 기능을 구현하고 관리하는 방법을 설명합니다.

1장. 네트워크 정책 API 이해
링크 복사

Kubernetes는 사용자가 네트워크 보안을 적용하는 데 사용할 수 있는 두 가지 기능을 제공합니다. 사용자가 네트워크 정책을 적용할 수 있는 한 가지 기능은 애플리케이션 개발자 및 네임스페이스 테넌트가 네임스페이스 범위 정책을 생성하여 네임스페이스를 보호하기 위해 주로 설계된 NetworkPolicy API입니다.

두 번째 기능은 AdminNetworkPolicy (ANP) API와 Baseline AdminNetworkPolicy (BANP) API의 두 API로 구성된 AdminNetworkPolicy입니다. ANP 및 BANP는 클러스터 범위 정책을 생성하여 클러스터 및 네트워크 관리자가 전체 클러스터를 보호하도록 설계되었습니다. 클러스터 관리자는 ANPs를 사용하여 NetworkPolicy 오브젝트보다 우선하는 복구 불가능한 정책을 적용할 수 있습니다. 관리자는 BANP를 사용하여 필요한 경우 NetworkPolicy 오브젝트를 사용하는 사용자가 덮어쓸 수 있는 선택적 클러스터 범위 네트워크 정책 규칙을 설정하고 적용할 수 있습니다. ANP, BANP 및 네트워크 정책을 함께 사용하면 관리자가 클러스터를 보호하는 데 사용할 수 있는 완전한 다중 테넌트 격리를 수행할 수 있습니다.

OpenShift Container Platform의 OVN-Kubernetes CNI는 ACL(Access Control List) 계층을 사용하여 이러한 네트워크 정책을 구현하여 이를 평가하고 적용합니다. ACL은 계층 1에서 계층 3까지 내림차순으로 평가됩니다.

계층 1은 관리NetworkPolicy (ANP) 오브젝트를 평가합니다. 계층 2는 NetworkPolicy 오브젝트를 평가합니다. 계층 3은 BaselineAdminNetworkPolicy (BANP) 오브젝트를 평가합니다.

OVK-Kubernetes Access Control List (ACL)
View larger image
OVK-Kubernetes Access Control List (ACL)

ANP가 먼저 평가됩니다. 일치 항목이 ANP 허용 또는 거부 규칙인 경우 클러스터의 기존 NetworkPolicy 및 BANP( BaselineAdminNetworkPolicy ) 오브젝트는 평가에서 건너뜁니다. 일치 항목이 ANP 통과 규칙인 경우 평가는 ACL의 계층 1에서 NetworkPolicy 정책이 평가되는 계층 2로 이동합니다. NetworkPolicy 가 트래픽과 일치하지 않으면 평가는 계층 2 ACL에서 BANP가 평가되는 계층 3 ACL로 이동합니다.

1.1. AdminNetworkPolicy와 NetworkPolicy 사용자 정의 리소스의 주요 차이점
링크 복사

다음 표에서는 클러스터 범위 AdminNetworkPolicy API와 네임스페이스 범위 NetworkPolicy API 간의 주요 차이점을 설명합니다.

Expand
정책 요소AdminNetworkPolicyNetworkPolicy

적용 가능한 사용자

클러스터 관리자 또는 이에 상응하는

네임스페이스 소유자

범위

Cluster

namespaced

트래픽 드롭

명시적 거부 작업 세트에서 규칙으로 지원됩니다.

정책 생성 시 암시적 거부 격리를 통해 지원됩니다.

트래픽 위임

규칙으로 Pass 작업 세트에서 지원됩니다.

해당 없음

트래픽 허용

명시적 허용 작업 세트를 규칙으로 사용하여 지원됩니다.

모든 규칙에 대한 기본 작업은 허용하는 것입니다.

정책 내에서 규칙 우선순위

ANP 내에 표시되는 순서에 따라 달라집니다. 규칙의 위치가 높을수록 우선순위가 높습니다.

규칙이 추가됩니다.

정책 우선순위

ANPs 중 우선순위 필드는 평가 순서를 설정합니다. 정책 우선 순위가 높은 우선 순위 번호가 적습니다.

정책 간에는 정책 순서가 없습니다.

기능 우선 순위

계층 1 ACL 및 BANP를 통해 먼저 평가되는 것은 계층 3 ACL을 통해 마지막으로 평가됩니다.

ANP 및 BANP 전에 시행되며 ACL의 계층 2에서 평가됩니다.

Pod 선택 일치

네임스페이스에 다른 규칙을 적용할 수 있습니다.

단일 네임스페이스의 Pod에 다른 규칙을 적용할 수 있습니다.

클러스터 송신 트래픽

노드 및 네트워크 피어를 통해 지원

허용되는 CIDR 구문과 함께 ipBlock 필드를 통해 지원됩니다.

클러스터 인그레스 트래픽

지원되지 않음

지원되지 않음

FQDN(정규화된 도메인 이름) 피어 지원

지원되지 않음

지원되지 않음

네임스페이스 선택기

namespaces.matchLabels 필드를 사용하여 고급 네임스페이스 선택 지원

namespaceSelector 필드를 사용하여 라벨 기반 네임스페이스 선택 지원

2장. 관리자 네트워크 정책
링크 복사

2.1. OVN-Kubernetes AdminNetworkPolicy
링크 복사

2.1.1. AdminNetworkPolicy
링크 복사

관리NetworkPolicy (ANP)는 클러스터 범위의 CRD(사용자 정의 리소스 정의)입니다. OpenShift Container Platform 관리자는 ANP를 사용하여 네임스페이스를 생성하기 전에 네트워크 정책을 생성하여 네트워크를 보호할 수 있습니다. 또한 NetworkPolicy 오브젝트에서 덮어쓸 수 없는 클러스터 범위 수준에서 네트워크 정책을 생성할 수 있습니다.

AdminNetworkPolicy 와 NetworkPolicy 오브젝트의 주요 차이점은 전자는 관리자용이고 후자는 테넌트 소유자용이고 네임스페이스 범위가 지정되는 동안 클러스터 범위라는 것입니다.

관리자는 ANP를 사용하여 다음을 지정할 수 있습니다.

  • 평가 순서를 결정하는 우선순위 값입니다. 우선 순위가 가장 높은 값이 낮을 수 있습니다.
  • 정책이 적용되는 네임스페이스 또는 네임스페이스 세트로 구성된 Pod 세트입니다.
  • 제목 을 향하는 모든 인그레스 트래픽에 적용할 수신 규칙 목록입니다.
  • 제목의 모든 송신 트래픽에 적용할 송신 규칙 목록입니다.
AdminNetworkPolicy 예

예 2.1. ANP에 대한 YAML 파일의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: sample-anp-deny-pass-rules
1 

spec:
  priority: 50
2 

  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name
3 

  ingress:
4 

  - name: "deny-all-ingress-tenant-1"
5 

    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1
6 

  egress:
7 

  - name: "pass-all-egress-to-tenant-1"
    action: "Pass"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-anp: tenant-1
        podSelector:
          matchLabels:
            custom-anp: tenant-1
Copy to Clipboard Toggle word wrap
1
ANP의 이름을 지정합니다.
2
spec.priority 필드는 클러스터의 값 0-99 범위에서 최대 100개의 ANP를 지원합니다. 값이 낮을수록 범위가 가장 낮은 값에서 가장 높은 값으로 읽혀지므로 우선 순위가 높습니다. ANP가 동일한 우선 순위로 생성될 때 정책이 우선 순위가 적용되는 보장이 없기 때문에 우선 순위가 결정되도록 ANP를 다른 우선순위로 설정합니다.
3
ANP 리소스를 적용할 네임스페이스를 지정합니다.
4
ANP에는 ingress 및 egress 규칙이 모두 있습니다. spec.ingress 필드의 ANP 규칙은 Pass,Deny 및 Allow for the action 필드를 허용합니다.
5
ingress.name 의 이름을 지정합니다.
6
namespaceSelector.matchLabels 에서 선택한 네임스페이스 내에서 Ingress 피어로 Pod를 선택하려면 podSelector.matchLabels 를 지정합니다.
7
ANP에는 수신 및 송신 규칙이 모두 있습니다. spec.egress 필드에 대한 ANP 규칙은 Pass,Deny 및 Allow for the action 필드를 허용합니다.

추가 리소스

2.1.1.1. 규칙에 대한 AdminNetworkPolicy 작업
링크 복사

관리자는 AdminNetworkPolicy 규칙에 대한 작업 필드로 Allow,Deny 또는 Pass 를 설정할 수 있습니다. OVN-Kubernetes는 계층화된 ACL을 사용하여 네트워크 트래픽 규칙을 평가하므로 관리자가 이를 수정하거나, 규칙을 삭제하거나, 우선 순위 규칙을 설정하여만 변경할 수 있는 매우 강력한 정책 규칙을 설정할 수 있습니다.

AdminNetworkPolicy 허용 예

우선 순위 9에 정의된 다음 ANP는 모니터링 네임스페이스에서 클러스터의 테넌트(다른 모든 네임스페이스)로 모든 수신 트래픽을 허용합니다.

예 2.2. 강력한 허용 ANP를 위한 YAML 파일의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: allow-monitoring
spec:
  priority: 9
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  ingress:
  - name: "allow-ingress-from-monitoring"
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

이는 관련된 모든 당사자가 해결할 수 없기 때문에 강력한 Allow ANP의 예입니다. 테넌트는 NetworkPolicy 오브젝트를 사용하여 자체적으로 모니터링되는 것을 차단할 수 없으며 모니터링 테넌트도 모니터링할 수 있거나 모니터링할 수 없습니다.

AdminNetworkPolicy 거부 예

우선순위 5에 정의된 다음 ANP는 모니터링 네임스페이스의 모든 수신 트래픽이 제한된 테넌트( 보안: restricted)로 차단되도록 합니다.

예 2.3. 강력한 Deny ANP를 위한 YAML 파일의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: block-monitoring
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        security: restricted
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

이는 강력한 Deny ANP로, 관련된 모든 당사자가 해결할 수 없는 강력한 Deny ANP입니다. 제한된 테넌트 소유자는 모니터링 트래픽을 허용하도록 권한을 부여할 수 없으며 인프라의 모니터링 서비스는 이러한 민감한 네임스페이스에서 아무것도 스크랩할 수 없습니다.

강력한 Allow 예제와 결합할 때 block-monitoring ANP는 우선순위가 높은 우선 순위 값을 가지므로 제한된 테넌트가 모니터링되지 않습니다.

AdminNetworkPolicy Pass 예

우선순위 7에 정의된 다음 ANP는 모니터링 네임스페이스에서 내부 인프라 테넌트(네트러블 security가 있는 네임스페이스)로 들어오는 모든 수신 트래픽을 ACL의 계층 2로 전달되고 네임스페이스의 NetworkPolicy 오브젝트에 의해 평가됩니다.

예 2.4. 강력한 Pass ANP를 위한 YAML 파일의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: pass-monitoring
spec:
  priority: 7
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "pass-ingress-from-monitoring"
    action: "Pass"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

이 예는 테넌트 소유자가 정의한 NetworkPolicy 오브젝트에 결정을 위임하기 때문에 강력한 Pass 작업 ANP입니다. 이 pass-monitoring ANP를 사용하면 모든 테넌트 소유자가 내부 보안 수준에서 그룹화하여 네임스페이스 범위 NetworkPolicy 오브젝트를 사용하여 인프라의 모니터링 서비스에서 메트릭을 스크랩해야 하는지 여부를 선택할 수 있습니다.

2.2. OVN-Kubernetes BaselineAdminNetworkPolicy
링크 복사

2.2.1. BaselineAdminNetworkPolicy
링크 복사

BMC( BaselineAdminNetworkPolicy )는 클러스터 범위의 CRD(사용자 정의 리소스 정의)입니다. OpenShift Container Platform 관리자는 BANP를 사용하여 NetworkPolicy 오브젝트를 사용하는 사용자가 덮어쓸 수 있는 선택적 기본 네트워크 정책 규칙을 설정하고 적용할 수 있습니다. BANP에 대한 규칙 작업은 허용 또는 거부 됩니다.

BaselineAdminNetworkPolicy 리소스는 전달된 트래픽 정책이 클러스터의 NetworkPolicy 오브젝트와 일치하지 않는 경우 가드레일 정책으로 사용할 수 있는 클러스터 싱글톤 오브젝트 입니다. BANP는 클러스터 내 트래픽이 기본적으로 차단되는 가드레일을 제공하는 기본 보안 모델로 사용할 수 있으며 사용자는 알려진 트래픽을 허용하기 위해 NetworkPolicy 오브젝트를 사용해야 합니다. BANP 리소스를 생성할 때 이름으로 default 를 사용해야 합니다.

관리자는 BANP를 사용하여 다음을 지정할 수 있습니다.

  • 네임스페이스 또는 네임스페이스 세트로 구성된 제목 입니다.
  • 제목 을 향하는 모든 인그레스 트래픽에 적용할 수신 규칙 목록입니다.
  • 제목의 모든 송신 트래픽에 적용할 송신 규칙 목록입니다.
BaselineAdminNetworkPolicy 예

예 2.5. BANP의 YAML 파일 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
1 

spec:
  subject:
    namespaces:
      matchLabels:
          kubernetes.io/metadata.name: example.name
2 

  ingress:
3 

  - name: "deny-all-ingress-from-tenant-1"
4 

    action: "Deny"
    from:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
5 

        podSelector:
          matchLabels:
            custom-banp: tenant-1
6 

  egress:
  - name: "allow-all-egress-to-tenant-1"
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            custom-banp: tenant-1
        podSelector:
          matchLabels:
            custom-banp: tenant-1
Copy to Clipboard Toggle word wrap
1
BANP는 싱글톤 오브젝트이므로 정책 이름을 기본값 으로 설정해야 합니다.
2
ANP를 적용할 네임스페이스를 지정합니다.
3
BANP에는 ingress 및 egress 규칙이 모두 있습니다. spec.ingress 및 spec.egress 필드에 대한 BANP 규칙은 Deny 및 Allow for the action 필드를 허용합니다.
4
ingress.name의 이름을 지정
5
BANP 리소스를 적용하려면 에서 Pod를 선택하도록 네임스페이스를 지정합니다.
6
BANP 리소스를 적용할 Pod의 podSelector.matchLabels 이름을 지정합니다.
BaselineAdminNetworkPolicy Deny 예

다음 BANP 싱글톤은 관리자가 내부 보안 수준에서 테넌트로 들어오는 모든 수신 모니터링 트래픽에 대한 기본 거부 정책을 설정하도록 합니다. "AdminNetworkPolicy Pass example"과 결합하면 이 거부 정책은 ANP pass-monitoring 정책에서 전달하는 모든 인그레스 트래픽에 대한 보호 정책 역할을 합니다.

예 2.6. guardrail Deny 규칙의 YAML 파일의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
        security: internal
  ingress:
  - name: "deny-ingress-from-monitoring"
    action: "Deny"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

Baseline AdminNetworkPolicy 리소스와 함께 작업 필드의 Pass 값과 함께 AdminNetworkPolicy 리소스를 사용하여 다중 테넌트 정책을 생성할 수 있습니다. 이 다중 테넌트 정책을 사용하면 한 테넌트에서 두 번째 테넌트에서 데이터를 동시에 수집하지 않고 애플리케이션에서 모니터링 데이터를 수집할 수 있습니다.

관리자는 "AdminNetworkPolicy Pass 작업 예"와 "BaselineAdminNetwork Policy Deny example"을 모두 적용하면 테넌트는 BANP 전에 평가할 NetworkPolicy 리소스를 생성하도록 선택할 수 있는 기능을 남겨 둡니다.

예를 들어 Tenant 1은 다음 NetworkPolicy 리소스를 설정하여 수신 트래픽을 모니터링할 수 있습니다.

예 2.7. NetworkPolicy예

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring
  namespace: tenant 1
spec:
  podSelector:
  policyTypes:
    - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: monitoring
# ...
Copy to Clipboard Toggle word wrap

이 시나리오에서 Tenant 1의 정책은 "AdminNetworkPolicy Pass 작업 예제" 및 "BaselineAdminNetwork Policy Deny example" 이전에 평가되며 보안 수준 internal 이 있는 테넌트로 들어오는 모든 수신 모니터링 트래픽을 거부합니다. Tenant 1의 NetworkPolicy 오브젝트를 사용하면 애플리케이션에서 데이터를 수집할 수 있습니다. 테넌트 2 그러나 NetworkPolicy 오브젝트가 없는 사용자는 데이터를 수집할 수 없습니다. 관리자는 기본적으로 내부 테넌트를 모니터링하지 않았으며 대신 테넌트가 NetworkPolicy 오브젝트를 사용하여 BANP의 기본 동작을 재정의할 수 있는 BANP를 생성했습니다.

2.3. 모니터링 ANP 및 BANP
링크 복사

AdminNetworkPolicy 및 BaselineAdminNetworkPolicy 리소스에는 정책을 모니터링하고 관리하는 데 사용할 수 있는 메트릭이 있습니다. 메트릭에 대한 자세한 내용은 다음 표를 참조하십시오.

2.3.1. AdminNetworkPolicy의 메트릭
링크 복사

Expand
이름설명설명

ovnkube_controller_admin_network_policies

해당 없음

클러스터의 총 AdminNetworkPolicy 리소스 수입니다.

ovnkube_controller_baseline_admin_network_policies

해당 없음

클러스터의 총 BaselineAdminNetworkPolicy 리소스 수입니다. 값은 0 또는 1이어야 합니다.

ovnkube_controller_admin_network_policies_rules

  • direction: Ingress 또는 Egress 를 지정합니다.
  • action: Pass,Allow 또는 Deny 를 지정합니다.

방향 및 조치로 그룹화된 클러스터의 모든 ANP 정책의 총 규칙 수입니다.

ovnkube_controller_baseline_admin_network_policies_rules

  • direction: Ingress 또는 Egress 를 지정합니다.
  • action: 허용 또는 거부를 지정합니다.

방향 및 조치로 그룹화된 클러스터의 모든 BANP 정책의 총 규칙 수입니다.

ovnkube_controller_admin_network_policies_db_objects

table_name: ACL 또는 Address_Set을 지정합니다.

table_name 으로 그룹화된 클러스터의 모든 ANP에서 생성하는 총 OVN Northbound 데이터베이스(nbdb) 오브젝트 수입니다.

ovnkube_controller_baseline_admin_network_policies_db_objects

table_name: ACL 또는 Address_Set을 지정합니다.

table_name 으로 그룹화된 클러스터의 모든 BANP에 의해 생성되는 총 OVN Northbound 데이터베이스(nbdb) 오브젝트 수입니다.

2.4. 관리NetworkPolicy의 송신 노드 및 네트워크 피어
링크 복사

이 섹션에서는 노드 및 네트워크 피어에 대해 설명합니다. 관리자는 이 섹션의 예제를 사용하여 AdminNetworkPolicy 및 BaselineAdminNetworkPolicy 를 설계하여 클러스터의 northbound 트래픽을 제어할 수 있습니다.

east-west 트래픽 제어를 지원하는 것 외에도 ANP 및 BANP를 사용하면 관리자가 클러스터의 다른 노드로 노드를 나가는 northbound 트래픽을 제어할 수 있습니다. 최종 사용자는 다음을 수행할 수 있습니다.

  • 노드 송신 피어를 사용하여 클러스터 노드에 대한 송신 트래픽 제어를 구현합니다.
  • 노드 또는 네트워크 송신 피어를 사용하여 Kubernetes API 서버에 대한 송신 트래픽 제어를 구현합니다.
  • 네트워크 피어를 사용하여 클러스터 외부의 외부 대상에 대한 송신 트래픽 제어를 구현합니다.
참고

ANP 및 BANP의 경우 노드 및 네트워크 피어는 송신 규칙에 대해서만 지정할 수 있습니다.

2.4.1.1. 노드 피어를 사용하여 클러스터 노드로의 송신 트래픽 제어
링크 복사

노드 피어 관리자를 사용하면 Pod에서 클러스터 노드로의 송신 트래픽을 제어할 수 있습니다. 이로 인해 노드가 클러스터에 추가되거나 클러스터에 삭제될 때 정책을 변경할 필요가 없습니다.

다음 예제에서는 노드 선택기 피어를 사용하여 제한된,기밀 또는 내부 보안 수준이 있는 네임스페이스에 의해 포트 6443 의 Kubernetes API 서버로의 송신 트래픽을 허용합니다. 또한 제한된 기밀 또는 내부 보안 수준이 있는 네임스페이스에서 클러스터의 모든 작업자 노드에 대한 트래픽을 거부합니다.

예 2.8. 노드 피어를 사용하여 송신 허용 의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-security-allow
spec:
  egress:
  - action: Deny
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
  - action: Allow
    name: allow-to-kubernetes-api-server-and-engr-dept-pods
    ports:
    - portNumber:
        port: 6443
        protocol: TCP
    to:
    - nodes:
1 

        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    - pods:
2 

        namespaceSelector:
          matchLabels:
            dept: engr
        podSelector: {}
  priority: 55
  subject:
3 

    namespaces:
      matchExpressions:
      - key: security
4 

        operator: In
        values:
        - restricted
        - confidential
        - internal
Copy to Clipboard Toggle word wrap
1
matchExpressions 필드를 사용하여 클러스터의 노드 또는 노드 집합을 지정합니다.
2
dept: engr 로 레이블이 지정된 모든 Pod를 지정합니다.
3
네트워크 정책에서 사용하는 라벨과 일치하는 네임스페이스를 포함하는 ANP의 제목을 지정합니다. 이 예제에서는 제한된 보안,기밀 또는 내부 보안 수준이 있는 네임스페이스와 일치합니다.
4
matchExpressions 필드의 키/값 쌍을 지정합니다.
2.4.1.2. 네트워크 피어를 사용하여 외부 대상으로의 송신 트래픽 제어
링크 복사

클러스터 관리자는 네트워크 피어에서 CIDR 범위를 사용하고 Pod에서 나가는 송신 트래픽을 제어하고 네트워크 필드로 지정된 CIDR 범위 내에 있는 IP 주소에 구성된 대상으로 이동할 수 있습니다.

다음 예제에서는 네트워크 피어를 사용하고 ANP 및 BANP 정책을 결합하여 송신 트래픽을 제한합니다.

중요

ANP 및 BANP의 네임스페이스 필드에서 빈 선택기({})를 사용합니다. 빈 선택기를 사용하는 경우 OpenShift 네임스페이스도 선택합니다.

ANP 또는 BANP Deny 규칙에서 0.0.0.0/0 값을 사용하는 경우 Deny 를 0.0.0.0/0 로 설정하기 전에 더 높은 우선 순위 ANP 허용 규칙을 필요한 대상에 설정해야 합니다.

예 2.9. 네트워크 피어를 사용하는 ANP 및 BANP의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: network-as-egress-peer
spec:
  priority: 70
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-egress-to-external-dns-servers"
    action: "Deny"
    to:
    - networks:
1 

      - 8.8.8.8/32
      - 8.8.4.4/32
      - 208.67.222.222/32
    ports:
      - portNumber:
          protocol: UDP
          port: 53
  - name: "allow-all-egress-to-intranet"
    action: "Allow"
    to:
    - networks:
2 

      - 89.246.180.0/22
      - 60.45.72.0/22
  - name: "allow-all-intra-cluster-traffic"
    action: "Allow"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  - name: "pass-all-egress-to-internet"
    action: "Pass"
    to:
    - networks:
      - 0.0.0.0/0
3 

---
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  name: default
spec:
  subject:
    namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "deny-all-egress-to-internet"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0
4 

---
Copy to Clipboard Toggle word wrap
1
네트워크를 사용하여 클러스터 외부의 CIDR 네트워크 범위를 지정합니다.
2
리소스의 클러스터 내부 트래픽의 CIDR 범위를 지정합니다.
3 4
네트워크 값을 0.0.0.0/0 으로 설정하여 모든 항목에 대한 거부 송신을 지정합니다. Kubernetes API 및 DNS 서버를 포함한 모든 트래픽을 거부하므로 Deny 를 0.0.0.0/0 로 설정하기 전에 필요한 대상에 우선 순위가 더 높은 허용 규칙이 있는지 확인합니다.

네트워크 피어를 사용하여 network-as-egress-peer ANP와 기본 BANP를 공동으로 사용하여 다음 송신 정책을 적용합니다.

  • 모든 Pod는 나열된 IP 주소에 있는 외부 DNS 서버와 통신할 수 없습니다.
  • 모든 pod는 회사의 인트라넷의 나머지 부분과 통신할 수 있습니다.
  • 모든 Pod는 다른 Pod, 노드 및 서비스와 통신할 수 있습니다.
  • 모든 pod가 인터넷과 통신할 수 없습니다. 마지막 ANP Pass 규칙과 보호 장치가 있는 강력한 BANP Deny 규칙을 결합하여 클러스터의 트래픽을 보호합니다.
2.4.1.3. 노드 피어 및 네트워크 피어 사용
링크 복사

클러스터 관리자는 ANP 및 BANP 정책의 노드 와 네트워크 피어를 결합할 수 있습니다.

예 2.10. 노드 및 네트워크 피어의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: egress-peer-1
1 

spec:
  egress:
2 

  - action: "Allow"
    name: "allow-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - workloads # Egress traffic from nodes with label worker-group: workloads is allowed.
    - networks:
      - 104.154.164.170/32
    - pods:
        namespaceSelector:
          matchLabels:
            apps: external-apps
        podSelector:
          matchLabels:
            app: web # This rule in the policy allows the traffic directed to pods labeled apps: web in projects with apps: external-apps to leave the cluster.
  - action: "Deny"
    name: "deny-egress"
    to:
    - nodes:
        matchExpressions:
        - key: worker-group
          operator: In
          values:
          - infra # Egress traffic from nodes with label worker-group: infra is denied.
    - networks:
      - 104.154.164.160/32 # Egress traffic to this IP address from cluster is denied.
    - pods:
        namespaceSelector:
          matchLabels:
            apps: internal-apps
        podSelector: {}
  - action: "Pass"
    name: "pass-egress"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists # All other egress traffic is passed to NetworkPolicy or BANP for evaluation.
  priority: 30
3 

  subject:
4 

    namespaces:
      matchLabels:
        apps: all-apps
Copy to Clipboard Toggle word wrap
1
정책 이름을 지정합니다.
2
노드 및 네트워크 피어의 경우 ANP에서 northbound 트래픽 제어를 송신 으로만 사용할 수 있습니다.
3
ANP의 우선 순위를 지정하고 평가해야 하는 순서를 결정합니다. 우선순위가 낮은 규칙이 우선순위가 높습니다. ANP는 0~99의 값을 허용하며, 0은 우선순위가 가장 높고 99가 가장 낮은 우선 순위입니다.
4
정책의 규칙을 적용할 클러스터의 Pod 집합을 지정합니다. 이 예에서 apps가 있는 모든 Pod: 모든 네임스페이스의 all-apps 레이블이 정책의 제목 입니다.

2.5. AdminNetworkPolicy 문제 해결
링크 복사

2.5.1. ANP 생성 확인
링크 복사

AdminNetworkPolicy (ANP) 및 BaselineAdminNetworkPolicy (BANP)가 올바르게 생성되었는지 확인하려면 oc describe anp 또는 oc describe prohibitp.

좋은 상태는 OVN DB plumbing이 성공 했으며 SetupSucceeded 임을 나타냅니다.

예 2.11. 상태가 좋은 ANP 예

...
Conditions:
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-control-plane Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker
Last Transition Time:  2024-06-08T20:29:00Z
Message:               Setting up OVN DB plumbing was successful
Reason:                SetupSucceeded
Status:                True
Type:                  Ready-In-Zone-ovn-worker2
...
Copy to Clipboard Toggle word wrap

배관에 실패하면 해당 영역 컨트롤러에서 오류가 보고됩니다.

예 2.12. 잘못된 상태 및 오류 메시지가 있는 ANP의 예

...
Status:
  Conditions:
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:45Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-worker-0.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-1.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-2.example.example-org.net
    Last Transition Time:  2024-06-25T12:47:44Z
    Message:               error attempting to add ANP cluster-control with priority 600 because, OVNK only supports priority ranges 0-99
    Reason:                SetupFailed
    Status:                False
    Type:                  Ready-In-Zone-example-ctlplane-0.example.example-org.net
    ```
Copy to Clipboard Toggle word wrap

실패한 정책 문제를 해결하려면 nbctl 명령의 다음 섹션을 참조하십시오.

2.5.1.1. ANP 및 BANP에 nbctl 명령 사용
링크 복사

실패한 설정 문제를 해결하려면 ACL,AdressSet, Port_Group 을 포함한 OVN Northbound 데이터베이스(nbdb) 오브젝트를 확인하여 시작합니다. nbdb를 보려면 해당 노드의 Pod 내부에 있어야 해당 노드의 오브젝트를 확인해야 합니다.

사전 요구 사항

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

클러스터에서 ovn nbctl 명령을 실행하려면 관련 노드에서 'nbdb'로 원격 쉘을 열어야 합니다.

다음 정책은 출력을 생성하는 데 사용되었습니다.

예 2.13. 출력을 생성하는 데 사용되는 AdminNetworkPolicy

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  name: cluster-control
spec:
  priority: 34
  subject:
    namespaces:
      matchLabels:
        anp: cluster-control-anp # Only namespaces with this label have this ANP
  ingress:
  - name: "allow-from-ingress-router" # rule0
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  - name: "allow-from-monitoring" # rule1
    action: "Allow"
    from:
    - namespaces:
        matchLabels:
          kubernetes.io/metadata.name: openshift-monitoring
    ports:
    - portNumber:
        protocol: TCP
        port: 7564
    - namedPort: "scrape"
  - name: "allow-from-open-tenants" # rule2
    action: "Allow"
    from:
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-from-restricted-tenants" # rule3
    action: "Pass"
    from:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny" # rule4
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "allow-to-dns" # rule0
    action: "Allow"
    to:
    - pods:
        namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-dns
        podSelector:
          matchLabels:
            app: dns
    ports:
    - portNumber:
        protocol: UDP
        port: 5353
  - name: "allow-to-kapi-server" # rule1
    action: "Allow"
    to:
    - nodes:
        matchExpressions:
        - key: node-role.kubernetes.io/control-plane
          operator: Exists
    ports:
    - portNumber:
        protocol: TCP
        port: 6443
  - name: "allow-to-splunk" # rule2
    action: "Allow"
    to:
    - namespaces:
        matchLabels:
          tenant: splunk
    ports:
    - portNumber:
        protocol: TCP
        port: 8991
    - portNumber:
        protocol: TCP
        port: 8992
  - name: "allow-to-open-tenants-and-intranet-and-worker-nodes" # rule3
    action: "Allow"
    to:
    - nodes: # worker-nodes
        matchExpressions:
        - key: node-role.kubernetes.io/worker
          operator: Exists
    - networks: # intranet
      - 172.29.0.0/30
      - 10.0.54.0/19
      - 10.0.56.38/32
      - 10.0.69.0/24
    - namespaces: # open tenants
        matchLabels:
          tenant: open
  - name: "pass-to-restricted-tenants" # rule4
    action: "Pass"
    to:
    - namespaces: # restricted tenants
        matchLabels:
          tenant: restricted
  - name: "default-deny"
    action: "Deny"
    to:
    - networks:
      - 0.0.0.0/0
Copy to Clipboard Toggle word wrap

프로세스

  1. 다음 명령을 실행하여 노드 정보가 있는 Pod를 나열합니다. 

    $ oc get pods -n openshift-ovn-kubernetes -owide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
ovnkube-control-plane-5c95487779-8k9fd   2/2     Running   0          34m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-control-plane-5c95487779-v2xn8   2/2     Running   0          34m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-524dt                       8/8     Running   0          33m   10.0.0.4     ci-ln-0tv5gg2-72292-6sjw5-master-2         <none>           <none>
ovnkube-node-gbwr9                       8/8     Running   0          24m   10.0.128.4   ci-ln-0tv5gg2-72292-6sjw5-worker-c-s9gqt   <none>           <none>
ovnkube-node-h4fpx                       8/8     Running   0          33m   10.0.0.5     ci-ln-0tv5gg2-72292-6sjw5-master-0         <none>           <none>
ovnkube-node-j4hzw                       8/8     Running   0          24m   10.0.128.2   ci-ln-0tv5gg2-72292-6sjw5-worker-a-hzbh5   <none>           <none>
ovnkube-node-wdhgv                       8/8     Running   0          33m   10.0.0.3     ci-ln-0tv5gg2-72292-6sjw5-master-1         <none>           <none>
ovnkube-node-wfncn                       8/8     Running   0          24m   10.0.128.3   ci-ln-0tv5gg2-72292-6sjw5-worker-b-5bb7f   <none>           <none>
    Copy to Clipboard Toggle word wrap

  2. 포드로 이동하여 다음 명령을 실행하여 northbound 데이터베이스를 확인합니다. 

    $ oc rsh -c nbdb -n openshift-ovn-kubernetes ovnkube-node-524dt
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 ACL nbdb를 확인합니다. 

    $ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
    Copy to Clipboard Toggle word wrap
    다음과 같습니다., cluster-control
    문제를 해결하는 AdminNetworkPolicy 의 이름을 지정합니다.
    AdminNetworkPolicy
    AdminNetworkPolicy 또는 BaselineAdminNetworkPolicy 유형을 지정합니다.

    예 2.14. ACL 출력 예

    _uuid               : 0d5e4722-b608-4bb1-b625-23c323cc9926
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13730899355151937870))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:2"
options             : {}
priority            : 26598
severity            : []
tier                : 1

_uuid               : b7be6472-df67-439c-8c9c-f55929f0a6e0
action              : drop
direction           : from-lport
external_ids        : {direction=Egress, gress-index="5", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a11452480169090787059))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:5"
options             : {apply-after-lb="true"}
priority            : 26595
severity            : []
tier                : 1

_uuid               : 5a6e5bb4-36eb-4209-b8bc-c611983d4624
action              : pass
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a764182844364804195))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:3"
options             : {}
priority            : 26597
severity            : []
tier                : 1

_uuid               : 04f20275-c410-405c-a923-0e677f767889
action              : pass
direction           : from-lport
external_ids        : {direction=Egress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a5972452606168369118))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:4"
options             : {apply-after-lb="true"}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 4b5d836a-e0a3-4088-825e-f9f0ca58e538
action              : drop
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="4", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a13814616246365836720))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:4"
options             : {}
priority            : 26596
severity            : []
tier                : 1

_uuid               : 5d09957d-d2cc-4f5a-9ddd-b97d9d772023
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="2", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a18396736153283155648)) && tcp && tcp.dst=={8991,8992}"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:2"
options             : {apply-after-lb="true"}
priority            : 26598
severity            : []
tier                : 1

_uuid               : 1a68a5ed-e7f9-47d0-b55c-89184d97e81a
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10706246167277696183)) && tcp && tcp.dst==6443"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:1"
options             : {apply-after-lb="true"}
priority            : 26599
severity            : []
tier                : 1

_uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1

_uuid               : 1a27d30e-3f96-4915-8ddd-ade7f22c117b
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="3", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a10622494091691694581))"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:3"
options             : {apply-after-lb="true"}
priority            : 26597
severity            : []
tier                : 1

_uuid               : b23a087f-08f8-4225-8c27-4a9a9ee0c407
action              : allow-related
direction           : from-lport
external_ids        : {direction=Egress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:udp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=udp}
label               : 0
log                 : false
match               : "inport == @a14645450421485494999 && ((ip4.dst == $a13517855690389298082)) && udp && udp.dst==5353"
meter               : acl-logging
name                : "ANP:cluster-control:Egress:0"
options             : {apply-after-lb="true"}
priority            : 26600
severity            : []
tier                : 1

_uuid               : d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="0", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:None", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=None}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a14545668191619617708))"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:0"
options             : {}
priority            : 26600
severity            : []
tier                : 1
    Copy to Clipboard Toggle word wrap
    참고

    수신 및 송신에 대한 출력은 ACL의 정책 논리를 표시합니다. 예를 들어 패킷이 제공된 것과 일치 할 때마다 작업이 수행됩니다.

    1. 다음 명령을 실행하여 규칙에 대한 특정 ACL을 검사합니다. 

      $ ovn-nbctl find ACL 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Ingress,"k8s.ovn.org/name"=cluster-control,gress-index="1"}'
      Copy to Clipboard Toggle word wrap
      다음과 같습니다., cluster-control
      ANP의 이름을 지정합니다.
      Ingress
      Ingress 또는 Egress 유형의 트래픽 방향을 지정합니다.
      1
      확인할 규칙을 지정합니다.

      우선순위 34 에서 cluster-control 이라는 ANP의 예는 Ingress 규칙 1의 출력 예입니다.

      예 2.15. 출력 예

      _uuid               : aa1a224d-7960-4952-bdfb-35246bafbac8
action              : allow-related
direction           : to-lport
external_ids        : {direction=Ingress, gress-index="1", "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:tcp", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy, port-policy-protocol=tcp}
label               : 0
log                 : false
match               : "outport == @a14645450421485494999 && ((ip4.src == $a6786643370959569281)) && tcp && tcp.dst==7564"
meter               : acl-logging
name                : "ANP:cluster-control:Ingress:1"
options             : {}
priority            : 26599
severity            : []
tier                : 1
      Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 nbdb의 주소 세트를 확인합니다. 

    $ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
    Copy to Clipboard Toggle word wrap

    예 2.16. Address_Set출력 예

    _uuid               : 56e89601-5552-4238-9fc3-8833f5494869
addresses           : ["192.168.194.135", "192.168.194.152", "192.168.194.193", "192.168.194.254"]
external_ids        : {direction=Egress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10706246167277696183

_uuid               : 7df9330d-380b-4bdb-8acd-4eddeda2419c
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13814616246365836720

_uuid               : 84d76f13-ad95-4c00-8329-a0b1d023c289
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Egress, gress-index="4", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:4:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a5972452606168369118

_uuid               : 0c53e917-f7ee-4256-8f3a-9522c0481e52
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a18396736153283155648

_uuid               : 5228bf1b-dfd8-40ec-bfa8-95c5bf9aded9
addresses           : []
external_ids        : {direction=Ingress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14545668191619617708

_uuid               : 46530d69-70da-4558-8c63-884ec9dc4f25
addresses           : ["10.132.2.10", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.133.0.47", "10.134.0.33", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.19", "10.135.0.24", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Ingress, gress-index="1", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:1:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a6786643370959569281

_uuid               : 65fdcdea-0b9f-4318-9884-1b51d231ad1d
addresses           : ["10.132.3.72", "10.135.0.42"]
external_ids        : {direction=Ingress, gress-index="2", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:2:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13730899355151937870

_uuid               : 73eabdb0-36bf-4ca3-b66d-156ac710df4c
addresses           : ["10.0.32.0/19", "10.0.56.38/32", "10.0.69.0/24", "10.132.3.72", "10.135.0.42", "172.29.0.0/30", "192.168.194.103", "192.168.194.2"]
external_ids        : {direction=Egress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a10622494091691694581

_uuid               : 50cdbef2-71b5-474b-914c-6fcd1d7712d3
addresses           : ["10.132.0.10", "10.132.0.11", "10.132.0.12", "10.132.0.13", "10.132.0.14", "10.132.0.15", "10.132.0.16", "10.132.0.17", "10.132.0.5", "10.132.0.7", "10.132.0.71", "10.132.0.75", "10.132.0.8", "10.132.0.81", "10.132.0.9", "10.132.2.10", "10.132.2.11", "10.132.2.12", "10.132.2.14", "10.132.2.15", "10.132.2.3", "10.132.2.4", "10.132.2.5", "10.132.2.6", "10.132.2.7", "10.132.2.8", "10.132.2.9", "10.132.3.64", "10.132.3.65", "10.132.3.72", "10.132.3.73", "10.132.3.76", "10.133.0.10", "10.133.0.11", "10.133.0.12", "10.133.0.13", "10.133.0.14", "10.133.0.15", "10.133.0.16", "10.133.0.17", "10.133.0.18", "10.133.0.19", "10.133.0.20", "10.133.0.21", "10.133.0.22", "10.133.0.23", "10.133.0.24", "10.133.0.25", "10.133.0.26", "10.133.0.27", "10.133.0.28", "10.133.0.29", "10.133.0.30", "10.133.0.31", "10.133.0.32", "10.133.0.33", "10.133.0.34", "10.133.0.35", "10.133.0.36", "10.133.0.37", "10.133.0.38", "10.133.0.39", "10.133.0.40", "10.133.0.41", "10.133.0.42", "10.133.0.44", "10.133.0.45", "10.133.0.46", "10.133.0.47", "10.133.0.48", "10.133.0.5", "10.133.0.6", "10.133.0.7", "10.133.0.8", "10.133.0.9", "10.134.0.10", "10.134.0.11", "10.134.0.12", "10.134.0.13", "10.134.0.14", "10.134.0.15", "10.134.0.16", "10.134.0.17", "10.134.0.18", "10.134.0.19", "10.134.0.20", "10.134.0.21", "10.134.0.22", "10.134.0.23", "10.134.0.24", "10.134.0.25", "10.134.0.26", "10.134.0.27", "10.134.0.28", "10.134.0.30", "10.134.0.31", "10.134.0.32", "10.134.0.33", "10.134.0.34", "10.134.0.35", "10.134.0.36", "10.134.0.37", "10.134.0.38", "10.134.0.4", "10.134.0.42", "10.134.0.9", "10.135.0.10", "10.135.0.11", "10.135.0.12", "10.135.0.13", "10.135.0.14", "10.135.0.15", "10.135.0.16", "10.135.0.17", "10.135.0.18", "10.135.0.19", "10.135.0.23", "10.135.0.24", "10.135.0.26", "10.135.0.27", "10.135.0.29", "10.135.0.3", "10.135.0.4", "10.135.0.40", "10.135.0.41", "10.135.0.42", "10.135.0.43", "10.135.0.44", "10.135.0.5", "10.135.0.6", "10.135.0.7", "10.135.0.8", "10.135.0.9"]
external_ids        : {direction=Egress, gress-index="0", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:0:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a13517855690389298082

_uuid               : 32a42f32-2d11-43dd-979d-a56d7ee6aa57
addresses           : ["10.132.3.76", "10.135.0.44"]
external_ids        : {direction=Ingress, gress-index="3", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Ingress:3:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a764182844364804195

_uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059
    Copy to Clipboard Toggle word wrap

    1. 다음 명령을 실행하여 규칙의 특정 주소 집합을 검사합니다. 

      $ ovn-nbctl find Address_Set 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,direction=Egress,"k8s.ovn.org/name"=cluster-control,gress-index="5"}'
      Copy to Clipboard Toggle word wrap

      예 2.17. Address_Set출력 예

      _uuid               : 8fd3b977-6e1c-47aa-82b7-e3e3136c4a72
addresses           : ["0.0.0.0/0"]
external_ids        : {direction=Egress, gress-index="5", ip-family=v4, "k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control:Egress:5:v4", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a11452480169090787059
      Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 nbdb의 포트 그룹을 확인합니다. 

    $ ovn-nbctl find Port_Group 'external_ids{>=}{"k8s.ovn.org/owner-type"=AdminNetworkPolicy,"k8s.ovn.org/name"=cluster-control}'
    Copy to Clipboard Toggle word wrap

    예 2.18. Port_Group의 출력 예

    _uuid               : f50acf71-7488-4b9a-b7b8-c8a024e99d21
acls                : [04f20275-c410-405c-a923-0e677f767889, 0d5e4722-b608-4bb1-b625-23c323cc9926, 1a27d30e-3f96-4915-8ddd-ade7f22c117b, 1a68a5ed-e7f9-47d0-b55c-89184d97e81a, 4b5d836a-e0a3-4088-825e-f9f0ca58e538, 5a6e5bb4-36eb-4209-b8bc-c611983d4624, 5d09957d-d2cc-4f5a-9ddd-b97d9d772023, aa1a224d-7960-4952-bdfb-35246bafbac8, b23a087f-08f8-4225-8c27-4a9a9ee0c407, b7be6472-df67-439c-8c9c-f55929f0a6e0, d14ed5cf-2e06-496e-8cae-6b76d5dd5ccd]
external_ids        : {"k8s.ovn.org/id"="default-network-controller:AdminNetworkPolicy:cluster-control", "k8s.ovn.org/name"=cluster-control, "k8s.ovn.org/owner-controller"=default-network-controller, "k8s.ovn.org/owner-type"=AdminNetworkPolicy}
name                : a14645450421485494999
ports               : [5e75f289-8273-4f8a-8798-8c10f7318833, de7e1b71-6184-445d-93e7-b20acadf41ea]
    Copy to Clipboard Toggle word wrap

3장. 네트워크 정책
링크 복사

3.1. 네트워크 정책 정의
링크 복사

개발자는 클러스터의 Pod로 트래픽을 제한하는 네트워크 정책을 정의할 수 있습니다.

3.1.1. 네트워크 정책 정의
링크 복사

기본적으로 네트워크 정책 모드에서는 다른 Pod 및 네트워크 끝점에서 프로젝트의 모든 Pod에 액세스할 수 있습니다. 프로젝트에서 하나 이상의 Pod를 분리하기 위해 해당 프로젝트에서 NetworkPolicy 오브젝트를 생성하여 수신되는 연결을 표시할 수 있습니다. 프로젝트 관리자는 자신의 프로젝트 내에서 NetworkPolicy 오브젝트를 만들고 삭제할 수 있습니다.

하나 이상의 NetworkPolicy 오브젝트에서 선택기와 Pod가 일치하면 Pod는 해당 NetworkPolicy 오브젝트 중 하나 이상에서 허용되는 연결만 허용합니다. NetworkPolicy 오브젝트가 선택하지 않은 Pod에 완전히 액세스할 수 있습니다.

네트워크 정책은 TCP(Transmission Control Protocol), UDP(User Datagram Protocol), IMP(Internet Control Message Protocol) 및 SCTP(Stream Control Transmission Protocol) 프로토콜에만 적용됩니다. 다른 프로토콜은 영향을 받지 않습니다.

주의
  • 네트워크 정책은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 네트워크 정책 규칙의 영향을 받지 않습니다. 그러나 호스트 네트워크 pod에 연결하는 Pod는 네트워크 정책 규칙의 영향을 받을 수 있습니다.
  • podSelector 필드를 {} 로 설정하지 않고 namespaceSelector 필드를 사용하면 hostNetwork Pod가 포함되지 않습니다. 네트워크 정책을 생성할 때 hostNetwork Pod를 대상으로 하려면 namespaceSelector 필드와 함께 {} 로 설정된 podSelector 를 사용해야 합니다.
  • 네트워크 정책은 localhost 또는 상주 노드의 트래픽을 차단할 수 없습니다.

다음 예제 NetworkPolicy 오브젝트는 다양한 시나리오 지원을 보여줍니다.

  • 모든 트래픽 거부:

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

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  ingress: []
    Copy to Clipboard Toggle word wrap

  • OpenShift Container Platform Ingress 컨트롤러의 연결만 허용합니다.

    프로젝트에서 OpenShift Container Platform Ingress 컨트롤러의 연결만 허용하도록 하려면 다음 NetworkPolicy 개체를 추가합니다. 

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

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

    중요

    동일한 네임스페이스에 있는 hostNetwork Pod의 수신 연결을 허용하려면 allow-from-hostnetwork 정책을 allow-same-namespace 정책과 함께 적용해야 합니다.

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

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}
    Copy to Clipboard Toggle word wrap

  • 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
    Copy to Clipboard Toggle word wrap

  • 네임스페이스와 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
    Copy to Clipboard Toggle word wrap

NetworkPolicy 오브젝트는 추가 기능이므로 여러 NetworkPolicy 오브젝트를 결합하여 복잡한 네트워크 요구 사항을 충족할 수 있습니다.

예를 들어, 이전 샘플에서 정의된 NetworkPolicy 오브젝트의 경우 동일한 프로젝트 내에서 allow-same-namespace 정책과 allow-http-and-https 정책을 모두 정의할 수 있습니다. 따라서 레이블이 role=frontend로 지정된 Pod는 각 정책에서 허용하는 모든 연결을 허용할 수 있습니다. 즉 동일한 네임스페이스에 있는 Pod의 모든 포트 연결과 모든 네임스페이스에 있는 Pod에서 포트 80 및 443에 대한 연결이 허용됩니다.

3.1.1.1. allow-from-router 네트워크 정책 사용
링크 복사

다음 NetworkPolicy 를 사용하여 라우터 구성과 관계없이 외부 트래픽을 허용합니다. 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-router
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
1 

  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap
1
policy-group.network.openshift.io/ingress:" 레이블은 OVN-Kubernetes를 지원합니다.
3.1.1.2. allow-from-hostnetwork 네트워크 정책 사용
링크 복사

다음 allow-from-hostnetwork NetworkPolicy 오브젝트를 추가하여 호스트 네트워크 Pod에서 트래픽을 전달합니다. 

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-hostnetwork
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/host-network: ""
  podSelector: {}
  policyTypes:
  - Ingress
Copy to Clipboard Toggle word wrap

네트워크 정책을 설계할 때 다음 지침을 참조하십시오.

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

  • podSelector 또는 namespaceSelector 사양을 기반으로 하는 모든 수신 또는 송신 규칙은 네트워크 정책에서 선택한 Pod 수 + 수신 또는 송신 규칙에서 선택한 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
    Copy to Clipboard Toggle word wrap

    다음 정책은 동일한 두 규칙을 나타냅니다. 

    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]}
    Copy to Clipboard Toggle word wrap

    동일한 지침이 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
    Copy to Clipboard Toggle word wrap

    다음 네트워크 정책은 규칙과 동일한 두 규칙을 나타냅니다. 

    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
    Copy to Clipboard Toggle word wrap

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

3.1.2.1. OVN-Kubernetes의 NetworkPolicy CR 및 외부 IP
링크 복사

OVN-Kubernetes에서 NetworkPolicy CR(사용자 정의 리소스)은 엄격한 격리 규칙을 적용합니다. 외부 IP를 사용하여 서비스가 노출되면 트래픽을 허용하도록 명시적으로 구성되지 않는 한 네트워크 정책에서 다른 네임스페이스의 액세스를 차단할 수 있습니다.

네임스페이스에서 외부 IP에 대한 액세스를 허용하려면 필요한 네임스페이스에서 수신을 명시적으로 허용하고 지정된 서비스 포트에 대한 트래픽을 허용하는 NetworkPolicy CR을 생성합니다. 필요한 포트에 대한 트래픽을 허용하지 않고 액세스는 계속 제한될 수 있습니다.

출력 예

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    annotations:
    name: <policy_name>
    namespace: openshift-ingress
  spec:
    ingress:
    - ports:
      - port: 80
        protocol: TCP
    - ports:
      - port: 443
        protocol: TCP
    - from:
      - namespaceSelector:
          matchLabels:
          kubernetes.io/metadata.name: <my_namespace>
    podSelector: {}
    policyTypes:
    - Ingress
Copy to Clipboard Toggle word wrap

다음과 같습니다.

<policy_name>
정책의 이름을 지정합니다.
<my_namespace>
정책이 배포된 네임스페이스의 이름을 지정합니다.

자세한 내용은 "네트워크 정책 정보"를 참조하십시오.

3.1.3. 다음 단계
링크 복사

3.2. 네트워크 정책 생성
링크 복사

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 생성할 수 있습니다.

3.2.1. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
1 

spec:
  podSelector:
2 

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
3 

        matchLabels:
          app: app
    ports:
4 

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

3.2.2. CLI를 사용하여 네트워크 정책 만들기
링크 복사

클러스터의 네임스페이스에서 허용된 수신 또는 송신 네트워크 트래픽을 설명하는 세분화된 규칙을 정의하기 위해 네트워크 정책을 생성할 수 있습니다.

참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

    1. <policy_name>.yaml 파일을 생성합니다. 

      $ touch <policy_name>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <policy_name>
      네트워크 정책 파일 이름을 지정합니다.

    2. 방금 만든 파일에서 다음 예와 같이 네트워크 정책을 정의합니다.

      모든 네임스페이스의 모든 Pod에서 수신 거부

      이는 다른 네트워크 정책 구성에서 허용하는 포드 간 트래픽 이외의 모든 교차 포드 네트워킹을 차단하는 기본 정책입니다. 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress: []
      Copy to Clipboard Toggle word wrap

      동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
      Copy to Clipboard Toggle word wrap

      특정 네임스페이스에서 하나의 Pod로 수신 트래픽 허용

      이 정책을 사용하면 namespace-y 에서 실행되는 Pod의 pod-a 레이블이 있는 Pod로의 트래픽을 허용합니다. 

      kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-traffic-pod
spec:
  podSelector:
   matchLabels:
      pod: pod-a
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
           kubernetes.io/metadata.name: namespace-y
      Copy to Clipboard Toggle word wrap

  2. 네트워크 정책 오브젝트를 생성하려면 다음 명령을 입력합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 

    $ oc apply -f <policy_name>.yaml -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <policy_name>
    네트워크 정책 파일 이름을 지정합니다.
    <namespace>
    선택적 매개변수입니다. 현재 네임스페이스와 다른 네임스페이스에 오브젝트를 정의한 경우 매개변수는 네임스페이스를 지정합니다.

    성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하는 경우 클러스터의 모든 네임스페이스에서 직접 또는 웹 콘솔의 양식에서 네트워크 정책을 생성할 수 있습니다.

3.2.3. 기본 거부 모든 네트워크 정책 생성
링크 복사

이 정책은 다른 배포된 네트워크 정책 및 호스트 네트워크 Pod 간 트래픽에서 허용하는 네트워크 트래픽 이외의 모든 포드 간 네트워킹을 차단합니다. 이 절차에서는 my -project 네임스페이스에 기본 거부 정책을 적용하여 강력한 거부 정책을 적용합니다.

주의

트래픽 통신을 허용하는 NetworkPolicy CR(사용자 정의 리소스)을 구성하지 않으면 다음 정책으로 클러스터 전체에서 통신 문제가 발생할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 모든 네임스페이스의 모든 포드의 수신을 거부하도록 기본 거부 정책을 정의하는 다음 YAML을 생성합니다. YAML을 deny-by-default.yaml 파일에 저장합니다. 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-by-default
  namespace: my-project
    1 
    
spec:
  podSelector: {}
    2 
    
  ingress: []
    3
    Copy to Clipboard Toggle word wrap
    1
    정책을 배포할 네임스페이스를 지정합니다. 예를 들어 'my-project 네임스페이스는 다음과 같습니다.
    2
    이 필드가 비어 있으면 구성이 모든 Pod와 일치합니다. 따라서 정책은 my-project 네임스페이스의 모든 pod에 적용됩니다.
    3
    지정된 수신 규칙이 없습니다. 이로 인해 들어오는 트래픽이 모든 Pod로 삭제됩니다.

  2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 

    $ oc apply -f deny-by-default.yaml
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

3.2.4. 외부 클라이언트의 트래픽을 허용하는 네트워크 정책 생성
링크 복사

기본 거부 정책을 배치하면 app=web 레이블이 있는 외부 클라이언트에서 Pod로의 트래픽을 허용하는 정책을 구성할 수 있습니다.

참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

다음 절차에 따라 공용 인터넷의 외부 서비스를 직접 또는 Load Balancer를 사용하여 Pod에 액세스하는 방식으로 허용하는 정책을 구성합니다. app=web 레이블이 있는 Pod에만 트래픽이 허용됩니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 직접 또는 로드 밸런서를 사용하여 pod에 액세스하여 공용 인터넷의 트래픽을 허용하는 정책을 생성합니다. YAML을 web-allow-external.yaml 파일에 저장합니다. 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
  namespace: default
spec:
  policyTypes:
  - Ingress
  podSelector:
    matchLabels:
      app: web
  ingress:
    - {}
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 

    $ oc apply -f web-allow-external.yaml
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 이 정책은 다음 다이어그램에 설명된 대로 외부 트래픽을 포함하여 모든 리소스의 트래픽을 허용합니다.

외부 클라이언트의 트래픽 허용
View larger image
외부 클라이언트의 트래픽 허용
참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

다음 절차에 따라 모든 네임스페이스의 모든 Pod에서 특정 애플리케이션으로의 트래픽을 허용하는 정책을 구성합니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 모든 네임스페이스의 모든 Pod에서 특정 애플리케이션으로의 트래픽을 허용하는 정책을 생성합니다. YAML을 web-allow-all-namespaces.yaml 파일에 저장합니다. 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-all-namespaces
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
    1 
    
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    2
    Copy to Clipboard Toggle word wrap
    1
    기본 네임스페이스의 app:web pod에만 정책을 적용합니다.
    2
    모든 네임스페이스의 모든 Pod를 선택합니다.
    참고

    기본적으로 정책 오브젝트에 namespaceSelector 매개변수를 지정하지 않으면 네임스페이스를 선택하지 않습니다. 즉, 정책은 네트워크 정책이 배포하는 네임스페이스의 트래픽만 허용합니다.

  2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 

    $ oc apply -f web-allow-all-namespaces.yaml
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

검증

  1. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다. 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 보조 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다. 

    $ oc run test-$RANDOM --namespace=secondary --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap

  3. 쉘에서 다음 명령을 실행하고 서비스에서 요청을 허용하는지 확인합니다. 

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
    Copy to Clipboard Toggle word wrap

참고

cluster-admin 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

다음 절차에 따라 특정 네임스페이스의 app=web 레이블을 사용하여 Pod로의 트래픽을 허용하는 정책을 구성합니다. 다음을 위해 이 작업을 수행할 수 있습니다.

  • 프로덕션 워크로드가 배포된 네임스페이스로만 트래픽을 프로덕션 데이터베이스로 제한합니다.
  • 특정 네임스페이스에 배포된 모니터링 툴을 활성화하여 현재 네임스페이스에서 메트릭을 스크랩할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. purpose=production 레이블이 있는 특정 네임스페이스의 모든 Pod의 트래픽을 허용하는 정책을 생성합니다. YAML을 web-allow-prod.yaml 파일에 저장합니다. 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
    1 
    
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production
    2
    Copy to Clipboard Toggle word wrap
    1
    기본 네임스페이스의 app:web pod에만 정책을 적용합니다.
    2
    purpose=production 레이블이 있는 네임스페이스의 Pod로만 트래픽을 제한합니다.

  2. 다음 명령을 입력하여 정책을 적용합니다. 성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다. 

    $ oc apply -f web-allow-prod.yaml
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 정책 오브젝트의 이름과 생성된 상태가 나열됩니다.

검증

  1. 다음 명령을 입력하여 기본 네임스페이스에서 웹 서비스를 시작합니다. 

    $ oc run web --namespace=default --image=nginx --labels="app=web" --expose --port=80
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 prod 네임스페이스를 생성합니다. 

    $ oc create namespace prod
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 prod 네임스페이스에 레이블을 지정합니다. 

    $ oc label namespace/prod purpose=production
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 dev 네임스페이스를 생성합니다. 

    $ oc create namespace dev
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 dev 네임스페이스에 레이블을 지정합니다. 

    $ oc label namespace/dev purpose=testing
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 실행하여 dev 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다. 

    $ oc run test-$RANDOM --namespace=dev --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap

  7. 쉘에서 다음 명령을 실행하고 차단된 요청 이유를 확인합니다. 예를 들어 예상되는 출력 상태는 wget: download timed out 입니다. 

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 prod 네임스페이스에 alpine 이미지를 배포하고 쉘을 시작합니다. 

    $ oc run test-$RANDOM --namespace=prod --rm -i -t --image=alpine -- sh
    Copy to Clipboard Toggle word wrap

  9. 쉘에서 다음 명령을 실행하고 요청이 허용되는지 확인합니다. 

    # wget -qO- --timeout=2 http://web.default
    Copy to Clipboard Toggle word wrap

    예상 출력

    <!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
    Copy to Clipboard Toggle word wrap

3.3. 네트워크 정책 보기
링크 복사

admin 역할이 있는 사용자는 네임스페이스에 대한 네트워크 정책을 볼 수 있습니다.

3.3.1. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
1 

spec:
  podSelector:
2 

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
3 

        matchLabels:
          app: app
    ports:
4 

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

3.3.2. CLI를 사용하여 네트워크 정책 보기
링크 복사

네임스페이스에서 네트워크 정책을 검사할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네트워크 정책을 볼 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 네임스페이스의 네트워크 정책을 나열합니다.

    • 네임스페이스에 정의된 네트워크 정책 개체를 보려면 다음 명령을 입력합니다. 

      $ oc get networkpolicy
      Copy to Clipboard Toggle word wrap

    • 선택 사항: 특정 네트워크 정책을 검사하려면 다음 명령을 입력합니다. 

      $ oc describe networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <policy_name>
      검사할 네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

      예를 들면 다음과 같습니다. 

      $ oc describe networkpolicy allow-same-namespace
      Copy to Clipboard Toggle word wrap

      oc describe 명령의 출력

      Name:         allow-same-namespace
Namespace:    ns1
Created on:   2021-05-24 22:28:56 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      PodSelector: <none>
  Not affecting egress traffic
  Policy Types: Ingress
      Copy to Clipboard Toggle word wrap

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하는 경우 YAML 또는 웹 콘솔의 양식에서 클러스터의 모든 네임스페이스에서 네트워크 정책을 직접 볼 수 있습니다.

3.4. 네트워크 정책 편집
링크 복사

관리자 역할이 있는 사용자는 네임스페이스에 대한 기존 네트워크 정책을 편집할 수 있습니다.

3.4.1. 네트워크 정책 편집
링크 복사

네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 편집할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 선택 사항: 네임스페이스의 네트워크 정책 개체를 나열하려면 다음 명령을 입력합니다. 

    $ oc get networkpolicy
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

  2. 네트워크 정책 오브젝트를 편집합니다.

    • 네트워크 정책 정의를 파일에 저장한 경우 파일을 편집하고 필요한 사항을 변경한 후 다음 명령을 입력합니다. 

      $ oc apply -n <namespace> -f <policy_file>.yaml
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
      <policy_file>
      네트워크 정책이 포함된 파일의 이름을 지정합니다.

    • 네트워크 정책 개체를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다. 

      $ oc edit networkpolicy <policy_name> -n <namespace>
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      <policy_name>
      네트워크 정책의 이름을 지정합니다.
      <namespace>
      선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.

  3. 네트워크 정책 개체가 업데이트되었는지 확인합니다. 

    $ oc describe networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <policy_name>
    네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하는 경우 Actions 메뉴를 통해 클러스터의 모든 네임스페이스에서 직접 또는 웹 콘솔의 정책에서 네트워크 정책을 편집할 수 있습니다.

3.4.2. NetworkPolicy 오브젝트 예
링크 복사

다음은 예제 NetworkPolicy 오브젝트에 대한 주석입니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
1 

spec:
  podSelector:
2 

    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
3 

        matchLabels:
          app: app
    ports:
4 

    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap
1
NetworkPolicy 오브젝트의 이름입니다.
2
정책이 적용되는 Pod를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트를 정의하는 프로젝트에서 Pod만 선택할 수 있습니다.
3
정책 오브젝트가 수신 트래픽을 허용하는 Pod와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스의 Pod와 일치합니다.
4
트래픽을 허용할 하나 이상의 대상 포트 목록입니다.

3.5. 네트워크 정책 삭제
링크 복사

admin 역할이 있는 사용자는 네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

3.5.1. CLI를 사용하여 네트워크 정책 삭제
링크 복사

네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

참고

cluster-admin 역할을 가진 사용자로 로그인하면 클러스터의 모든 네트워크 정책을 삭제할 수 있습니다.

사전 요구 사항

  • 클러스터는 mode: NetworkPolicy 로 설정된 OVN-Kubernetes 네트워크 플러그인과 같은 NetworkPolicy 오브젝트를 지원하는 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • 네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

  • 네트워크 정책 오브젝트를 삭제하려면 다음 명령을 입력합니다. 성공적인 출력에는 정책 오브젝트의 이름과 삭제된 상태가 나열됩니다. 

    $ oc delete networkpolicy <policy_name> -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <policy_name>
    네트워크 정책의 이름을 지정합니다.
    <namespace>
    선택적 매개변수입니다. 현재 네임스페이스와 다른 네임스페이스에 오브젝트를 정의한 경우 매개변수는 네임스페이스를 지정합니다.

    성공적인 출력에는 정책 오브젝트의 이름과 삭제된 상태가 나열됩니다.

참고

cluster-admin 권한을 사용하여 웹 콘솔에 로그인하는 경우, YAML에서 직접 또는 Actions 메뉴를 통해 웹 콘솔의 정책에서 클러스터의 모든 네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

3.6. 프로젝트의 기본 네트워크 정책 정의
링크 복사

클러스터 관리자는 새 프로젝트를 만들 때 네트워크 정책을 자동으로 포함하도록 새 프로젝트 템플릿을 수정할 수 있습니다. 새 프로젝트에 대한 사용자 정의 템플릿이 아직 없는 경우에는 우선 생성해야 합니다.

3.6.1. 새 프로젝트의 템플릿 수정
링크 복사

클러스터 관리자는 사용자 정의 요구 사항을 사용하여 새 프로젝트를 생성하도록 기본 프로젝트 템플릿을 수정할 수 있습니다.

사용자 정의 프로젝트 템플릿을 만들려면:

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

프로세스

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

  2. 기본 프로젝트 템플릿을 생성합니다. 

    $ oc adm create-bootstrap-project-template -o yaml > template.yaml
    Copy to Clipboard Toggle word wrap
  3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.

  4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다. 

    $ oc create -f template.yaml -n openshift-config
    Copy to Clipboard Toggle word wrap

  5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

    • 웹 콘솔에 액세스:

      1. 관리 → 클러스터 설정으로 이동합니다.
      2. 구성 을 클릭하여 모든 구성 리소스를 확인합니다.
      3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.

    • CLI 사용:

      1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다. 

        $ oc edit project.config.openshift.io/cluster
        Copy to Clipboard Toggle word wrap

  6. projectRequestTemplate 및 name 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

    사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

    apiVersion: config.openshift.io/v1
kind: Project
metadata:
# ...
spec:
  projectRequestTemplate:
    name: <template_name>
# ...
    Copy to Clipboard Toggle word wrap

  7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

3.6.2. 새 프로젝트 템플릿에 네트워크 정책 추가
링크 복사

클러스터 관리자는 네트워크 정책을 새 프로젝트의 기본 템플릿에 추가할 수 있습니다. OpenShift Container Platform은 프로젝트의 템플릿에 지정된 모든 NetworkPolicy 개체를 자동으로 생성합니다.

사전 요구 사항

  • 클러스터는 OVN-Kubernetes와 같은 NetworkPolicy 오브젝트를 지원하는 기본 컨테이너 네트워크 인터페이스(CNI) 네트워크 플러그인을 사용합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인해야 합니다.
  • 새 프로젝트에 대한 사용자 정의 기본 프로젝트 템플릿을 생성해야 합니다.

프로세스

  1. 다음 명령을 실행하여 새 프로젝트의 기본 템플릿을 편집합니다. 

    $ oc edit template <project_template> -n openshift-config
    Copy to Clipboard Toggle word wrap

    <project_template>을 클러스터에 대해 구성한 기본 템플릿의 이름으로 변경합니다. 기본 템플릿 이름은 project-request입니다.

  2. 템플릿에서 각 NetworkPolicy 오브젝트를 objects 매개변수의 요소로 추가합니다. objects 매개변수는 하나 이상의 오브젝트 컬렉션을 허용합니다.

    다음 예제에서 objects 매개변수 컬렉션에는 여러 NetworkPolicy 오브젝트가 포함됩니다. 

    objects:
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            policy-group.network.openshift.io/ingress:
    podSelector: {}
    policyTypes:
    - Ingress
- apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-kube-apiserver-operator
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: openshift-kube-apiserver-operator
        podSelector:
          matchLabels:
            app: kube-apiserver-operator
    policyTypes:
    - Ingress
...
    Copy to Clipboard Toggle word wrap

  3. 선택 사항: 새 프로젝트를 생성하고 네트워크 정책 오브젝트가 성공적으로 생성되었는지 확인합니다.

    1. 새 프로젝트를 생성합니다. 

      $ oc new-project <project>
      1
      Copy to Clipboard Toggle word wrap
      1
      <project> 를 생성중인 프로젝트의 이름으로 변경합니다.

    2. 새 프로젝트 템플릿의 네트워크 정책 오브젝트가 새 프로젝트에 있는지 확인합니다. 

      $ oc get networkpolicy
      Copy to Clipboard Toggle word wrap

      예상 출력: 

      NAME                           POD-SELECTOR   AGE
allow-from-openshift-ingress   <none>         7s
allow-from-same-namespace      <none>         7s
      Copy to Clipboard Toggle word wrap

3.7. 네트워크 정책으로 다중 테넌트 격리 구성
링크 복사

클러스터 관리자는 다중 테넌트 네트워크 격리를 제공하도록 네트워크 정책을 구성할 수 있습니다.

참고

이 섹션에 설명된 대로 네트워크 정책을 구성하면 이전 버전의 OpenShift Container Platform에서 OpenShift SDN의 다중 테넌트 모드와 유사한 네트워크 격리가 제공됩니다.

3.7.1. 네트워크 정책을 사용하여 다중 테넌트 격리 구성
링크 복사

다른 프로젝트 네임스페이스의 Pod 및 서비스에서 격리하도록 프로젝트를 구성할 수 있습니다.

사전 요구 사항

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

프로세스

  1. 다음 NetworkPolicy 오브젝트를 생성합니다.

    1. 이름이 allow-from-openshift-ingress인 정책입니다. 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          policy-group.network.openshift.io/ingress: ""
  podSelector: {}
  policyTypes:
  - Ingress
EOF
      Copy to Clipboard Toggle word wrap
      참고

      policy-group.network.openshift.io/ingress: "" 는 OVN-Kubernetes의 기본 네임스페이스 선택기 레이블입니다.

    2. 이름이 allow-from-openshift-monitoring인 정책: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress
EOF
      Copy to Clipboard Toggle word wrap

    3. 이름이 allow-same-namespace인 정책: 

      $ cat << EOF| oc create -f -
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector:
  ingress:
  - from:
    - podSelector: {}
EOF
      Copy to Clipboard Toggle word wrap

    4. 이름이 allow-from-kube-apiserver-operator 인 정책: 

      $ cat << EOF| oc create -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-kube-apiserver-operator
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: openshift-kube-apiserver-operator
      podSelector:
        matchLabels:
          app: kube-apiserver-operator
  policyTypes:
  - Ingress
EOF
      Copy to Clipboard Toggle word wrap

      자세한 내용은 웹 후크 의 상태를 검증하는 새로운 kube-apiserver-operator 웹 후크 컨트롤러를 참조하십시오.

  2. 선택 사항: 현재 프로젝트에 네트워크 정책이 있는지 확인하려면 다음 명령을 입력합니다. 

    $ oc describe networkpolicy
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:         allow-from-openshift-ingress
Namespace:    example1
Created on:   2020-06-09 00:28:17 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: policy-group.network.openshift.io/ingress:
  Not affecting egress traffic
  Policy Types: Ingress


Name:         allow-from-openshift-monitoring
Namespace:    example1
Created on:   2020-06-09 00:29:57 -0400 EDT
Labels:       <none>
Annotations:  <none>
Spec:
  PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
  Allowing ingress traffic:
    To Port: <any> (traffic allowed to all ports)
    From:
      NamespaceSelector: network.openshift.io/policy-group: monitoring
  Not affecting egress traffic
  Policy Types: Ingress
    Copy to Clipboard Toggle word wrap

3.7.2. 다음 단계
링크 복사

4장. 네트워크 보안을 위한 감사 로깅
링크 복사

OVN-Kubernetes 네트워크 플러그인은 OVN(Open Virtual Network) 액세스 제어 목록(ACL)을 사용하여 AdminNetworkPolicy,BaselineAdminNetworkPolicy,NetworkPolicy, EgressFirewall 오브젝트를 관리합니다. 감사 로깅은 NetworkPolicy ,EgressFirewall 및 BaselineAdmin NetworkPolicy 사용자 정의 리소스(CR)에 대한 ACL 이벤트를 허용 및 거부합니다. 로깅은 관리NetworkPolicy (ANP) CR에 대한 ACL 이벤트도 노출하고,거부할 수 있습니다.

참고

감사 로깅은 OVN-Kubernetes 네트워크 플러그인 에서만 사용할 수 있습니다.

4.1. 감사 구성
링크 복사

감사 로깅 구성은 OVN-Kubernetes 클러스터 네트워크 공급자 구성의 일부로 지정됩니다. 다음 YAML은 감사 로깅의 기본값을 보여줍니다.

감사 로깅 구성

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0
Copy to Clipboard Toggle word wrap

다음 표에서는 감사 로깅을 위한 구성 필드를 설명합니다.

Expand
표 4.1. policyAuditConfig 오브젝트
필드유형설명

rateLimit

integer

노드당 1초마다 생성할 최대 메시지 수입니다. 기본값은 초당 20 개의 메시지입니다.

maxFileSize

integer

감사 로그의 최대 크기(바이트)입니다. 기본값은 50000000 또는 50MB입니다.

maxLogFiles

integer

유지되는 최대 로그 파일 수입니다.

대상

string

다음 추가 감사 로그 대상 중 하나입니다.

libc
호스트에서 journald 프로세스의 libc syslog() 함수입니다.
udp:<host>:<port>
syslog 서버입니다. <host>:<port>를 syslog 서버의 호스트 및 포트로 바꿉니다.
unix:<file>
<file>로 지정된 Unix Domain Socket 파일입니다.
null
감사 로그를 추가 대상으로 보내지 마십시오.

syslogFacility

string

RFC5424에 정의된 kern과 같은 syslog 기능입니다. 기본값은 local0입니다.

4.2. 감사 로깅
링크 복사

syslog 서버 또는 UNIX 도메인 소켓과 같은 감사 로그의 대상을 구성할 수 있습니다. 추가 구성에 관계없이 감사 로그는 항상 클러스터의 각 OVN-Kubernetes Pod의 /var/log/ovn/acl-audit-log.log에 저장됩니다.

k8s.ovn.org/acl-logging 섹션을 사용하여 각 네임스페이스 구성에 주석을 달아 각 네임스페이스에 대해 감사 로깅을 활성화할 수 있습니다. k8s.ovn.org/acl-logging 섹션에서 네임스페이스에 대한 감사 로깅을 활성화하려면 allow,deny 또는 두 값을 지정해야 합니다.

참고

네트워크 정책은 Pass 작업 세트를 규칙으로 설정하는 것을 지원하지 않습니다.

ACL-logging 구현에서는 네트워크에 대한 ACL(액세스 제어 목록) 이벤트를 기록합니다. 이러한 로그를 보고 잠재적인 보안 문제를 분석할 수 있습니다.

네임스페이스 주석의 예

kind: Namespace
apiVersion: v1
metadata:
  name: example1
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "info",
        "allow": "info"
      }
Copy to Clipboard Toggle word wrap

기본 ACL 로깅 구성 값을 보려면 cluster-network-03-config.yml 파일의 policyAuditConfig 오브젝트를 참조하십시오. 필요한 경우 이 파일에서 로그 파일 매개변수에 대한 ACL 로깅 구성 값을 변경할 수 있습니다.

로깅 메시지 형식은 RFC5424에 정의된 대로 syslog와 호환됩니다. syslog 기능은 구성 가능하며 기본값은 local0입니다. 다음 예제에서는 로그 메시지에 출력된 주요 매개변수 및 해당 값을 보여줍니다.

매개변수 및 해당 값을 출력하는 로깅 메시지의 예

<timestamp>|<message_serial>|acl_log(ovn_pinctrl0)|<severity>|name="<acl_name>", verdict="<verdict>", severity="<severity>", direction="<direction>": <flow>
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • <timestamp >는 로그 메시지 생성 시간 및 날짜를 지정합니다.
  • <message_serial >은 로그 메시지의 일련 번호를 나열합니다.
  • acl_log(ovn_pinctrl0) 는 OVN-Kubernetes 플러그인에 로그 메시지의 위치를 출력하는 리터럴 문자열입니다.
  • <severity >는 로그 메시지의 심각도 수준을 설정합니다. allow 및 deny 작업을 지원하는 감사 로깅을 활성화하면 두 가지 심각도 수준이 로그 메시지 출력에 표시됩니다.
  • < name>은 네트워크 정책에서 생성된 OVN 네트워크 브리징 데이터베이스(nbdb)에 ACL-logging 구현의 이름을 지정합니다.
  • <verdict& gt;는 허용 또는 드롭 일 수 있습니다.
  • <direction >은 to-lport 또는 from-lport 중 하나로, Pod에서 나가는 트래픽에 정책이 적용되었음을 나타냅니다.
  • <flow >는 OpenFlow 프로토콜과 동일한 형식으로 패킷 정보를 표시합니다. 이 매개변수는 OVS(Open vSwitch) 필드로 구성됩니다.

다음 예제에서는 flow 매개변수가 시스템 메모리에서 패킷 정보를 추출하는 데 사용하는 OVS 필드를 보여줍니다.

패킷 정보를 추출하기 위해 flow 매개변수에서 사용하는 OVS 필드의 예

<proto>,vlan_tci=0x0000,dl_src=<src_mac>,dl_dst=<source_mac>,nw_src=<source_ip>,nw_dst=<target_ip>,nw_tos=<tos_dscp>,nw_ecn=<tos_ecn>,nw_ttl=<ip_ttl>,nw_frag=<fragment>,tp_src=<tcp_src_port>,tp_dst=<tcp_dst_port>,tcp_flags=<tcp_flags>
Copy to Clipboard Toggle word wrap

다음과 같습니다.

  • & lt;proto& gt;는 프로토콜을 표시합니다. 유효한 값은 tcp 및 udp 입니다.
  • VLAN ID가 내부 Pod 네트워크 트래픽에 설정되지 않았기 때문에 vlan_tci=0x0000 은 VLAN 헤더를 0 으로 지정합니다.
  • <src_mac >는 MAC(Media Access Control) 주소의 소스를 지정합니다.
  • <source_mac& gt;는 MAC 주소의 대상을 지정합니다.
  • <SOURCE_IP& gt;는 소스 IP 주소 나열
  • <target_ip& gt;는 대상 IP 주소를 나열합니다.
  • < tos_dscp >는 다른 트래픽보다 특정 네트워크 트래픽을 분류하고 우선 순위를 지정할 수 있는 다양한 서비스 코드 포인트(DSCP) 값을 나타냅니다.
  • <tos_ecn >은 네트워크에서 혼잡한 트래픽을 나타내는 ECN(Explicit Congestion Notification) 값을 나타냅니다.
  • <ip_ttl >은 패킷에 대한 TTP(Time To Live) 정보를 표시합니다.
  • <fragment >는 일치시킬 IP 조각 또는 IP의 유형을 지정합니다.
  • <tcp_src_port >는 TCP 및 UDP 프로토콜의 포트 소스를 보여줍니다.
  • <tcp_dst_port >는 TCP 및 UDP 프로토콜의 대상 포트를 나열합니다.
  • <tcp_flags >는 SYN,ACK,PSH 등과 같은 다양한 플래그를 지원합니다. 여러 값을 설정해야 하는 경우 각 값은 세로 막대(|)로 구분됩니다. UDP 프로토콜은 이 매개변수를 지원하지 않습니다.
참고

이전 필드 설명에 대한 자세한 내용은 ovs-fields 의 OVS 매뉴얼 페이지로 이동하십시오.

네트워크 정책에 대한 ACL 거부 로그 항목의 예

2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
Copy to Clipboard Toggle word wrap

다음 표에서는 네임스페이스 주석 값에 대해 설명합니다.

Expand
표 4.2. k8s.ovn.org/acl-logging에 대한 감사 로깅 네임스페이스 주석
필드설명

deny

거부 작업과 함께 ACL 규칙과 일치하는 모든 트래픽에 대한 네임스페이스 액세스를 차단합니다. 필드는 경고,warning,notice,info 또는 debug 값을 지원합니다.

allow

허용 작업과 함께 ACL 규칙과 일치하는 모든 트래픽에 대한 네임스페이스 액세스를 허용합니다. 필드는 경고,warning,notice,info 또는 debug 값을 지원합니다.

통과

pass 작업은 admin 네트워크 정책의 ACL 규칙에 적용됩니다. pass 작업을 사용하면 네임스페이스의 네트워크 정책 또는 기본 관리자 네트워크 정책 규칙을 사용하여 들어오고 나가는 모든 트래픽을 평가할 수 있습니다. 네트워크 정책은 통과 작업을 지원하지 않습니다.

4.3. AdminNetworkPolicy 감사 로깅
링크 복사

다음 예와 같이 k8s.ovn.org/acl-logging 키로 ANP 정책에 주석을 달아 AdminNetworkPolicy CR별로 감사 로깅이 활성화됩니다.

예 4.1. AdminNetworkPolicy CR 주석의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: AdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert", "pass" : "warning" }'
  name: anp-tenant-log
spec:
  priority: 5
  subject:
    namespaces:
      matchLabels:
        tenant: backend-storage # Selects all pods owned by storage tenant.
  ingress:
    - name: "allow-all-ingress-product-development-and-customer" # Product development and customer tenant ingress to backend storage.
      action: "Allow"
      from:
      - pods:
          namespaceSelector:
            matchExpressions:
            - key: tenant
              operator: In
              values:
              - product-development
              - customer
          podSelector: {}
    - name: "pass-all-ingress-product-security"
      action: "Pass"
      from:
      - namespaces:
          matchLabels:
              tenant: product-security
    - name: "deny-all-ingress" # Ingress to backend from all other pods in the cluster.
      action: "Deny"
      from:
      - namespaces: {}
  egress:
    - name: "allow-all-egress-product-development"
      action: "Allow"
      to:
      - pods:
          namespaceSelector:
            matchLabels:
              tenant: product-development
          podSelector: {}
    - name: "pass-egress-product-security"
      action: "Pass"
      to:
      - namespaces:
           matchLabels:
             tenant: product-security
    - name: "deny-all-egress" # Egress from backend denied to all other pods.
      action: "Deny"
      to:
      - namespaces: {}
Copy to Clipboard Toggle word wrap

특정 OVN ACL에 도달할 때마다 로그가 생성되고 로깅 주석에 설정된 작업 기준을 충족합니다. 예를 들어 테넌트: product-devel이라는 라벨이 있는 네임스페이스 중 하나라도 backend- storage 라는 레이블이 있는 네임스페이스에 액세스하는 경우 로그가 생성됩니다.

참고

ACL 로깅은 60자로 제한됩니다. ANP 이름 필드가 길면 나머지 로그가 잘립니다.

다음은 다음 예제 로그 항목에 대한 방향 인덱스입니다.

Expand
방향Rule

Ingress

Rule0
테넌트 제품 개발 및 고객 에서 테넌트 backend-storage; Ingress0: 허용
Rule1
product-security'에서 'backend-storage ; Ingress1: Pass로 전달
Rule2
모든 Pod의 수신 거부; Ingress2: Deny

Egress

Rule0
제품 개발 허용; Egress0: 허용
Rule1
product-security; Egress1: Pass로 전달
Rule2
다른 모든 pod로의 송신 거부; Egress2: Deny

예 4.2. Ingress:0 및 Egress:0을 사용하여 anp-tenant-log 라는 AdminNetworkPolicy 작업의 허용 로그 항목의 예

2024-06-10T16:27:45.194Z|00052|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1a,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.26,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=57814,tp_dst=8080,tcp_flags=syn
2024-06-10T16:28:23.130Z|00059|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:18,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.24,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=38620,tp_dst=8080,tcp_flags=ack
2024-06-10T16:28:38.293Z|00069|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:0", verdict=allow, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1a,nw_src=10.128.2.25,nw_dst=10.128.2.26,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=47566,tp_dst=8080,tcp_flags=fin|ack=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=55704,tp_dst=8080,tcp_flags=ack
Copy to Clipboard Toggle word wrap

예 4.3. Ingress:1 및 Egress:1을 사용하여 anp-tenant-log 라는 AdminNetworkPolicy 동작에 대한 ACL 로그 항목의 예 

2024-06-10T16:33:12.019Z|00075|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:1", verdict=pass, severity=warning, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1b,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.27,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=37394,tp_dst=8080,tcp_flags=ack
2024-06-10T16:35:04.209Z|00081|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:1", verdict=pass, severity=warning, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:1b,nw_src=10.128.2.25,nw_dst=10.128.2.27,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=34018,tp_dst=8080,tcp_flags=ack
Copy to Clipboard Toggle word wrap

예 4.4. Egress:2 및 Ingress2를 사용하여 anp-tenant-log 라는 AdminNetworkPolicy 작업의 거부 작업의 예

2024-06-10T16:43:05.287Z|00087|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Egress:2", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:19,dl_dst=0a:58:0a:80:02:18,nw_src=10.128.2.25,nw_dst=10.128.2.24,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=51598,tp_dst=8080,tcp_flags=syn
2024-06-10T16:44:43.591Z|00090|acl_log(ovn_pinctrl0)|INFO|name="ANP:anp-tenant-log:Ingress:2", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:80:02:1c,dl_dst=0a:58:0a:80:02:19,nw_src=10.128.2.28,nw_dst=10.128.2.25,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=33774,tp_dst=8080,tcp_flags=syn
Copy to Clipboard Toggle word wrap

다음 표에서는 ANP 주석을 설명합니다.

Expand
표 4.3. 감사 로깅 관리NetworkPolicy 주석
주석현재의

k8s.ovn.org/acl-logging

네임스페이스에 대한 감사 로깅을 활성화하려면 허용,거부 또는 Pass 중 하나 이상을 지정해야 합니다.

거부
선택 사항: alert, warning, notice, info, debug를 지정합니다.
허용
선택 사항: alert, warning, notice, info, debug를 지정합니다.
통과
선택 사항: alert, warning, notice, info, debug를 지정합니다.

4.4. BaselineAdminNetworkPolicy 감사 로깅
링크 복사

다음 예와 같이 k8s.ovn.org/acl-logging 키로 BANP 정책에 주석을 달아 BaselineAdminNetworkPolicy CR에서 감사 로깅이 활성화됩니다.

예 4.5. BaselineAdminNetworkPolicy CR 주석의 예

apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert"}'
  name: default
spec:
  subject:
    namespaces:
      matchLabels:
          tenant: workloads # Selects all workload pods in the cluster.
  ingress:
  - name: "default-allow-dns" # This rule allows ingress from dns tenant to all workloads.
    action: "Allow"
    from:
    - namespaces:
          matchLabels:
            tenant: dns
  - name: "default-deny-dns" # This rule denies all ingress from all pods to workloads.
    action: "Deny"
    from:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
  egress:
  - name: "default-deny-dns" # This rule denies all egress from workloads. It will be applied when no ANP or network policy matches.
    action: "Deny"
    to:
    - namespaces: {} # Use the empty selector with caution because it also selects OpenShift namespaces as well.
Copy to Clipboard Toggle word wrap

이 예제에서는 tenant: dns 레이블이 있는 네임스페이스 중 하나에 tenant: workloads 라는 레이블이 있는 네임스페이스에 액세스하는 경우 로그가 생성됩니다.

다음은 다음 예제 로그 항목에 대한 방향 인덱스입니다.

Expand
방향Rule

Ingress

Rule0
테넌트 dns 에서 테넌트 워크로드; Ingress0: Allow로 허용
Rule1
모든 Pod의 테넌트 워크로드 거부; Ingress1: Deny

Egress

Rule0
모든 pod에 대해 거부; Egress0: Deny

예 4.6. ACL의 예는 Ingress:0을 사용하여 기본 BANP의 허용 작업에 대한 로그 항목을 허용합니다.

2024-06-10T18:11:58.263Z|00022|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=syn
2024-06-10T18:11:58.264Z|00023|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=psh|ack
2024-06-10T18:11:58.264Z|00024|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00025|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
2024-06-10T18:11:58.264Z|00026|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=fin|ack
2024-06-10T18:11:58.264Z|00027|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:0", verdict=allow, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:57,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.87,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=60510,tp_dst=8080,tcp_flags=ack
Copy to Clipboard Toggle word wrap

예 4.7. ACL의 예는 Egress:0 및 Ingress:1이 있는 기본 BANP의 허용 작업에 대한 로그 항목을 허용합니다.

2024-06-10T18:09:57.774Z|00016|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:09:58.809Z|00017|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:00.857Z|00018|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Egress:0", verdict=drop, severity=alert, direction=from-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:56,dl_dst=0a:58:0a:82:02:57,nw_src=10.130.2.86,nw_dst=10.130.2.87,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=45614,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:25.414Z|00019|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:26.457Z|00020|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
2024-06-10T18:10:28.505Z|00021|acl_log(ovn_pinctrl0)|INFO|name="BANP:default:Ingress:1", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:82:02:58,dl_dst=0a:58:0a:82:02:56,nw_src=10.130.2.88,nw_dst=10.130.2.86,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=40630,tp_dst=8080,tcp_flags=syn
Copy to Clipboard Toggle word wrap

다음 표에서는 BANP 주석을 설명합니다.

Expand
표 4.4. 감사 로깅 BaselineAdminNetworkPolicy 주석
주석현재의

k8s.ovn.org/acl-logging

네임스페이스에 대한 감사 로깅을 활성화하려면 허용 또는 거부 중 하나를 지정해야 합니다.

거부
선택 사항: alert, warning, notice, info, debug를 지정합니다.
허용
선택 사항: alert, warning, notice, info, debug를 지정합니다.

4.5. 클러스터에 대한 송신 방화벽 및 네트워크 정책 감사 구성
링크 복사

클러스터 관리자는 클러스터의 감사 로깅을 사용자 지정할 수 있습니다.

사전 요구 사항

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

프로세스

  • 감사 로깅 구성을 사용자 지정하려면 다음 명령을 입력합니다. 

    $ oc edit network.operator.openshift.io/cluster
    Copy to Clipboard Toggle word wrap
    작은 정보

    다음 YAML을 사용자 지정하고 적용하여 감사 로깅을 구성할 수도 있습니다. 

    apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      policyAuditConfig:
        destination: "null"
        maxFileSize: 50
        rateLimit: 20
        syslogFacility: local0
    Copy to Clipboard Toggle word wrap

검증

  1. 네트워크 정책을 사용하여 네임스페이스를 생성하려면 다음 단계를 완료합니다.

    1. 검증을 위해 네임스페이스를 생성합니다. 

      $ cat <<EOF| oc create -f -
kind: Namespace
apiVersion: v1
metadata:
  name: verify-audit-logging
  annotations:
    k8s.ovn.org/acl-logging: '{ "deny": "alert", "allow": "alert" }'
EOF
      Copy to Clipboard Toggle word wrap

      출력에 네트워크 정책 및 생성된 상태가 포함된 네임스페이스가 나열됩니다.

    2. 네임스페이스의 네트워크 정책을 생성합니다. 

      $ cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector:
    matchLabels:
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-same-namespace
  namespace: verify-audit-logging
spec:
  podSelector: {}
  policyTypes:
   - Ingress
   - Egress
  ingress:
    - from:
        - podSelector: {}
  egress:
    - to:
       - namespaceSelector:
          matchLabels:
            kubernetes.io/metadata.name: verify-audit-logging
EOF
      Copy to Clipboard Toggle word wrap

      출력 예

      networkpolicy.networking.k8s.io/deny-all created
networkpolicy.networking.k8s.io/allow-from-same-namespace created
      Copy to Clipboard Toggle word wrap

  2. default 네임스페이스에서 소스 트래픽에 사용할 Pod를 생성합니다. 

    $ cat <<EOF| oc create -n default -f -
apiVersion: v1
kind: Pod
metadata:
  name: client
spec:
  containers:
    - name: client
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
    Copy to Clipboard Toggle word wrap

  3. verify-audit-logging 네임스페이스에 두 개의 Pod를 생성합니다. 

    $ for name in client server; do
cat <<EOF| oc create -n verify-audit-logging -f -
apiVersion: v1
kind: Pod
metadata:
  name: ${name}
spec:
  containers:
    - name: ${name}
      image: registry.access.redhat.com/rhel7/rhel-tools
      command: ["/bin/sh", "-c"]
      args:
        ["sleep inf"]
EOF
done
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 pod/client 및 pod/server 와 같은 두 Pod와 생성된 상태가 나열됩니다.

  4. 트래픽을 생성하고 네트워크 정책 감사 로그 항목을 생성하려면 다음 단계를 완료합니다.

    1. verify-audit-logging 네임스페이스에서 server라는 Pod의 IP 주소를 가져옵니다. 

      $ POD_IP=$(oc get pods server -n verify-audit-logging -o jsonpath='{.status.podIP}')
      Copy to Clipboard Toggle word wrap

    2. default 네임스페이스의 client 라는 Pod에서 이전 명령의 IP 주소를 ping하고 모든 패킷이 삭제되었는지 확인합니다. 

      $ oc exec -it client -n default -- /bin/ping -c 2 $POD_IP
      Copy to Clipboard Toggle word wrap

      출력 예

      PING 10.128.2.55 (10.128.2.55) 56(84) bytes of data.

--- 10.128.2.55 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 2041ms
      Copy to Clipboard Toggle word wrap

    3. verify-audit-logging 네임스페이스의 클라이언트 Pod에서 POD_IP 쉘 환경 변수에 저장된 IP 주소를 ping하고 시스템에서 모든 패킷을 허용하는지 확인합니다. 

      $ oc exec -it client -n verify-audit-logging -- /bin/ping -c 2 $POD_IP
      Copy to Clipboard Toggle word wrap

      출력 예

      PING 10.128.0.86 (10.128.0.86) 56(84) bytes of data.
64 bytes from 10.128.0.86: icmp_seq=1 ttl=64 time=2.21 ms
64 bytes from 10.128.0.86: icmp_seq=2 ttl=64 time=0.440 ms

--- 10.128.0.86 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.440/1.329/2.219/0.890 ms
      Copy to Clipboard Toggle word wrap

  5. 네트워크 정책 감사 로그의 최신 항목을 표시합니다. 

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done
    Copy to Clipboard Toggle word wrap

    출력 예

    2023-11-02T16:28:54.139Z|00004|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:55.187Z|00005|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:28:57.235Z|00006|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:Ingress", verdict=drop, severity=alert, direction=to-lport: tcp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:01,dl_dst=0a:58:0a:81:02:23,nw_src=10.131.0.39,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=62,nw_frag=no,tp_src=58496,tp_dst=8080,tcp_flags=syn
2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
    Copy to Clipboard Toggle word wrap

클러스터 관리자는 네임스페이스에 대한 감사 로깅을 활성화할 수 있습니다.

사전 요구 사항

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

프로세스

  • 네임스페이스에 대한 감사 로깅을 활성화하려면 다음 명령을 입력합니다. 

    $ oc annotate namespace <namespace> \
  k8s.ovn.org/acl-logging='{ "deny": "alert", "allow": "notice" }'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <namespace>
    네임스페이스의 이름을 지정합니다.
    작은 정보

    다음 YAML을 적용하여 감사 로깅을 활성화할 수도 있습니다. 

    kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: |-
      {
        "deny": "alert",
        "allow": "notice"
      }
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 감사 로깅 이름과 주석이 추가된 상태가 나열됩니다.

검증

  • 감사 로그의 최신 항목을 표시합니다. 

    $ for pod in $(oc get pods -n openshift-ovn-kubernetes -l app=ovnkube-node --no-headers=true | awk '{ print $1 }') ; do
    oc exec -it $pod -n openshift-ovn-kubernetes -- tail -4 /var/log/ovn/acl-audit-log.log
  done
    Copy to Clipboard Toggle word wrap

    출력 예

    2023-11-02T16:49:57.909Z|00028|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:57.909Z|00029|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00030|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Egress:0", verdict=allow, severity=alert, direction=from-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
2023-11-02T16:49:58.932Z|00031|acl_log(ovn_pinctrl0)|INFO|name="NP:verify-audit-logging:allow-from-same-namespace:Ingress:0", verdict=allow, severity=alert, direction=to-lport: icmp,vlan_tci=0x0000,dl_src=0a:58:0a:81:02:22,dl_dst=0a:58:0a:81:02:23,nw_src=10.129.2.34,nw_dst=10.129.2.35,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,icmp_type=8,icmp_code=0
    Copy to Clipboard Toggle word wrap

클러스터 관리자는 네임스페이스에 대한 감사 로깅을 비활성화할 수 있습니다.

사전 요구 사항

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

프로세스

  • 네임스페이스에 대한 감사 로깅을 비활성화하려면 다음 명령을 입력합니다. 

    $ oc annotate --overwrite namespace <namespace> k8s.ovn.org/acl-logging-
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <namespace>
    네임스페이스의 이름을 지정합니다.
    작은 정보

    다음 YAML을 적용하여 감사 로깅을 비활성화할 수도 있습니다. 

    kind: Namespace
apiVersion: v1
metadata:
  name: <namespace>
  annotations:
    k8s.ovn.org/acl-logging: null
    Copy to Clipboard Toggle word wrap

    성공적인 출력에는 감사 로깅 이름과 주석이 추가된 상태가 나열됩니다.

5장. 송신 방화벽
링크 복사

5.1. 프로젝트의 송신 방화벽 보기
링크 복사

클러스터 관리자는 기존 송신 방화벽의 이름을 나열하고 특정 송신 방화벽에 대한 트래픽 규칙을 볼 수 있습니다.

5.1.1. EgressFirewall 오브젝트 보기
링크 복사

클러스터의 EgressFirewall 오브젝트를 볼 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • oc로 알려진 OpenShift 명령 인터페이스 (CLI)를 설치합니다.
  • 클러스터에 로그인해야 합니다.

프로세스

  1. 선택사항: 클러스터에 정의된 EgressFirewall 오브젝트의 이름을 보려면 다음 명령을 입력합니다. 

    $ oc get egressfirewall --all-namespaces
    Copy to Clipboard Toggle word wrap

  2. 정책을 검사하려면 다음 명령을 입력하십시오. <policy_name>을 검사할 정책 이름으로 교체합니다. 

    $ oc describe egressfirewall <policy_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:		default
Namespace:	project1
Created:	20 minutes ago
Labels:		<none>
Annotations:	<none>
Rule:		Allow to 1.2.3.0/24
Rule:		Allow to www.example.com
Rule:		Deny to 0.0.0.0/0
    Copy to Clipboard Toggle word wrap

5.2. 프로젝트의 송신 방화벽 편집
링크 복사

클러스터 관리자는 기존 송신 방화벽에 대한 네트워크 트래픽 규칙을 수정할 수 있습니다.

5.2.1. EgressFirewall 오브젝트 편집
링크 복사

클러스터 관리자는 프로젝트의 송신 방화벽을 업데이트할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다. 

    $ oc get -n <project> egressfirewall
    Copy to Clipboard Toggle word wrap

  2. 선택 사항: 송신 네트워크 방화벽을 만들 때 EgressFirewall 오브젝트의 사본을 저장하지 않은 경우 다음 명령을 입력하여 사본을 생성합니다. 

    $ oc get -n <project> egressfirewall <name> -o yaml > <filename>.yaml
    Copy to Clipboard Toggle word wrap

    <project>를 프로젝트 이름으로 바꿉니다. <name>을 오브젝트 이름으로 변경합니다. YAML을 저장할 파일의 이름으로 <filename>을 바꿉니다.

  3. 정책 규칙을 변경한 후 다음 명령을 입력하여 EgressFirewall 오브젝트를 바꿉니다. 업데이트된 EgressFirewall 오브젝트가 포함된 파일 이름으로 <filename>을 바꿉니다. 

    $ oc replace -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

5.3. 프로젝트에서 송신 방화벽 제거
링크 복사

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거하여 OpenShift Container Platform 클러스터를 나가는 프로젝트에서 네트워크 트래픽에 대한 모든 제한을 제거할 수 있습니다.

5.3.1. EgressFirewall 오브젝트 제거
링크 복사

클러스터 관리자는 프로젝트에서 송신 방화벽을 제거할 수 있습니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 프로젝트의 EgressFirewall 오브젝트 이름을 찾습니다. <project>를 프로젝트 이름으로 바꿉니다. 

    $ oc get -n <project> egressfirewall
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 입력하여 EgressFirewall 오브젝트를 삭제합니다. <project>를 프로젝트 이름으로 바꾸고 <name>을 오브젝트 이름으로 바꿉니다. 

    $ oc delete -n <project> egressfirewall <name>
    Copy to Clipboard Toggle word wrap

5.4. 프로젝트에 대한 송신 방화벽 구성
링크 복사

클러스터 관리자는 OpenShift Container Platform 클러스터에서 나가는 송신 트래픽을 제한하는 프로젝트에 대한 송신 방화벽을 생성할 수 있습니다.

5.4.1. 프로젝트에서 송신 방화벽이 작동하는 방식
링크 복사

클러스터 관리자는 송신 방화벽을 사용하여 일부 또는 모든 Pod가 클러스터 내에서 액세스할 수 있는 외부 호스트를 제한할 수 있습니다. 송신 방화벽은 다음 시나리오를 지원합니다.

  • Pod는 내부 호스트에만 연결할 수 있으며 공용 인터넷 연결을 시작할 수 없습니다.
  • Pod는 공용 인터넷에만 연결할 수 있으며 OpenShift Container Platform 클러스터 외부에 있는 내부 호스트에 대한 연결을 시작할 수 없습니다.
  • Pod는 지정된 내부 서브넷이나 OpenShift Container Platform 클러스터 외부의 호스트에 연결할 수 없습니다.
  • Pod는 특정 외부 호스트에만 연결할 수 있습니다.

예를 들어, 한 프로젝트가 지정된 IP 범위에 액세스하도록 허용하지만 다른 프로젝트에 대한 동일한 액세스는 거부할 수 있습니다. 또는 애플리케이션 개발자가 Python pip 미러에서 업데이트하지 못하도록 하고 승인된 소스에서만 업데이트를 수행하도록 할 수 있습니다.

참고

송신 방화벽은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 송신 방화벽 규칙의 영향을 받지 않습니다.

EgressFirewall CR(사용자 정의 리소스) 오브젝트를 만들어 송신 방화벽 정책을 구성합니다. 송신 방화벽은 다음 기준 중 하나를 충족하는 네트워크 트래픽과 일치합니다.

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
  • 포트 번호
  • 다음 프로토콜 중 하나인 프로토콜 : TCP, UDP 및 SCTP
중요

송신 방화벽에 0.0.0.0/0에 대한 거부 규칙이 포함된 경우 OpenShift Container Platform API 서버에 대한 액세스 권한이 차단됩니다. 각 IP 주소에 대해 허용 규칙을 추가하거나 송신 정책 규칙에서 nodeSelector 유형 허용 규칙을 사용하여 API 서버에 연결해야 합니다.

다음 예제에서는 API 서버 액세스를 확인하는 데 필요한 송신 방화벽 규칙의 순서를 보여줍니다. 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>
1 

spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
2 

    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
3 

    type: Deny
Copy to Clipboard Toggle word wrap
1
송신 방화벽의 네임스페이스입니다.
2
OpenShift Container Platform API 서버를 포함하는 IP 주소 범위입니다.
3
글로벌 거부 규칙은 OpenShift Container Platform API 서버에 액세스할 수 없습니다.

API 서버의 IP 주소를 찾으려면 oc get ep kubernetes -n default 를 실행합니다.

자세한 내용은 BZ#1988324에서 참조하십시오.

주의

송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.

5.4.1.1. 송신 방화벽의 제한
링크 복사

송신 방화벽에는 다음과 같은 제한이 있습니다.

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 프로젝트당 최대 50개의 규칙이 있는 최대 하나의 EgressFirewall 오브젝트를 정의할 수 있습니다.
  • Red Hat OpenShift Networking에서 공유 게이트웨이 모드가 있는 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 반환 수신 응답이 송신 방화벽 규칙의 영향을 받습니다. 송신 방화벽 규칙이 ingress 응답 대상 IP를 삭제하면 트래픽이 삭제됩니다.

이러한 제한 사항을 위반하면 프로젝트의 송신 방화벽이 손상됩니다. 결과적으로 모든 외부 네트워크 트래픽이 삭제되어 조직에 보안 위험이 발생할 수 있습니다.

Egress Firewall 리소스는 kube-node-lease,kube-public,kube-system,openshift 및 openshift- 프로젝트에서 생성할 수 있습니다.

5.4.1.2. 송신 방화벽 정책 규칙에 대한 일치 순서
링크 복사

송신 방화벽 정책 규칙은 정의된 순서대로 처음부터 마지막까지 평가됩니다. Pod의 송신 연결과 일치하는 첫 번째 규칙이 적용됩니다. 해당 연결에 대한 모든 후속 규칙은 무시됩니다.

5.4.1.3. DNS(Domain Name Server) 확인 작동 방식
링크 복사

송신 방화벽 정책 규칙에서 DNS 이름을 사용하는 경우 도메인 이름의 적절한 확인에는 다음 제한 사항이 적용됩니다.

  • 도메인 이름 업데이트는 TTL(Time To- Live) 기간에 따라 폴링됩니다. 기본적으로 기간은 30분입니다. 송신 방화벽 컨트롤러가 로컬 이름 서버에 도메인 이름을 쿼리할 때 응답에 TTL이 포함되고 TTL이 30분 미만이면 컨트롤러는 해당 DNS 이름의 기간을 반환된 값으로 설정합니다. 각 DNS 이름은 DNS 레코드의 TTL이 만료된 후에 쿼리됩니다.
  • Pod는 필요한 경우 동일한 로컬 이름 서버에서 도메인을 확인해야 합니다. 확인하지 않으면 송신 방화벽 컨트롤러와 Pod에 의해 알려진 도메인의 IP 주소가 다를 수 있습니다. 호스트 이름의 IP 주소가 다르면 송신 방화벽이 일관되게 적용되지 않을 수 있습니다.
  • 송신 방화벽 컨트롤러와 Pod는 동일한 로컬 이름 서버를 비동기적으로 폴링하기 때문에 Pod가 송신 컨트롤러보다 먼저 업데이트된 IP 주소를 얻을 수 있으며 이로 인해 경쟁 조건이 발생합니다. 현재 이런 제한으로 인해 EgressFirewall 오브젝트의 도메인 이름 사용은 IP 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
참고

송신 방화벽 정책에서 DNS 이름을 사용하는 것은 CoreDNS를 통한 로컬 DNS 확인에는 영향을 미치지 않습니다.

그러나 송신 방화벽 정책이 도메인 이름을 사용하고 외부 DNS 서버가 영향을 받는 Pod의 DNS 확인을 처리하는 경우 DNS 서버의 IP 주소에 대한 액세스를 허용하는 송신 방화벽 규칙을 포함해야 합니다.

5.4.1.3.1. DNS 확인 및 와일드카드 도메인 이름 확인
링크 복사

DNS 레코드와 연결된 IP 주소가 자주 변경되거나 송신 방화벽 정책 규칙에 와일드카드 도메인 이름을 지정할 수 있는 상황이 있을 수 있습니다.

이 경우 OVN-Kubernetes 클러스터 관리자는 송신 방화벽 정책 규칙에 사용되는 각 고유 DNS 이름에 대해 DNSNameResolver 사용자 정의 리소스 오브젝트를 생성합니다. 이 사용자 정의 리소스는 다음 정보를 저장합니다.

중요

송신 방화벽 규칙에 대한 DNS 확인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

DNSNameResolver CR 정의의 예

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com.
1 

status:
  resolvedNames:
  - dnsName: www.example.com.
2 

    resolvedAddress:
    - ip: "1.2.3.4"
3 

      ttlSeconds: 60
4 

      lastLookupTime: "2023-08-08T15:07:04Z"
5
Copy to Clipboard Toggle word wrap

1
DNS 이름입니다. 표준 DNS 이름 또는 와일드카드 DNS 이름일 수 있습니다. 와일드카드 DNS 이름의 경우 DNS 이름 확인 정보에는 와일드카드 DNS 이름과 일치하는 모든 DNS 이름이 포함됩니다.
2
spec.name 필드와 일치하는 확인된 DNS 이름입니다. spec.name 필드에 와일드카드 DNS 이름이 포함된 경우 확인 시 와일드카드 DNS 이름과 일치하는 표준 DNS 이름이 포함된 여러 dnsName 항목이 생성됩니다. 와일드카드 DNS 이름도 성공적으로 확인할 수 있는 경우 이 필드는 와일드카드 DNS 이름도 저장합니다.
3
DNS 이름과 연결된 현재 IP 주소입니다.
4
마지막 TTL(Time-to-live) 기간입니다.
5
마지막 조회 시간입니다.

DNS 확인 중에 쿼리의 DNS 이름이 DNSNameResolver CR에 정의된 이름과 일치하는 경우 이전 정보는 CR status 필드에 적절하게 업데이트됩니다. 실패한 DNS 와일드카드 이름 조회의 경우 요청은 기본 TTL 30분 후에 다시 시도합니다.

OVN-Kubernetes 클러스터 관리자는 EgressFirewall 사용자 정의 리소스 오브젝트의 업데이트를 감시하고 해당 업데이트가 발생할 때 해당 송신 방화벽 정책과 연결된 DNSNameResolver CR을 생성, 수정 또는 삭제합니다.

주의

DNSNameResolver 사용자 정의 리소스를 직접 수정하지 마십시오. 이로 인해 송신 방화벽의 원치 않는 동작이 발생할 수 있습니다.

5.4.2. EgressFirewall CR(사용자 정의 리소스) 오브젝트
링크 복사

송신 방화벽에 대해 하나 이상의 규칙을 정의할 수 있습니다. 규칙이 적용되는 트래픽에 대한 사양을 담은 Allow 규칙 또는 Deny 규칙입니다.

다음 YAML은 EgressFirewall CR 오브젝트를 설명합니다.

EgressFirewall 오브젝트

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: <name>
1 

spec:
  egress:
2 

    ...
Copy to Clipboard Toggle word wrap

1
오브젝트의 이름은 default이어야 합니다.
2
다음 섹션에서 설명하는 하나 이상의 송신 네트워크 정책 규칙 컬렉션입니다.
5.4.2.1. EgressFirewall 규칙
링크 복사

다음 YAML은 송신 방화벽 규칙 오브젝트를 설명합니다. 사용자는 CIDR 형식, 도메인 이름에서 IP 주소 범위를 선택하거나 nodeSelector 를 사용하여 송신 트래픽을 허용하거나 거부할 수 있습니다. 송신 스탠자는 하나 이상의 오브젝트 배열을 예상합니다.

송신 정책 규칙 스탠자

egress:
- type: <type>
1 

  to:
2 

    cidrSelector: <cidr>
3 

    dnsName: <dns_name>
4 

    nodeSelector: <label_name>: <label_value>
5 

  ports:
6 

      ...
Copy to Clipboard Toggle word wrap

1
규칙 유형입니다. 값은 Allow 또는 Deny여야 합니다.
2
cidrSelector 필드 또는 dnsName 필드를 지정하는 송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
3
CIDR 형식의 IP 주소 범위입니다,
4
DNS 도메인 이름입니다.
5
레이블은 사용자가 정의하는 키/값 쌍입니다. 레이블은 Pod와 같은 오브젝트에 연결됩니다. nodeSelector 를 사용하면 하나 이상의 노드 레이블을 선택하고 Pod에 연결할 수 있습니다.
6
선택 사항: 규칙에 대한 네트워크 포트 및 프로토콜 컬렉션을 설명하는 스탠자입니다.

포트 스탠자

ports:
- port: <port>
1 

  protocol: <protocol>
2
Copy to Clipboard Toggle word wrap

1
80 또는 443과 같은 네트워크 포트. 이 필드의 값을 지정하는 경우 protocol의 값도 지정해야 합니다.
2
네트워크 프로토콜. 값은 TCP, UDP 또는 SCTP여야 합니다.
5.4.2.2. EgressFirewall CR 오브젝트의 예
링크 복사

다음 예는 여러 가지 송신 방화벽 정책 규칙을 정의합니다. 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
1 

  - type: Allow
    to:
      cidrSelector: 1.2.3.0/24
  - type: Deny
    to:
      cidrSelector: 0.0.0.0/0
Copy to Clipboard Toggle word wrap
1
송신 방화벽 정책 규칙 오브젝트의 컬렉션입니다.

다음 예제에서는 트래픽이 TCP 프로토콜 및 대상 포트 80 또는 임의의 프로토콜 및 대상 포트 443 을 사용하는 경우 172.16.1.1/32 IP 주소에서 호스트에 대한 트래픽을 거부하는 정책 규칙을 정의합니다. 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
  egress:
  - type: Deny
    to:
      cidrSelector: 172.16.1.1/32
    ports:
    - port: 80
      protocol: TCP
    - port: 443
Copy to Clipboard Toggle word wrap
5.4.2.3. EgressFirewall의 nodeSelector 예
링크 복사

클러스터 관리자는 nodeSelector 를 사용하여 라벨을 지정하여 클러스터의 노드에 대한 송신 트래픽을 허용하거나 거부할 수 있습니다. 레이블은 하나 이상의 노드에 적용할 수 있습니다. 다음은 region=east 라벨이 있는 예입니다. 

apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
spec:
    egress:
    - to:
        nodeSelector:
          matchLabels:
            region: east
      type: Allow
Copy to Clipboard Toggle word wrap
작은 정보

노드 IP 주소당 수동 규칙을 추가하는 대신 노드 선택기를 사용하여 송신 방화벽 뒤의 Pod가 호스트 네트워크 pod에 액세스할 수 있는 레이블을 생성합니다.

5.4.3. 송신 방화벽 정책 오브젝트 생성
링크 복사

클러스터 관리자는 프로젝트에 대한 송신 방화벽 정책 오브젝트를 만들 수 있습니다.

중요

프로젝트에 이미 EgressFirewall 오브젝트가 정의되어 있는 경우 기존 정책을 편집하여 송신 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

  • OVN-Kubernetes 네트워크 플러그인을 사용하는 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 클러스터 관리자로 클러스터에 로그인해야 합니다.

프로세스

  1. 다음과 같이 정책 규칙을 생성합니다.

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 생성한 파일에서 송신 정책 오브젝트를 정의합니다.

  2. 다음 명령을 입력하여 정책 오브젝트를 생성합니다. <policy_name>을 정책 이름으로 바꾸고 <project>를 규칙이 적용되는 프로젝트로 바꿉니다. 

    $ oc create -f <policy_name>.yaml -n <project>
    Copy to Clipboard Toggle word wrap

    출력 성공에는 egressfirewall.k8s.ovn.org/v1 이름과 생성된 상태가 나열됩니다.

  3. 선택사항: 나중에 변경할 수 있도록 <policy_name>.yaml 파일을 저장합니다.

6장. IPsec 암호화 구성
링크 복사

IPsec을 활성화하면 클러스터 외부의 Pod와 IPsec 끝점 간의 내부 pod-to-pod 클러스터 트래픽을 모두 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 pod-to-pod 네트워크 트래픽은 전송 모드에서 IPsec으로 암호화됩니다.

IPsec은 기본적으로 비활성화되어 있습니다. 클러스터를 설치하는 동안 또는 클러스터를 설치한 후 IPsec을 활성화할 수 있습니다. 클러스터 설치에 대한 자세한 내용은 OpenShift Container Platform 설치 개요 를 참조하십시오.

참고

libreswan 및 NetworkManager-libreswan 패키지에 다른 OpenShift Container Platform 버전이 있는 경우 클러스터를 OpenShift Container Platform 4.18로 업그레이드하면 두 개의 연속 컴퓨팅 노드 재부팅 작업이 발생합니다. 첫 번째 재부팅의 경우 CNO(Cluster Network Operator)는 IPsec 구성을 컴퓨팅 노드에 적용합니다. 두 번째 재부팅의 경우 MCO(Machine Config Operator)는 최신 머신 구성을 클러스터에 적용합니다.

CNO 및 MCO 업데이트를 단일 노드 재부팅에 결합하려면 다음 작업을 완료합니다.

  • 클러스터를 업그레이드하기 전에 컴퓨팅 노드를 그룹화하는 MachineConfigPools CR(사용자 정의 리소스)에서 paused 매개변수를 true 로 설정합니다.
  • 클러스터를 업그레이드한 후 매개변수를 false 로 설정합니다.

자세한 내용은 컨트롤 플레인만 업데이트 수행을 참조하십시오.

OpenShift Container Platform 클러스터의 IPsec에 대해 다음과 같은 지원 제한 사항이 있습니다.

  • IBM Cloud®에서 IPsec은 NAT-T만 지원합니다. 이 플랫폼에서 ESP(Security Payload)를 캡슐화하는 것은 지원되지 않습니다.
  • 클러스터에서 Red Hat OpenShift Container Platform에 호스팅되는 컨트롤 플레인 을 사용하는 경우 pod-to-pod 또는 외부 호스트에 대한 트래픽의 IPsec 암호화에는 IPsec이 지원되지 않습니다.
  • 하나 이상의 인터페이스가 OVS(Open vSwitch)에 연결된 경우 네트워크 인터페이스에서 ESP 하드웨어 오프로드를 사용할 수 없습니다. 클러스터에 IPsec을 활성화하면 OVS에 연결된 인터페이스가 있는 IPsec 사용이 트리거됩니다. 기본적으로 OpenShift Container Platform은 OVS에 연결된 인터페이스에서 ESP 하드웨어 오프로드를 비활성화합니다.
  • OVS에 연결되지 않은 네트워크 인터페이스에 IPsec을 활성화한 경우 클러스터 관리자는 OVS에 연결되지 않은 각 인터페이스에서 ESP 하드웨어 오프로드를 수동으로 비활성화해야 합니다.
  • IPsec은 각 컴퓨팅 노드에 있는 호스트와 ovn-ipsec 컨테이너 간의 libreswan 비호환성 문제로 인해 RHEL(Red Hat Enterprise Linux) 컴퓨팅 노드에서 지원되지 않습니다. (OCPBUGS-53316)를 참조하십시오.

다음 목록은 IPsec 문서의 주요 작업을 간략하게 설명합니다.

  • 클러스터 설치 후 IPsec을 활성화하고 비활성화합니다.
  • 클러스터와 외부 호스트 간의 트래픽에 대한 IPsec 암호화를 구성합니다.
  • IPsec이 다른 노드의 Pod 간 트래픽을 암호화하는지 확인합니다.

6.1. 작업 모드
링크 복사

OpenShift Container Platform 클러스터에서 IPsec을 사용하는 경우 다음 운영 모드에서 선택할 수 있습니다.

Expand
표 6.1. IPsec 작업 모드
모드설명기본

비활성화됨

트래픽은 암호화되지 않습니다. 이는 클러스터 기본값입니다.

제공됨

full

pod-to-pod 트래픽은 "Pod-to-pod IPsec"에 의해 암호화된 네트워크 트래픽 흐름의 유형에 설명된 대로 암호화됩니다. IPsec에 필요한 구성 단계를 완료한 후 외부 노드로의 트래픽이 암호화될 수 있습니다.

없음

외부

IPsec에 필요한 구성 단계를 완료한 후 외부 노드로의 트래픽이 암호화될 수 있습니다.

없음

6.2. 사전 요구 사항
링크 복사

외부 호스트에 대한 트래픽을 암호화하기 위한 IPsec 지원의 경우 다음 사전 요구 사항이 충족되어야 합니다.

  • OVN-Kubernetes 네트워크 플러그인은 로컬 게이트웨이 모드에서 구성해야 합니다. 여기서 ovnKubernetesConfig.gatewayConfig.routingViaHost=true.

  • NMState Operator가 설치되어 있습니다. 이 Operator는 IPsec 구성을 지정하는 데 필요합니다. 자세한 내용은 Kubernetes NMState Operator 를 참조하십시오.

    참고

    NMState Operator는 IPsec 구성에 대해서만 GCP(Google Cloud Platform)에서 지원됩니다.

  • Butane 툴(butane)이 설치되어 있습니다. Butane을 설치하려면 Butane 설치를 참조하십시오.

이러한 사전 요구 사항은 호스트 NSS 데이터베이스에 인증서를 추가하고 외부 호스트와 통신하도록 IPsec을 구성해야 합니다.

6.3. IPsec이 활성화된 경우 네트워크 연결 요구 사항
링크 복사

OpenShift Container Platform 클러스터 구성 요소가 통신할 수 있도록 시스템 간 네트워크 연결을 구성해야 합니다. 각 시스템에서 클러스터에 있는 다른 모든 시스템의 호스트 이름을 확인할 수 있어야 합니다.

Expand
표 6.2. 모든 시스템 간 통신에 사용되는 포트
프로토콜포트설명

UDP

500

IPsec IKE 패킷

4500

IPsec NAT-T 패킷

ESP

해당 없음

IPsec Encapsulating Security Payload (ESP)

6.4. pod-to-pod 트래픽에 대한 IPsec 암호화
링크 복사

pod-to-pod 트래픽의 IPsec 암호화의 경우 다음 섹션에서는 어떤 특정 pod-to-pod 트래픽이 암호화되는지, 어떤 종류의 암호화 프로토콜이 사용되는지, X.509 인증서가 처리되는 방법을 설명합니다. 이러한 섹션은 특정 외부 네트워크 인프라에 대해 수동으로 구성해야 하는 클러스터와 외부 호스트 간의 IPsec 암호화에는 적용되지 않습니다.

6.4.1. pod-to-pod IPsec으로 암호화된 네트워크 트래픽 흐름 유형
링크 복사

IPsec을 활성화하면 포드 간 다음 네트워크 트래픽 흐름만 암호화됩니다.

  • 클러스터 네트워크의 서로 다른 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드에서 클러스터 네트워크의 포드로의 트래픽

다음 트래픽 흐름은 암호화되지 않습니다.

  • 클러스터 네트워크의 동일한 노드에 있는 pod 간 트래픽
  • 호스트 네트워크의 포드 간 트래픽
  • 클러스터 네트워크의 포드에서 호스트 네트워크 포드로의 트래픽

암호화되거나 암호화되지 않은 흐름은 다음 다이어그램에 설명되어 있습니다.

IPsec 암호화 및 암호화되지 않은 트래픽 흐름
View larger image
IPsec 암호화 및 암호화되지 않은 트래픽 흐름

6.4.2. 암호화 프로토콜 및 IPsec 모드
링크 복사

사용된 암호화 암호는 AES-GCM-16-256입니다. 무결성 검사 값(ICV)은 16바이트입니다. 키 길이는 256비트입니다.

사용된 IPsec 모드는 전송 모드입니다. 즉, ESP(Encapsulated Security Payload) 헤더를 원래 패킷의 IP 헤더에 추가하고 패킷 데이터를 암호화하여 엔드 투 엔드 통신을 암호화하는 모드입니다. OpenShift Container Platform은 현재 pod-to-pod 통신에 IPsec tunnel 모드를 사용하거나 지원하지 않습니다.

6.4.3. 보안 인증서 생성 및 교체
링크 복사

CNO(Cluster Network Operator)는 암호화에 IPsec에서 사용하는 자체 서명된 X.509 인증 기관(CA)을 생성합니다. 각 노드의 CSR(인증서 서명 요청)은 CNO에서 자동으로 충족됩니다.

CA는 10년 동안 유효합니다. 개별 노드 인증서는 5년간 유효하며 4년 6개월 경과 후 자동으로 교체됩니다.

6.5. 외부 트래픽에 대한 IPsec 암호화
링크 복사

OpenShift Container Platform은 제공해야 하는 TLS 인증서가 있는 외부 호스트에 대한 트래픽에 대해 IPsec 암호화를 지원합니다.

6.5.1. 지원되는 플랫폼
링크 복사

이 기능은 다음 플랫폼에서 지원됩니다.

  • 베어 메탈
  • GCP(Google Cloud Platform)
  • Red Hat OpenStack Platform (RHOSP)
  • VMware vSphere
중요

RHEL(Red Hat Enterprise Linux) 작업자 노드가 있는 경우 외부 트래픽에 대해 IPsec 암호화를 지원하지 않습니다.

클러스터에서 Red Hat OpenShift Container Platform에 호스팅된 컨트롤 플레인을 사용하는 경우 외부 호스트에 대한 트래픽을 암호화하기 위해 IPsec을 구성하는 것은 지원되지 않습니다.

6.5.2. 제한
링크 복사

다음과 같은 금지 사항이 있는지 확인합니다.

  • IPv6 구성은 현재 외부 트래픽에 대해 IPsec을 구성할 때 NMState Operator에서 지원되지 않습니다.
  • 제공된 인증서 번들에 있는 인증서 공통 이름(CN)은 ovs_ 접두사로 시작해야 합니다. 이 이름은 각 노드의 NSS(Network Security Services) 데이터베이스의 pod-to-pod IPsec CN 이름과 충돌할 수 있기 때문입니다.

6.6. IPsec 암호화 활성화
링크 복사

클러스터 관리자는 pod-to-pod IPsec 암호화, 클러스터 간 IPsec 암호화 및 외부 IPsec 끝점을 활성화할 수 있습니다.

다음 모드 중 하나로 IPsec을 구성할 수 있습니다.

  • full: pod-to-pod 및 외부 트래픽에 대한 암호화
  • External: 외부 트래픽의 암호화
참고

전체 모드에서 IPsec을 구성하는 경우 "외부 트래픽용 IPsec 암호화 구성" 절차도 완료해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • IPsec ESP 헤더의 오버헤드를 허용하도록 클러스터 MTU의 크기를 46 바이트 감소했습니다.

프로세스

  1. IPsec 암호화를 활성화하려면 다음 명령을 입력합니다. 

    $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"<mode">
    1 
    
        }}}}}'
    Copy to Clipboard Toggle word wrap
    1
    외부 호스트에 대한 트래픽을 암호화하거나 Pod 간 트래픽을 암호화하고 선택적으로 외부 호스트로의 트래픽을 암호화하도록 Full 을 지정합니다. 기본적으로 IPsec은 비활성화되어 있습니다.
  2. "외부 트래픽용 IPsec 암호화 구성" 절차를 완료하여 IPsec으로 외부 트래픽을 암호화합니다.

검증

  1. OVN-Kubernetes 데이터 플레인 Pod의 이름을 찾으려면 다음 명령을 입력합니다. 

    $ oc get pods -n openshift-ovn-kubernetes -l=app=ovnkube-node
    Copy to Clipboard Toggle word wrap

    출력 예

    ovnkube-node-5xqbf                       8/8     Running   0              28m
ovnkube-node-6mwcx                       8/8     Running   0              29m
ovnkube-node-ck5fr                       8/8     Running   0              31m
ovnkube-node-fr4ld                       8/8     Running   0              26m
ovnkube-node-wgs4l                       8/8     Running   0              33m
ovnkube-node-zfvcl                       8/8     Running   0              34m
...
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 클러스터에서 IPsec을 활성화했는지 확인합니다.

    참고

    클러스터 관리자는 전체 모드에서 IPsec을 구성할 때 클러스터의 Pod 간에 IPsec을 활성화했는지 확인할 수 있습니다. 이 단계에서는 클러스터와 외부 호스트 간에 IPsec이 작동하는지 확인하지 않습니다. 

    $ oc -n openshift-ovn-kubernetes rsh ovnkube-node-<XXXXX> ovn-nbctl --no-leader-only get nb_global . ipsec
    1
    Copy to Clipboard Toggle word wrap

    여기서 & lt;XXXXX >는 이전 단계에서 Pod의 임의의 문자 시퀀스를 지정합니다.

    명령의 성공적인 출력에는 상태가 true 로 표시됩니다.

6.7. 외부 트래픽에 대한 IPsec 암호화 구성
링크 복사

클러스터 관리자는 IPsec을 사용하여 외부 트래픽을 암호화하려면 PKCS#12 인증서 제공을 포함하여 네트워크 인프라에 대해 IPsec을 구성해야 합니다. 이 절차에서는 Butane을 사용하여 머신 구성을 생성하므로 butane 명령이 설치되어 있어야 합니다.

참고

머신 구성을 적용한 후 Machine Config Operator가 클러스터의 영향을 받는 노드를 재부팅하여 새 머신 구성을 롤아웃합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 로컬 컴퓨터에 butane 유틸리티를 설치했습니다.
  • NMState Operator가 클러스터에 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인했습니다.
  • IPsec 끝점에 대한 기존 PKCS#12 인증서와 PEM 형식의 CA 인증서가 있습니다.
  • 클러스터에서 전체 또는 외부 모드에서 IPsec을 활성화했습니다.
  • OVN-Kubernetes 네트워크 플러그인은 로컬 게이트웨이 모드에서 구성해야 합니다. 여기서 ovnKubernetesConfig.gatewayConfig.routingViaHost=true.

프로세스

  1. NMState Operator 노드 네트워크 구성 정책을 사용하여 IPsec 구성을 생성합니다. 자세한 내용은 IPsec VPN 구현으로 Libreswan을 참조하십시오.

    1. IPsec 끝점인 클러스터 노드의 IP 주소를 확인하려면 다음 명령을 입력합니다. 

      $ oc get nodes
      Copy to Clipboard Toggle word wrap

    2. 다음 예와 같이 NMState Operator에 대한 노드 네트워크 구성 정책이 포함된 ipsec-config.yaml 이라는 파일을 생성합니다. NodeNetworkConfigurationPolicy 오브젝트에 대한 개요 는 Kubernetes NMState 프로젝트를 참조하십시오.

      NMState IPsec 전송 구성의 예

      apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>"
      1 
      
  desiredState:
    interfaces:
    - name: <interface_name>
      2 
      
      type: ipsec
      libreswan:
        left: <cluster_node>
      3 
      
        leftid: '%fromcert'
        leftrsasigkey: '%cert'
        leftcert: left_server
        leftmodecfgclient: false
        right: <external_host>
      4 
      
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32
      5 
      
        ikev2: insist
        type: transport
      Copy to Clipboard Toggle word wrap

      1 1
      정책을 적용할 호스트 이름을 지정합니다. 이 호스트는 IPsec 구성에서 왼쪽 호스트로 사용됩니다.
      2
      호스트에서 생성할 인터페이스의 이름을 지정합니다.
      3
      클러스터 측에서 IPsec 터널을 종료하는 클러스터 노드의 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [Subject Alternate Name] 과 일치해야 합니다.
      4
      host.example.com 과 같은 외부 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [Subject Alternate Name] 과 일치해야 합니다.
      5
      10.1.2.3/32 와 같은 외부 호스트의 IP 주소를 지정합니다.

      NMState IPsec 터널 구성의 예

      apiVersion: nmstate.io/v1
kind: NodeNetworkConfigurationPolicy
metadata:
  name: ipsec-config
spec:
  nodeSelector:
    kubernetes.io/hostname: "<hostname>"
      1 
      
  desiredState:
    interfaces:
    - name: <interface_name>
      2 
      
      type: ipsec
      libreswan:
        left: <cluster_node>
      3 
      
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftrsasigkey: '%cert'
        leftcert: left_server
        right: <external_host>
      4 
      
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32
      5 
      
        ikev2: insist
        type: tunnel
      Copy to Clipboard Toggle word wrap

      1
      정책을 적용할 호스트 이름을 지정합니다. 이 호스트는 IPsec 구성에서 왼쪽 호스트로 사용됩니다.
      2
      호스트에서 생성할 인터페이스의 이름을 지정합니다.
      3
      클러스터 측에서 IPsec 터널을 종료하는 클러스터 노드의 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [Subject Alternate Name] 과 일치해야 합니다.
      4
      host.example.com 과 같은 외부 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [Subject Alternate Name] 과 일치해야 합니다.
      5
      10.1.2.3/32 와 같은 외부 호스트의 IP 주소를 지정합니다.

    3. IPsec 인터페이스를 구성하려면 다음 명령을 입력합니다. 

      $ oc create -f ipsec-config.yaml
      Copy to Clipboard Toggle word wrap

  2. 각 호스트의 NSS(Network Security Services) 데이터베이스에 추가할 다음 인증서 파일을 제공합니다. 이러한 파일은 이후 단계에서 Butane 구성의 일부로 가져옵니다.

    • left_server.p12: IPsec 엔드포인트의 인증서 번들
    • ca.pem: 인증서에 서명한 인증 기관

  3. 클러스터에 인증서를 추가할 머신 구성을 생성합니다.

    1. 컨트롤 플레인 및 작업자 노드에 대한 Butane 구성 파일을 생성하려면 다음 명령을 입력합니다.

      참고

      구성 파일에 지정하는 Butane 버전이 OpenShift Container Platform 버전과 일치해야 하며 항상 0 으로 끝나야 합니다. 예: 4.18.0. Butane에 대한 자세한 내용은 “Butane 을 사용하여 머신 구성 생성”을 참조하십시오. 

      $ for role in master worker; do
  cat >> "99-ipsec-${role}-endpoint-config.bu" <<-EOF
  variant: openshift
  version: 4.18.0
  metadata:
    name: 99-${role}-import-certs
    labels:
      machineconfiguration.openshift.io/role: $role
  systemd:
    units:
    - name: ipsec-import.service
      enabled: true
      contents: |
        [Unit]
        Description=Import external certs into ipsec NSS
        Before=ipsec.service

        [Service]
        Type=oneshot
        ExecStart=/usr/local/bin/ipsec-addcert.sh
        RemainAfterExit=false
        StandardOutput=journal

        [Install]
        WantedBy=multi-user.target
  storage:
    files:
    - path: /etc/pki/certs/ca.pem
      mode: 0400
      overwrite: true
      contents:
        local: ca.pem
    - path: /etc/pki/certs/left_server.p12
      mode: 0400
      overwrite: true
      contents:
        local: left_server.p12
    - path: /usr/local/bin/ipsec-addcert.sh
      mode: 0740
      overwrite: true
      contents:
        inline: |
          #!/bin/bash -e
          echo "importing cert to NSS"
          certutil -A -n "CA" -t "CT,C,C" -d /var/lib/ipsec/nss/ -i /etc/pki/certs/ca.pem
          pk12util -W "" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
          certutil -M -n "left_server" -t "u,u,u" -d /var/lib/ipsec/nss/
EOF
done
      Copy to Clipboard Toggle word wrap

    2. 이전 단계에서 생성한 Butane 파일을 머신 구성으로 변환하려면 다음 명령을 입력합니다. 

      $ for role in master worker; do
  butane -d . 99-ipsec-${role}-endpoint-config.bu -o ./99-ipsec-$role-endpoint-config.yaml
done
      Copy to Clipboard Toggle word wrap

  4. 머신 구성을 클러스터에 적용하려면 다음 명령을 입력합니다. 

    $ for role in master worker; do
  oc apply -f 99-ipsec-${role}-endpoint-config.yaml
done
    Copy to Clipboard Toggle word wrap
    중요

    MCO(Machine Config Operator)는 각 머신 구성 풀에서 머신을 업데이트하므로 각 노드를 하나씩 재부팅합니다. 외부 IPsec 연결을 사용할 수 있기 전에 모든 노드가 업데이트될 때까지 기다려야 합니다.

  5. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다. 

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  6. IPsec 머신 구성이 성공적으로 롤아웃되었는지 확인하려면 다음 명령을 입력합니다.

    1. IPsec 머신 구성 생성을 확인합니다. 

      $ oc get mc | grep ipsec
      Copy to Clipboard Toggle word wrap

      출력 예

      80-ipsec-master-extensions        3.2.0        6d15h
80-ipsec-worker-extensions        3.2.0        6d15h
      Copy to Clipboard Toggle word wrap

    2. 컨트롤 플레인 노드에 대한 IPsec 확장의 애플리케이션을 확인합니다. 예제 출력에는 2 가 표시됩니다. 

      $ oc get mcp master -o yaml | grep 80-ipsec-master-extensions -c
      Copy to Clipboard Toggle word wrap

    3. 컴퓨팅 노드에 IPsec 확장의 애플리케이션을 확인합니다. 예제 출력에는 2 가 표시됩니다. 

      $ oc get mcp worker -o yaml | grep 80-ipsec-worker-extensions -c
      Copy to Clipboard Toggle word wrap

6.8. 외부 IPsec 끝점에 대한 IPsec 암호화 비활성화
링크 복사

클러스터 관리자는 기존 IPsec 터널을 외부 호스트에 제거할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 클러스터에서 전체 또는 외부 모드에서 IPsec을 활성화했습니다.

프로세스

  1. 다음 YAML을 사용하여 remove-ipsec-tunnel.yaml 이라는 파일을 생성합니다. 

    kind: NodeNetworkConfigurationPolicy
apiVersion: nmstate.io/v1
metadata:
  name: <name>
spec:
  nodeSelector:
    kubernetes.io/hostname: <node_name>
  desiredState:
    interfaces:
    - name: <tunnel_name>
      type: ipsec
      state: absent
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    name
    노드 네트워크 구성 정책의 이름을 지정합니다.
    node_name
    삭제할 IPsec 터널이 있는 노드의 이름을 지정합니다.
    tunnel_name
    기존 IPsec 터널의 인터페이스 이름을 지정합니다.

  2. IPsec 터널을 제거하려면 다음 명령을 입력합니다. 

    $ oc apply -f remove-ipsec-tunnel.yaml
    Copy to Clipboard Toggle word wrap

6.9. IPsec 암호화 비활성화
링크 복사

클러스터 관리자는 IPsec 암호화를 비활성화할 수 있습니다.

사전 요구 사항

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

프로세스

  1. IPsec 암호화를 비활성화하려면 다음 명령을 입력합니다. 

    $ oc patch networks.operator.openshift.io cluster --type=merge \
-p '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Disabled"
        }}}}}'
    Copy to Clipboard Toggle word wrap
  2. 선택 사항: IP 패킷의 IPsec ESP 헤더에서 오버헤드가 더 이상 없으므로 클러스터 MTU 크기를 46 바이트까지 늘릴 수 있습니다.

6.10. 추가 리소스
링크 복사

7장. 제로 신뢰 네트워킹
링크 복사

제로 신뢰는 모든 상호 작용이 신뢰할 수 없는 상태에서 시작되는 전제를 기반으로 보안 아키텍처를 설계하는 방법입니다. 이는 방화벽 내에서 통신이 시작되는지 여부에 따라 신뢰성을 결정할 수 있는 기존 아키텍처와 대조됩니다. 특히 제로 신뢰는 암시적 신뢰 모델 및 일회성 인증에 의존하는 보안 아키텍처의 격차를 없애려고 합니다.

OpenShift Container Platform은 컨테이너 또는 해당 컨테이너에서 실행되는 소프트웨어를 변경하지 않고도 플랫폼에서 실행되는 컨테이너에 일부 제로 신뢰 네트워킹 기능을 추가할 수 있습니다. Red Hat이 제공하는 여러 제품도 컨테이너의 제로 신뢰 네트워킹 기능을 추가로 보강할 수 있습니다. 컨테이너에서 실행되는 소프트웨어를 변경할 수 있는 기능이 있는 경우 Red Hat에서 추가 기능을 추가할 수 있는 다른 프로젝트가 있습니다.

제로 신뢰 네트워킹의 다음과 같은 대상 기능을 살펴봅니다.

7.1. 신뢰의 루트
링크 복사

공개 인증서 및 개인 키는 제로 트러스트 네트워킹에 중요합니다. 이러한 구성 요소는 서로 구성 요소를 식별하고 인증하고 트래픽을 보호하는 데 사용됩니다. 인증서는 다른 인증서에서 서명하며 루트 CA(인증 기관)에 대한 신뢰 체인이 있습니다. 네트워크에 참여하는 모든 것은 궁극적으로 신뢰 체인을 검증할 수 있도록 루트 CA의 공개 키를 보유해야 합니다. 공개 내용의 경우 일반적으로 널리 알려진 루트 CA 세트이며 운영 체제, 웹 브라우저 등과 함께 키가 배포되는 키입니다. 그러나 개인 CA의 인증서가 모든 당사자에게 배포되는 경우 클러스터 또는 법인을 위해 개인 CA를 실행할 수 있습니다.

제품 상세 정보:

  • OpenShift Container Platform: OpenShift는 설치 시 클러스터 리소스를 보호하는 데 사용되는 클러스터 CA 를 생성합니다. 그러나 OpenShift Container Platform은 클러스터의 서비스에 대한 인증서를 생성하고 서명할 수 있으며 요청된 경우 클러스터 CA 번들을 Pod에 삽입할 수 있습니다. OpenShift Container Platform에서 생성 및 서명한 서비스 인증서 에는 26개월의 라이브(TTL)가 있으며 13개월에 자동으로 순환됩니다. 필요한 경우 수동으로 순환할 수도 있습니다.
  • OpenShift cert-manager Operator: cert-manager를 사용하면 신뢰의 외부 루트에서 서명한 키를 요청할 수 있습니다. 위임된 서명 인증서와 함께 외부 발행자와 통합할 수 있는 구성 가능한 많은 발행자가 있습니다. cert-manager API는 제로 신뢰 네트워킹의 다른 소프트웨어에서 사용하여 필요한 인증서(예: Red Hat OpenShift Service Mesh)를 요청하거나 고객 소프트웨어에서 직접 사용할 수 있습니다.

7.2. 트래픽 인증 및 암호화
링크 복사

유선의 모든 트래픽이 암호화되고 엔드포인트를 확인할 수 있는지 확인합니다. 상호 TLS 또는 mTLS는 상호 인증을 위한 방법입니다.

제품 상세 정보:

7.3. 식별 및 인증
링크 복사

CA를 사용하여 인증서를 Mint할 수 있는 기능이 있으면 이 인증서를 사용하여 사용자 또는 클라이언트 머신의 다른 쪽 끝의 ID를 확인하여 신뢰 관계를 설정할 수 있습니다. 또한 손상된 경우 사용을 제한하려면 인증서 라이프사이클을 관리해야 합니다.

제품 상세 정보:

  • OpenShift Container Platform: 클라이언트가 신뢰할 수 있는 끝점과 통신할 수 있도록 클러스터 서명 서비스 인증서 입니다. 이를 위해서는 서비스에서 SSL/TLS를 사용하고 클라이언트가 클러스터 CA 를 사용해야 합니다. 클라이언트 ID는 다른 방법을 사용하여 제공해야 합니다.
  • Red Hat Single Sign-On: 엔터프라이즈 사용자 디렉터리 또는 타사 ID 공급자와의 요청 인증 통합을 제공합니다.
  • Red Hat OpenShift Service Mesh: mTLS에 대한 연결투명 업그레이드, 자동 순환, 사용자 정의 인증서 만료, JSON 웹 토큰(JWT)을 통한 인증 요청.
  • OpenShift cert-manager Operator: 애플리케이션에서 사용할 인증서 생성 및 관리 인증서는 CRD에서 제어하고 시크릿으로 마운트하거나 cert-manager API와 직접 상호 작용하도록 애플리케이션을 변경할 수 있습니다.

7.4. 서비스 간 권한 부여
링크 복사

요청자의 ID를 기반으로 서비스에 대한 액세스를 제어할 수 있어야 합니다. 이 작업은 플랫폼에 의해 수행되며 각 애플리케이션을 구현할 필요가 없습니다. 이를 통해 정책의 감사 및 검사를 더 잘 수행할 수 있습니다.

제품 상세 정보:

  • OpenShift Container Platform: Kubernetes NetworkPolicy 및 AdminNetworkPolicy 오브젝트를 사용하여 플랫폼의 네트워킹 계층에 격리를 적용할 수 있습니다.
  • Red Hat OpenShift Service Mesh: 표준 Istio 오브젝트를 사용한 트래픽 제어 및 mTLS를 사용하여 트래픽의 소스 및 대상을 확인한 다음 해당 정보를 기반으로 정책을 적용합니다.

7.5. 트랜잭션 수준 확인
링크 복사

연결을 식별하고 인증하는 기능 외에도 개별 트랜잭션에 대한 액세스를 제어하는 것도 유용합니다. 여기에는 소스별 속도 제한, 관찰 기능, 트랜잭션이 잘 형성되는 의미 체계 검증이 포함될 수 있습니다.

제품 상세 정보:

7.6. 위험 평가
링크 복사

클러스터의 보안 정책 수가 증가함에 따라 정책 허용 및 거부에 대한 시각화가 점점 더 중요해지고 있습니다. 이러한 툴을 사용하면 클러스터 보안 정책을 보다 쉽게 생성, 시각화 및 관리할 수 있습니다.

제품 상세 정보:

7.7. 사이트 전체 정책 시행 및 배포
링크 복사

클러스터에 애플리케이션을 배포한 후 보안 규칙을 구성하는 모든 오브젝트를 관리하기가 어려워집니다. 사이트 전체 정책을 적용하고 배포된 오브젝트를 감사하여 정책을 준수하는 것이 중요합니다. 이렇게 하면 정의된 범위 내의 사용자 및 클러스터 관리자에게 일부 권한을 위임할 수 있으며 필요한 경우 정책에 대한 예외를 허용해야 합니다.

제품 상세 정보:

7.8. 일정 및 retrospective, evaluation에 대한 관찰 가능성
링크 복사

실행 중인 클러스터가 있으면 트래픽을 관찰하고 트래픽이 정의된 규칙으로 시작되는지 확인할 수 있어야 합니다. 이는 침입 감지, 법의학에 중요하며, 운영 부하 관리에 유용합니다.

제품 상세 정보:

  • Network Observability Operator: 클러스터의 Pod 및 노드에 대한 네트워크 연결에 대한 검사, 모니터링 및 경고를 허용합니다.
  • Red Hat Advanced Cluster Management(RHACM) for Kubernetes: 프로세스 실행, 네트워크 연결 및 흐름, 권한 에스컬레이션과 같은 시스템 수준 이벤트를 모니터링, 수집 및 평가합니다. 클러스터 기준을 확인한 다음 비정상적인 활동을 감지하고 이에 대해 경고할 수 있습니다.
  • Red Hat OpenShift Service Mesh: Pod로 들어오고 나가는 트래픽을 모니터링 할 수 있습니다.
  • Red Hat OpenShift Distributed Tracing Platform: 적절하게 조정된 애플리케이션의 경우 마이크로 서비스에 대한 하위 요청으로 분할할 때 특정 작업과 관련된 모든 트래픽을 확인할 수 있습니다. 이를 통해 분산 애플리케이션 내에서 병목 현상을 식별할 수 있습니다.

7.9. 엔드포인트 보안
링크 복사

클러스터에서 서비스를 실행하는 소프트웨어가 손상되지 않았음을 신뢰할 수 있어야 합니다. 예를 들어 인증된 이미지가 신뢰할 수 있는 하드웨어에서 실행되고 엔드포인트 특성을 기반으로 끝점 간 연결만 허용하는 정책이 있어야 할 수 있습니다.

제품 상세 정보:

  • OpenShift Container Platform: Secureboot는 클러스터의 노드가 신뢰할 수 있는 소프트웨어를 실행하도록 할 수 있으므로 플랫폼 자체(컨테이너 런타임 포함)가 변조되지 않았습니다. 특정 서명에서 서명된 이미지만 실행하도록 OpenShift Container Platform을 구성할 수 있습니다.
  • Red Hat Trusted Artifact Signer: 신뢰할 수 있는 빌드 체인에서 사용할 수 있으며 서명된 컨테이너 이미지를 생성할 수 있습니다.

7.10. 클러스터 외부에서 신뢰 확장
링크 복사

클러스터가 하위 도메인의 CA를 Mint하도록 허용하여 클러스터 외부에서 신뢰를 확장해야 할 수 있습니다. 또는 클러스터의 워크로드 ID를 원격 끝점으로 테스트할 수 있습니다.

제품 상세 정보:

  • OpenShift cert-manager Operator: cert-manager를 사용하여 다른 클러스터에 또는 조직을 통해 신뢰를 배포할 수 있도록 위임된 CA를 관리할 수 있습니다.
  • Red Hat OpenShift Service Mesh: SPIFFE를 사용하여 원격 또는 로컬 클러스터에서 실행되는 엔드포인트에 워크로드의 원격 인증 정보를 제공할 수 있습니다.

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat