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

네트워크 보안

OpenShift Container Platform 4.19

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

Red Hat OpenShift Documentation Team

초록

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

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

네트워크 정책은 클러스터 범위와 네임스페이스 범위 네트워크 정책 API를 모두 사용하여 정의됩니다. 이러한 다양한 수준에서 네트워크 정책을 정의하면 전체 멀티 테넌트 격리를 포함하여 클러스터에 대한 정교한 네트워크 보안 구성을 만들 수 있습니다.

1.1. 네트워크 정책 및 범위
링크 복사

클러스터 범위 네트워크 정책

클러스터 및 네트워크 관리자는 AdminNetworkPolicy를 사용하여 클러스터 수준에서 네트워크 정책을 정의할 수 있습니다. AdminNetworkPolicy 기능은 AdminNetworkPolicy API와 BaselineAdminNetworkPolicy API라는 두 가지 API로 구성됩니다. 이러한 API는 전체 클러스터에 적용할 수 있는 규칙을 설정하거나 네임스페이스 범위의 NetworkPolicy 에 위임하는 데 사용됩니다.

AdminNetworkPolicy API를 사용하여 정의된 정책은 "허용" 또는 "거부"로 설정된 경우 다른 모든 정책 유형보다 우선합니다. 그러나 관리자는 "Pass"를 사용하여 주어진 정책에 대한 책임을 네임스페이스 범위의 NetworkPolicy 에 위임하여 애플리케이션 개발자와 네임스페이스 테넌트가 프로젝트의 네트워크 보안의 특정 측면을 제어할 수 있도록 할 수도 있습니다.

BaselineAdminNetworkPolicy API를 사용하여 정의된 정책은 다른 네트워크 정책이 이를 재정의하지 않는 경우에만 적용됩니다. AdminNetworkPolicy API를 사용하여 네트워크 정책의 측면을 네임스페이스 범위의 NetworkPolicy 에 위임하는 경우 BaselineAdminNetworkPolicy 에서도 합리적인 최소 제한을 정의해야 합니다. 네임스페이스의 NetworkPolicy가 충분한 보호를 제공하지 못하는 경우, 이를 통해 클러스터 수준에서 기본 수준의 네트워크 보안이 보장됩니다.

네임스페이스 범위 네트워크 정책
애플리케이션 개발자와 네임스페이스 테넌트는 NetworkPolicy API를 사용하여 특정 네임스페이스에 대한 네트워크 정책 규칙을 정의할 수 있습니다. 네임스페이스에 대한 NetworkPolicy 의 규칙은 BaselineAdminNetworkPolicy API를 사용하여 구성된 클러스터 전체 규칙이나 클러스터 전체 AdminNetworkPolicy API에서 위임되거나 "전달된" 클러스터 전체 규칙보다 우선합니다.

1.2. 네트워크 정책이 평가되고 적용되는 방식
링크 복사

네트워크 연결이 설정되면 네트워크 공급자(기본값: OVN-Kubernetes)는 네트워크 정책 규칙에 대해 연결 세부 정보를 확인하여 연결을 처리하는 방법을 결정합니다.

OVN-Kubernetes는 다음 순서에 따라 네트워크 정책 개체에 대한 연결을 평가합니다.

  1. AdminNetworkPolicy 계층에서 일치 항목을 확인합니다.

    1. 연결이 허용 또는 거부 규칙과 일치하는 경우 해당 규칙을 따르고 평가를 중지합니다.
    2. 연결이 Pass 규칙과 일치하는 경우 NetworkPolicy 계층으로 이동합니다.

  2. NetworkPolicy 계층에서 일치 항목을 확인합니다.

    1. 연결이 규칙과 일치하면 해당 규칙을 따르고 평가를 중지합니다.
    2. 일치하는 항목이 없으면 BaselineAdminNetworkPolicy 계층으로 이동합니다.
  3. BaselineAdminNetworkPolicy 계층에서 일치 규칙을 따릅니다.

그림 1.1. OVN-Kubernetes의 네트워크 정책 평가

OVN-Kubernetes 접근 제어 목록(ACL)
View larger image
OVN-Kubernetes 접근 제어 목록(ACL)

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

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

Expand
정책 요소AdminNetworkPolicyNetworkPolicy

해당 사용자

클러스터 관리자 또는 동등 자격

네임스페이스 소유자

범위

Cluster

네임스페이스

트래픽 삭제

명시적인 거부 작업을 규칙으로 설정하여 지원됩니다.

정책 생성 시 암묵적인 Deny 격리를 통해 지원됩니다.

위임 트래픽

규칙으로 설정된 Pass 작업으로 지원됩니다.

해당 없음

트래픽 허용

명시적인 허용 작업을 규칙으로 설정하여 지원됩니다.

모든 규칙에 대한 기본 동작은 허용입니다.

정책 내 규칙 우선순위

ANP에 나타나는 순서에 따라 달라집니다. 규칙의 위치가 높을수록 우선순위가 높아집니다.

규칙은 누적적입니다.

정책 우선순위

ANP 중에서 우선순위 필드는 평가 순서를 설정합니다. 우선순위 번호가 낮을수록 정책 우선순위가 높습니다.

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

기능 우선 순위

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

ANP 이후, BANP 이전에 시행되며 ACL 2계층에서 평가됩니다.

매칭 포드 선택

네임스페이스 전반에 걸쳐 다양한 규칙을 적용할 수 있습니다.

단일 네임스페이스의 여러 포드에 걸쳐 다양한 규칙을 적용할 수 있습니다.

클러스터 이그레스 트래픽

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

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

클러스터 유입 트래픽

지원되지 않음

지원되지 않음

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

지원되지 않음

지원되지 않음

네임스페이스 선택기

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

namespaceSelector 필드를 사용하여 레이블 기반 네임스페이스 선택을 지원합니다.

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

2.1. OVN-Kubernetes AdminNetworkPolicy
링크 복사

2.1.1. AdminNetworkPolicy
링크 복사

AdminNetworkPolicy (ANP)는 클러스터 범위의 사용자 정의 리소스 정의(CRD)입니다. OpenShift Container Platform 관리자는 네임스페이스를 만들기 전에 네트워크 정책을 만들어 ANP를 사용하여 네트워크를 보호할 수 있습니다. 또한 NetworkPolicy 개체로 재정의할 수 없는 클러스터 범위 수준에서 네트워크 정책을 만들 수 있습니다.

AdminNetworkPolicy 와 NetworkPolicy 객체의 주요 차이점은 전자가 관리자를 위한 것이고 클러스터 범위인 반면, 후자는 테넌트 소유자를 위한 것이고 네임스페이스 범위라는 것입니다.

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

  • 평가 순서를 결정하는 우선순위 값입니다. 값이 낮을수록 우선순위가 높습니다.
  • 정책이 적용되는 네임스페이스 또는 네임스페이스 집합으로 구성된 포드 집합입니다.
  • 해당 주체 에 대한 모든 수신 트래픽에 적용될 수신 규칙 목록입니다.
  • 해당 주체 의 모든 이탈 트래픽에 적용될 이탈 규칙 목록입니다.
2.1.1.1. 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에는 유입 및 유출 규칙이 모두 있습니다. spec.ingress 필드에 대한 ANP 규칙은 action 필드에 대해 Pass , Deny , Allow 값을 허용합니다.
5
ingress.name 에 대한 이름을 지정합니다.
6
namespaceSelector.matchLabels 로 선택한 네임스페이스 내의 포드를 인그레스 피어로 선택하려면 podSelector.matchLabels를 지정합니다.
7
ANP에는 진입 및 진출 규칙이 모두 있습니다. spec.egress 필드에 대한 ANP 규칙은 action 필드에 대해 Pass , Deny , Allow 값을 허용합니다.

추가 리소스

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

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

2.1.1.2.1. 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 객체를 사용하여 모니터링을 차단할 수 없으며 모니터링 테넌트도 모니터링할 수 있는 항목과 할 수 없는 항목을 선택할 수 없습니다.

2.1.1.2.2. AdminNetworkPolicy Deny 예제
링크 복사

우선순위 5로 정의된 다음 ANP는 모니터링 네임스페이스에서 제한된 테넌트( security: 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입니다. 제한된 세입자 소유자는 트래픽 모니터링을 허용하도록 스스로 권한을 부여할 수 없으며, 인프라의 모니터링 서비스는 이러한 중요한 네임스페이스에서 어떤 것도 스크래핑할 수 없습니다.

강력한 Allow 예제와 결합하면 블록 모니터링 ANP는 더 낮은 우선순위 값을 갖고 더 높은 우선 순위를 갖게 되므로 제한된 테넌트는 결코 모니터링되지 않습니다.

2.1.1.2.3. AdminNetworkPolicy Pass 예제
링크 복사

우선순위 7로 정의된 다음 ANP는 모니터링 네임스페이스에서 내부 인프라 테넌트(레이블이 security: internal 인 네임스페이스)로 향하는 모든 유입 트래픽이 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입니다. 이 패스 모니터링 ANP를 사용하면 보안 수준 내부 에서 그룹화된 모든 테넌트 소유자가 네임스페이스 범위의 NetworkPolicy 객체를 사용하여 인프라 모니터링 서비스에서 메트릭을 스크래핑할지 여부를 선택할 수 있습니다.

2.2. OVN-Kubernetes BaselineAdminNetworkPolicy
링크 복사

2.2.1. BaselineAdminNetworkPolicy
링크 복사

BaselineAdminNetworkPolicy (BANP)는 클러스터 범위의 사용자 정의 리소스 정의(CRD)입니다. OpenShift Container Platform 관리자는 BANP를 사용하여 필요한 경우 NetworkPolicy 객체를 사용하여 사용자가 재정의할 수 있는 선택적 기준 네트워크 정책 규칙을 설정하고 적용할 수 있습니다. BANP에 대한 규칙 동작은 허용 또는 거부 입니다.

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

BANP를 통해 관리자는 다음을 지정할 수 있습니다.

  • 네임스페이스 또는 네임스페이스의 집합으로 구성된 주제 입니다.
  • 해당 주체 에 대한 모든 수신 트래픽에 적용될 수신 규칙 목록입니다.
  • 해당 주체 의 모든 이탈 트래픽에 적용될 이탈 규칙 목록입니다.
2.2.1.1. 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는 싱글톤 객체이므로 정책 이름은 default 여야 합니다.
2
ANP를 적용할 네임스페이스를 지정합니다.
3
BANP에는 진입 및 진출 규칙이 모두 있습니다. spec.ingress 및 spec.egress 필드에 대한 BANP 규칙은 action 필드에 대해 Deny 및 Allow 값을 허용합니다.
4
ingress.name 에 대한 이름을 지정하세요.
5
BANP 리소스를 적용할 포드를 선택할 네임스페이스를 지정합니다.
6
BANP 리소스를 적용할 포드의 podSelector.matchLabels 이름을 지정합니다.
2.2.1.2. BaselineAdminNetworkPolicy 거부 예
링크 복사

다음 BANP 싱글턴은 관리자가 내부 보안 수준에서 테넌트로 들어오는 모든 유입 모니터링 트래픽에 대한 기본 거부 정책을 설정했는지 확인합니다. "AdminNetworkPolicy Pass 예시"와 결합하면 이 거부 정책은 ANP 패스 모니터링 정책에 의해 전달되는 모든 유입 트래픽에 대한 가드레일 정책 역할을 합니다.

예 2.6. 가드레일 거부 규칙에 대한 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

작업 필드에 Pass 값이 있는 AdminNetworkPolicy 리소스를 BaselineAdminNetworkPolicy 리소스와 함께 사용하여 다중 테넌트 정책을 만들 수 있습니다. 이 다중 테넌트 정책을 사용하면 한 테넌트가 다른 테넌트로부터 데이터를 수집하지 않는 동시에 자신의 애플리케이션에서 모니터링 데이터를 수집할 수 있습니다.

관리자로서 "AdminNetworkPolicy Pass 작업 예시"와 "BaselineAdminNetwork Policy Deny 예시"를 모두 적용하는 경우 테넌트는 BANP에 앞서 평가될 NetworkPolicy 리소스를 생성할지 선택할 수 있습니다.

예를 들어, 테넌트 1은 다음과 같은 NetworkPolicy 리소스를 설정하여 유입 트래픽을 모니터링할 수 있습니다.

예 2.7. 네트워크 정책 예시

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

이 시나리오에서 테넌트 1의 정책은 "AdminNetworkPolicy Pass 작업 예시" 다음에, 보안 수준이 internal 인 테넌트로 들어오는 모든 유입 모니터링 트래픽을 거부하는 "BaselineAdminNetwork 정책 거부 예시" 전에 평가됩니다. 테넌트 1의 NetworkPolicy 객체가 있으면 해당 애플리케이션에서 데이터를 수집할 수 있습니다. 하지만 NetworkPolicy 객체가 없는 테넌트 2는 데이터를 수집할 수 없습니다. 관리자는 기본적으로 내부 테넌트를 모니터링하지 않았지만, 대신 테넌트가 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

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

클러스터 내 모든 ANP 정책에 걸친 규칙의 총 개수를 방향 및 작업 별로 그룹화한 것입니다.

ovnkube_controller_baseline_admin_network_policies_rules

  • 방향 : Ingress 또는 Egress를 지정합니다.
  • action : Allow 또는 Deny를 지정합니다.

클러스터 내 모든 BANP 정책에 걸친 규칙의 총 수를 방향 및 작업 별로 그룹화한 것입니다.

ovnkube_controller_admin_network_policies_db_objects

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

클러스터의 모든 ANP가 table_name 으로 그룹화하여 생성한 OVN Northbound 데이터베이스(nbdb) 개체의 총 수입니다.

ovnkube_controller_baseline_admin_network_policies_db_objects

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

클러스터 내 모든 BANP가 table_name 으로 그룹화하여 생성한 OVN Northbound 데이터베이스(nbdb) 객체의 총 수입니다.

2.4. AdminNetworkPolicy에 대한 Egress 노드 및 네트워크 피어
링크 복사

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

2.4.1. AdminNetworkPolicy 및 BaselineAdminNetworkPolicy에 대한 북행 교통 제어
링크 복사

ANP와 BANP는 동서 교통 제어를 지원하는 것 외에도 관리자가 클러스터를 떠나는 북행 트래픽이나 노드를 떠나 클러스터의 다른 노드로 가는 트래픽을 제어할 수 있도록 합니다. 최종 사용자는 다음을 수행할 수 있습니다.

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

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

노드 피어 관리자는 클러스터의 노드에서 포드로의 유출 트래픽을 제어할 수 있습니다. 이 방법의 장점은 클러스터에 노드를 추가하거나 삭제할 때 정책을 변경할 필요가 없다는 것입니다.

다음 예제에서는 노드 선택기 피어를 사용하여 restricted , confidential 또는 internal 보안 수준을 가진 네임스페이스를 통해 포트 6443 에서 Kubernetes API 서버로의 송신 트래픽을 허용합니다. 또한 보안 수준이 ' 제한됨 ', '기밀 ' 또는 '내부' 인 모든 네임스페이스에서 클러스터의 모든 워커 노드로의 트래픽을 거부합니다.

예 2.8. 노드 피어를 사용하여 ANP 허용 이탈의 예

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 로 라벨이 지정된 모든 포드를 지정합니다.
3
네트워크 정책에서 사용하는 레이블과 일치하는 모든 네임스페이스를 포함하는 ANP의 주제를 지정합니다. 이 예제는 restricted , confidential 또는 internal 보안 수준을 가진 모든 네임스페이스와 일치합니다.
4
matchExpressions 필드에 대한 키/값 쌍을 지정합니다.

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

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

중요

ANP 및 BANP의 네임스페이스 필드에서 빈 선택자({})를 사용할 때는 주의하세요. 빈 선택기를 사용하면 OpenShift 네임스페이스도 선택됩니다.

ANP 또는 BANP 거부 규칙에서 0.0.0.0/0 값을 사용하는 경우 거부를 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 으로 설정하여 모든 것에 대한 출구 거부를 지정합니다. Deny를 0.0.0.0/0 으로 설정하기 전에 필수 대상에 대한 Allow 규칙의 우선순위가 더 높은지 확인하세요. 이렇게 하면 Kubernetes API 및 DNS 서버를 포함한 모든 트래픽이 거부됩니다.

네트워크-투-이그레스-피어 ANP와 네트워크 피어를 사용하는 기본 BANP는 함께 다음의 이그레스 정책을 시행합니다.

  • 모든 포드는 나열된 IP 주소의 외부 DNS 서버와 통신할 수 없습니다.
  • 모든 포드는 회사 인트라넷의 나머지 부분과 통신할 수 있습니다.
  • 모든 포드는 다른 포드, 노드, 서비스와 통신할 수 있습니다.
  • 모든 포드가 인터넷과 통신할 수는 없습니다. 마지막 ANP 통과 규칙과 강력한 BANP 거부 규칙을 결합하면 클러스터 내 트래픽을 보호하는 가드레일 정책이 생성됩니다.
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
pod 이름을 지정합니다.
2
노드 및 네트워크 피어의 경우 ANP에서 북쪽으로 향하는 트래픽 제어를 출구 로만 사용할 수 있습니다.
3
ANP의 우선순위를 지정하여 평가 순서를 결정합니다. 우선순위가 낮은 규칙은 우선순위가 높습니다. ANP는 0~99의 값을 허용하며 0이 가장 높은 우선순위이고 99가 가장 낮은 우선순위입니다.
4
정책 규칙이 적용될 클러스터의 포드 세트를 지정합니다. 이 예에서 모든 네임스페이스에서 apps: all-apps 레이블이 있는 모든 포드는 정책의 주제 입니다.

2.5. AdminNetworkPolicy 문제 해결
링크 복사

2.5.1. ANP 생성 확인
링크 복사

AdminNetworkPolicy (ANP)와 BaselineAdminNetworkPolicy (BANP)가 올바르게 생성되었는지 확인하려면 다음 명령의 상태 출력을 확인하세요. oc describe anp 또는 oc describe banp .

좋은 상태는 OVN DB 플러밍이 성공적이고 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를 보려면 해당 노드의 포드 내부에 있어야 해당 노드의 데이터베이스에 있는 객체를 볼 수 있습니다.

사전 요구 사항

  • 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. 다음 명령을 실행하여 노드 정보가 포함된 포드를 나열합니다. 

    $ 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. 다음 명령을 실행하여 북쪽 방향의 데이터베이스를 살펴보려면 포드로 이동하세요. 

    $ 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
      유입 또는 유출 유형의 트래픽 방향을 지정합니다.
      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. 네트워크 정책 정의
링크 복사

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

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

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

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

네트워크 정책은 TCP(전송 제어 프로토콜), UDP(사용자 데이터그램 프로토콜), ICMP(인터넷 제어 메시지 프로토콜), SCTP(스트림 제어 전송 프로토콜) 프로토콜에만 적용됩니다. 다른 프로토콜은 영향을 받지 않습니다.

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

다음 예제 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 포드에서 수신 연결을 허용하려면 allow-same-namespace 정책과 함께 allow-from-hostnetwork 정책을 적용해야 합니다.

    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 객체를 추가합니다. 

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

3.1.2. OVN-Kubernetes 네트워크 플러그인을 사용한 네트워크 정책 최적화
링크 복사

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

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

  • podSelector 또는 namespaceSelector 사양을 기반으로 하는 모든 수신 또는 송신 규칙은 네트워크 정책에 의해 선택된 포드 수 + 수신 또는 송신 규칙에 의해 선택된 포드 수 에 비례하는 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. 네트워크 정책 생성
링크 복사

클러스터 관리자는 네임스페이스에 대한 네트워크 정책을 생성할 수 있습니다.

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

다음 구성은 NetworkPolicy 개체의 예에 주석을 달았습니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap

다음과 같습니다.

name
NetworkPolicy 오브젝트의 이름입니다.
spec.podSelector
정책이 적용되는 포드를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
ingress.from.podSelector
정책 객체가 유입 트래픽을 허용하는 포드와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스에 있는 포드를 일치시킵니다.
ingress.ports
트래픽을 수용할 하나 이상의 대상 포트 목록입니다.

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

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

참고

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

사전 요구 사항

  • 클러스터는 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. 생성된 파일에서 네트워크 정책을 정의합니다. 다음 예제에서는 모든 네임스페이스의 모든 포드에서 들어오는 트래픽을 거부합니다. 이는 다른 네트워크 정책의 구성에 의해 허용되는 크로스 포드 트래픽 외의 모든 크로스 포드 네트워킹을 차단하는 기본 정책입니다. 

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

      다음 예제 구성은 동일한 네임스페이스에 있는 모든 포드에서 수신 트래픽을 허용합니다. 

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

      다음 예제에서는 특정 네임스페이스에서 하나의 포드로의 수신 트래픽을 허용합니다. 이 정책은 namespace-y 에서 실행되는 포드에서 pod-a 레이블이 있는 포드로의 트래픽을 허용합니다. 

      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

      다음 예제 구성은 서비스에 대한 트래픽을 제한합니다. 이 정책을 적용하면 app=bookstore 및 role=api 레이블이 있는 모든 포드는 app=bookstore 레이블이 있는 포드에서만 액세스할 수 있습니다. 이 예에서 애플리케이션은 app=bookstore 및 role=api 라벨이 표시된 REST API 서버가 될 수 있습니다.

      이 예제 구성은 다음과 같은 사용 사례를 다룹니다.

      • 해당 서비스에 대한 트래픽을 해당 서비스를 사용해야 하는 다른 마이크로서비스로만 제한합니다.

      • 해당 애플리케이션에서만 데이터베이스를 사용할 수 있도록 연결을 제한합니다. 

        kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: bookstore
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: bookstore
# ...
        Copy to Clipboard Toggle word wrap

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

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

    다음과 같습니다.

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

    성공적인 출력에는 정책 개체의 이름과 생성 상태가 나열됩니다.

    참고

    클러스터 관리자 권한으로 웹 콘솔에 로그인하면 YAML에서 직접 또는 웹 콘솔의 양식을 통해 클러스터의 모든 네임스페이스에 네트워크 정책을 만들 수 있습니다.

3.2.3. 모든 네트워크 정책을 거부하는 기본 정책 만들기
링크 복사

기본적으로 모든 네트워크 거부 정책은 다른 배포된 네트워크 정책의 구성에서 허용하는 네트워크 트래픽과 호스트 네트워크 포드 간 트래픽을 제외한 모든 크로스 포드 네트워킹을 차단합니다. 이 절차는 my-project 네임스페이스에 deny-by-default 정책을 적용하여 강력한 거부 정책을 시행합니다.

주의

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

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 모든 네임스페이스의 모든 포드에서 들어오는 트래픽을 거부하는 기본 거부 정책을 정의하는 다음 YAML을 만듭니다. deny-by-default.yaml 파일에 YAML을 저장합니다. 

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

    다음과 같습니다.

    네임스페이스
    정책을 배포할 네임스페이스를 지정합니다. 예를 들어, my-project 네임스페이스.
    podSelector
    이 필드가 비어 있으면 구성이 모든 포드와 일치합니다. 따라서 해당 정책은 my-project 네임스페이스의 모든 포드에 적용됩니다.
    Ingress
    여기서 []는 수신 규칙이 지정되지 않았음을 나타냅니다. 이로 인해 모든 포드에 대한 수신 트래픽이 삭제됩니다.

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

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

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

기본적으로 거부 정책이 적용되면 app=web 레이블이 있는 포드로의 외부 클라이언트의 트래픽을 허용하는 정책을 구성할 수 있습니다.

참고

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

공용 인터넷에서 직접 또는 로드 밸런서를 사용하여 포드에 액세스하는 외부 서비스를 허용하는 정책을 구성하려면 다음 절차를 따르세요. 트래픽은 app=web 라벨이 있는 Pod에만 허용됩니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

  1. 퍼블릭 인터넷에서 직접 또는 로드 밸런서를 사용하여 트래픽이 포드에 액세스할 수 있도록 허용하는 정책을 만듭니다. web-allow-external.yaml 파일에 YAML을 저장합니다. 

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
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 역할로 사용자로 로그인하는 경우 클러스터의 모든 네임스페이스에서 네트워크 정책을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

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

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector: {}
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    app
    이 정책은 기본 네임스페이스의 app:web 포드에만 적용됩니다.
    namespaceSelector

    모든 네임스페이스의 모든 포드를 선택합니다.

    참고

    기본적으로 정책 개체에서 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. 다음 명령을 실행하여 보조 네임스페이스에 알파인 이미지를 배포하고 셸을 시작합니다. 

    $ 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

특정 네임스페이스에서 app=web 라벨이 있는 포드로의 트래픽을 허용하는 정책을 구성할 수 있습니다. 이 구성은 다음과 같은 사용 사례에 유용합니다.

  • 프로덕션 워크로드가 배포된 네임스페이스에만 프로덕션 데이터베이스로의 트래픽을 제한합니다.
  • 특정 네임스페이스에 배포된 모니터링 도구를 활성화하여 현재 네임스페이스에서 메트릭을 스크래핑합니다.
참고

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

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 적용되는 네임스페이스에서 작업하고 있습니다.

프로세스

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

    kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-prod
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          purpose: production
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    app
    이 정책은 기본 네임스페이스의 app:web 포드에만 적용됩니다.
    목적
    라벨이 purpose=production 인 네임스페이스의 포드에만 트래픽을 제한합니다.

  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. 네트워크 정책 보기
링크 복사

클러스터 관리자는 네임스페이스에 대한 네트워크 정책을 볼 수 있습니다.

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

다음 구성은 NetworkPolicy 개체의 예에 주석을 달았습니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap

다음과 같습니다.

name
NetworkPolicy 오브젝트의 이름입니다.
spec.podSelector
정책이 적용되는 포드를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
ingress.from.podSelector
정책 객체가 유입 트래픽을 허용하는 포드와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스에 있는 포드를 일치시킵니다.
ingress.ports
트래픽을 수용할 하나 이상의 대상 포트 목록입니다.

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

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

참고

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

사전 요구 사항

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

프로세스

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

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

      $ oc get networkpolicy
      Copy to Clipboard Toggle word wrap

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

      $ 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 
      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
참고

클러스터 관리자 권한으로 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에 있는 네트워크 정책을 YAML에서 직접 보거나 웹 콘솔의 양식을 통해 볼 수 있습니다.

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

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

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

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

참고

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

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

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

    $ oc get network policy -n <namespace>
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

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

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

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

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

      다음과 같습니다.

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

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

      $ oc edit network policy <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>
    선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 이를 사용하여 네임스페이스를 지정합니다.
참고

클러스터 관리자 권한으로 웹 콘솔에 로그인하면 클러스터의 모든 네임스페이스에서 네트워크 정책을 YAML에서 직접 편집하거나 웹 콘솔의 작업 메뉴를 통해 정책을 편집할 수 있습니다.

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

다음 구성은 NetworkPolicy 개체의 예에 주석을 달았습니다. 

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-27107
spec:
  podSelector:
    matchLabels:
      app: mongodb
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: app
    ports:
    - protocol: TCP
      port: 27017
Copy to Clipboard Toggle word wrap

다음과 같습니다.

name
NetworkPolicy 오브젝트의 이름입니다.
spec.podSelector
정책이 적용되는 포드를 설명하는 선택기입니다. 정책 오브젝트는 NetworkPolicy 오브젝트가 정의된 프로젝트에서 Pod만 선택할 수 있습니다.
ingress.from.podSelector
정책 객체가 유입 트래픽을 허용하는 포드와 일치하는 선택기입니다. 선택기는 NetworkPolicy와 동일한 네임스페이스에 있는 포드를 일치시킵니다.
ingress.ports
트래픽을 수용할 하나 이상의 대상 포트 목록입니다.

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

클러스터 관리자는 네임스페이스에서 네트워크 정책을 삭제할 수 있습니다.

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

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

참고

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

사전 요구 사항

  • 클러스터는 NetworkPolicy 객체를 지원하는 네트워크 플러그인(예: OVN-Kubernetes 네트워크 플러그인)을 사용하며, 모드: NetworkPolicy가 설정되어 있습니다.
  • OpenShift CLI(oc)를 설치합니다.
  • admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • 네트워크 정책이 존재하는 네임스페이스에서 작업하고 있습니다.

프로세스

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

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

    다음과 같습니다.

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

클러스터 관리자 권한으로 웹 콘솔에 로그인하면 YAML에서 직접 클러스터의 네임스페이스에 있는 네트워크 정책을 삭제하거나, 작업 메뉴를 통해 웹 콘솔의 정책을 통해 삭제할 수 있습니다.

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 및 서비스에서 격리하도록 프로젝트를 구성할 수 있습니다.

사전 요구 사항

  • 클러스터는 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 및 BaselineAdminNetworkPolicy 사용자 정의 리소스(CR)에 대한 허용 및 거부 ACL 이벤트를 노출합니다. 로깅은 또한 AdminNetworkPolicy (ANP) CR에 대한 allow , deny , pass 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 로깅 구현은 네트워크에 대한 액세스 제어 목록(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

다음과 같습니다.

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

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

패킷 정보를 추출하기 위해 흐름 매개변수에서 사용되는 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

다음과 같습니다.

  • <proto>는 프로토콜을 나타냅니다. 유효한 값은 tcp 와 udp 입니다.
  • vlan_tci=0x0000은 내부 Pod 네트워크 트래픽에 대한 VLAN ID가 설정되지 않았기 때문에 VLAN 헤더를 0 으로 나타냅니다.
  • <src_mac>은 MAC(Media Access Control) 주소에 대한 소스를 지정합니다.
  • <source_mac>은 MAC 주소의 대상을 지정합니다.
  • <source_ip>는 소스 IP 주소를 나열합니다.
  • <target_ip>는 대상 IP 주소를 나열합니다.
  • <tos_dscp>는 다른 트래픽보다 특정 네트워크 트래픽을 분류하고 우선순위를 지정하기 위한 DSCP(Differentiated Services Code Point) 값을 나타냅니다.
  • <tos_ecn> 은 네트워크의 혼잡한 트래픽을 나타내는 명시적 혼잡 알림(ECN) 값을 나타냅니다.
  • <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 매뉴얼 페이지에서 ovs-fields를 참조하세요.

네트워크 정책에 대한 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

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

allow

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

통과

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

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에 도달하고 로깅 주석에 설정된 작업 기준을 충족할 때마다 로그가 생성됩니다. 예를 들어, 레이블이 tenant: product-development 인 네임스페이스 중 하나가 레이블이 tenant: backend-storage 인 네임스페이스에 액세스하는 이벤트가 발생하면 로그가 생성됩니다.

참고

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

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

Expand
방향Rule

Ingress

규칙0
테넌트 제품 개발 및 고객 에서 테넌트 백엔드 저장소 로 허용; Ingress0: 허용
Rule1
`product-security`에서 `backend-storage` 테넌트로 전달; Ingress1: 전달
Rule2
모든 포드에서 Ingress 거부; Ingress2: 거부

Egress

규칙0
제품 개발 허용 ; Egress0: 허용
Rule1
제품 보안 으로 전달; Egress1: 전달
Rule2
다른 모든 포드로의 이탈을 거부합니다. Egress2: 거부

예 4.2. Ingress:0 및 Egress:0을 포함하는 anp-tenant-log 라는 AdminNetworkPolicy 의 허용 작업에 대한 ACL 로그 항목 예

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 의 Pass 작업에 대한 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 의 Deny 작업에 대한 ACL 로그 항목 예

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. 감사 로깅 AdminNetworkPolicy 주석
주석현재의

k8s.ovn.org/acl-logging

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

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

4.4. BaselineAdminNetworkPolicy audit logging
링크 복사

다음 예와 같이 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

규칙0
테넌트 DNS 에서 테넌트 워크로드 로 허용; Ingress0: 허용
Rule1
모든 포드에서 테넌트 워크로드 거부; Ingress1: 거부

Egress

규칙0
모든 포드에 거부; Egress0: 거부

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

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. Egress:0 및 Ingress:1을 사용하여 기본 BANP의 허용 작업에 대한 ACL 허용 로그 항목 예

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

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

deny
선택 사항: 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 와 같은 두 개의 포드와 생성 상태가 나열됩니다.

  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. 기본 네임스페이스의 client 라는 포드에서 이전 명령의 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_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 사용자 정의 리소스(CR) 보기
링크 복사

클러스터에서 EgressFirewall CR을 볼 수 있습니다.

사전 요구 사항

  • 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 사용자 정의 리소스(CR) 편집
링크 복사

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

사전 요구 사항

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

프로세스

  1. 해당 프로젝트의 EgressFirewall CR 이름을 찾으세요. <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 CR 제거
링크 복사

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

사전 요구 사항

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

프로세스

  1. 해당 프로젝트의 EgressFirewall CR 이름을 찾으세요. <project>를 프로젝트 이름으로 바꿉니다. 

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

  2. 다음 명령을 입력하여 EgressFirewall CR을 삭제합니다. <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 클러스터 외부의 호스트에 연결할 수 없습니다.
  • 포드는 특정 외부 호스트에만 연결할 수 있습니다.

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

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

  • CIDR 형식의 IP 주소 범위
  • IP 주소로 확인되는 DNS 이름
  • 포트 번호
  • 다음 프로토콜 중 하나인 프로토콜 : TCP, UDP 및 SCTP
5.4.1.1. 송신 방화벽의 제한
링크 복사

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

  • EgressFirewall 오브젝트를 두 개 이상 보유할 수 있는 프로젝트는 없습니다.
  • 송신 방화벽 규칙은 라우터를 통과하는 트래픽에는 적용되지 않습니다. Route CR 오브젝트를 생성할 권한이 있는 모든 사용자는 허용되지 않은 대상을 가리키는 경로를 생성하여 송신 방화벽 정책 규칙을 바이패스할 수 있습니다.
  • 송신 방화벽은 호스트 네트워크 네임스페이스에 적용되지 않습니다. 호스트 네트워킹이 활성화된 Pod는 송신 방화벽 규칙의 영향을 받지 않습니다.

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

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

    apiVersion: k8s.ovn.org/v1
kind: EgressFirewall
metadata:
  name: default
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <api_server_address_range>
    1 
    
    type: Allow
# ...
  - to:
      cidrSelector: 0.0.0.0/0
    2 
    
    type: Deny
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    <namespace>
    송신 방화벽의 네임스페이스를 지정합니다.
    <api_server_address_range>
    OpenShift Container Platform API 서버를 포함하는 IP 주소 범위입니다.
    <cidrSelector>

    OpenShift Container Platform API 서버에 대한 액세스를 방지하는 글로벌 거부 규칙을 설정하려면 값 0.0.0.0/0 을 지정합니다.

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

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

  • 프로젝트당 최대 50개의 규칙이 있는 최대 하나의 EgressFirewall 오브젝트를 정의할 수 있습니다.
  • Red Hat OpenShift Networking에서 공유 게이트웨이 모드로 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우, 반환 수신 응답은 송신 방화벽 규칙의 영향을 받습니다. 송신 방화벽 규칙이 수신 응답 대상 IP를 삭제하면 트래픽이 삭제됩니다.
  • 일반적으로, 송신 방화벽 정책에서 DNS(도메인 이름 서버) 이름을 사용해도 CoreDNS를 통한 로컬 DNS 확인에는 영향을 미치지 않습니다. 하지만 이그레스 방화벽 정책이 도메인 이름을 사용하고 외부 DNS 서버가 영향을 받는 포드에 대한 DNS 확인을 처리하는 경우 DNS 서버의 IP 주소에 대한 액세스를 허용하는 이그레스 방화벽 규칙을 포함해야 합니다.

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

kube-node-lease , kube-public , kube-system , openshift 및 openshift- 프로젝트에서 EgressFirewall 리소스가 생성됩니다.

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

OVN-Kubernetes는 정의된 순서대로, 처음부터 끝까지 이그레스 방화벽 정책 규칙을 평가합니다. 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 주소가 자주 변경되지 않는 도메인에만 권장됩니다.
5.4.1.3.1. 향상된 DNS 확인 및 와일드카드 도메인 이름 확인
링크 복사

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

이 상황에서 OVN-Kubernetes 클러스터 관리자는 송신 방화벽 정책 규칙에 사용된 각 고유 DNS 이름에 대해 DNSNameResolver 사용자 정의 리소스 객체를 생성합니다. 이 사용자 정의 리소스는 다음 정보를 저장합니다.

중요

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

Red Hat Technology Preview 기능의 지원 범위에 대한 자세한 내용은 다음 링크를 참조하세요.

DNSNameResolver CR 정의 예

apiVersion: networking.openshift.io/v1alpha1
kind: DNSNameResolver
spec:
  name: www.example.com.
status:
  resolvedNames:
  - dnsName: www.example.com.
    resolvedAddress:
    - ip: "1.2.3.4"
      ttlSeconds: 60
      lastLookupTime: "2023-08-08T15:07:04Z"
Copy to Clipboard Toggle word wrap

다음과 같습니다.

<name>
DNS 이름을 지정합니다. 이는 표준 DNS 이름이거나 와일드카드 DNS 이름일 수 있습니다. 와일드카드 DNS 이름의 경우 DNS 이름 확인 정보에는 와일드카드 DNS 이름과 일치하는 모든 DNS 이름이 포함됩니다.
<dnsName>
spec.name 필드와 일치하는 확인된 DNS 이름을 지정합니다. spec.name 필드에 와일드카드 DNS 이름이 포함되어 있으면 확인 시 와일드카드 DNS 이름과 일치하는 표준 DNS 이름이 포함된 여러 dnsName 항목이 생성됩니다. 와일드카드 DNS 이름도 성공적으로 확인될 수 있는 경우 이 필드에는 와일드카드 DNS 이름도 저장됩니다. <ip> DNS 이름과 연결된 현재 IP 주소를 지정합니다.
<ttlSeconds>
마지막 TTL(수명) 기간을 지정합니다.
<lastLookupTime>
마지막 조회 시간을 지정합니다.

DNS 확인 중에 쿼리의 DNS 이름이 DNSNameResolver CR에 정의된 이름과 일치하는 경우, 이전 정보가 CR 상태 필드에 적절하게 업데이트됩니다. 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: <ovn>
spec:
  egress: <egress_rules>
    ...
Copy to Clipboard Toggle word wrap

다음과 같습니다.

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

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

송신 정책 규칙 스탠자

egress:
- type: <type>
  to:
    cidrSelector: <cidr_range>
    dnsName: <dns_name>
    nodeSelector: <label_name>: <label_value>
  ports: <optional_port>
      ...
Copy to Clipboard Toggle word wrap

다음과 같습니다.

<type>
규칙의 유형을 지정합니다. 값은 Allow 또는 Deny여야 합니다.
<to>
cidrSelector 필드 또는 dnsName 필드를 지정하는 송신 트래픽 일치 규칙을 설명하는 스탠자입니다. 동일한 규칙에서 두 필드를 모두 사용할 수 없습니다.
<cidr_range>
CIDR 형식의 IP 주소 범위를 지정합니다.
<dns_name>
DNS 도메인 이름을 지정합니다.
<nodeSelector>
사용자가 정의하는 키와 값 쌍인 레이블을 지정합니다. 라벨은 포드와 같은 객체에 붙습니다. nodeSelector를 사용하면 하나 이상의 노드 레이블을 선택하여 Pod에 첨부할 수 있습니다.
<ports>
규칙에 대한 네트워크 포트와 프로토콜 컬렉션을 설명하는 선택적 필드를 지정합니다.

포트 스탠자

ports:
- port:
  protocol:
Copy to Clipboard Toggle word wrap

다음과 같습니다.

<port>
80 이나 443 과 같은 네트워크 포트를 지정합니다. 이 필드에 값을 지정하는 경우 프로토콜 필드에도 값을 지정해야 합니다.
<protocol>
네트워크 프로토콜을 지정합니다. 값은 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

다음과 같습니다.

<egress>
송신 방화벽 정책 규칙 개체의 컬렉션을 지정합니다.

다음 예에서는 트래픽이 TCP 프로토콜 및 대상 포트 80 또는 임의의 프로토콜 및 대상 포트 443을 사용하는 경우 172.16.1.1 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. nodeSelector를 사용한 EgressFirewall CR 예시
링크 복사

클러스터 관리자는 nodeSelector 필드를 사용하여 레이블을 지정하여 클러스터의 노드에 대한 송신 트래픽을 허용하거나 거부할 수 있습니다. 레이블은 하나 이상의 노드에 적용될 수 있습니다. 레이블은 노드 IP 주소별로 수동 규칙을 추가하는 대신 노드 선택기를 사용하여 송신 방화벽 뒤에 있는 포드가 호스트 네트워크 포드에 액세스할 수 있도록 하는 레이블을 만들 수 있으므로 유용할 수 있습니다. 다음은 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

5.4.3. EgressFirewall 사용자 정의 리소스(CR) 생성
링크 복사

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

중요

프로젝트에 이미 EgressFirewall 리소스가 있는 경우 기존 정책을 편집하여 Egress 방화벽 규칙을 변경해야 합니다.

사전 요구 사항

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

프로세스

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

    1. <policy_name>이 송신 정책 규칙을 설명하는 <policy_name>.yaml 파일을 만듭니다.
    2. 파일에서 EgressFirewall 객체를 정의합니다.

  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 간 클러스터 트래픽과 클러스터 외부의 Pod와 IPsec 엔드포인트 간 외부 트래픽을 모두 암호화할 수 있습니다. OVN-Kubernetes 클러스터 네트워크의 노드 간 모든 Pod 간 네트워크 트래픽은 전송 모드 에서 IPsec으로 암호화됩니다.

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

참고

libreswan 과 NetworkManager-libreswan 패키지에 서로 다른 OpenShift Container Platform 버전이 있는 경우 클러스터를 OpenShift Container Platform 4.19로 업그레이드하면 두 번의 연속적인 컴퓨트 노드 재부팅 작업이 발생합니다. 첫 번째 재부팅의 경우, 클러스터 네트워크 운영자(CNO)는 IPsec 구성을 컴퓨팅 노드에 적용합니다. 두 번째 재부팅의 경우, MCO(Machine Config Operator)는 클러스터에 최신 머신 구성을 적용합니다.

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

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

자세한 내용은 제어 평면 전용 업데이트 수행을 참조하세요.

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

  • IBM Cloud®에서 IPsec은 NAT-T(네트워크 주소 변환-트래버설)만 지원합니다. 이 플랫폼에서는 ESP(Encapsulating Security Payload)가 지원되지 않습니다.
  • 클러스터가 Red Hat OpenShift Container Platform에 대한 호스팅 제어 플레인을 사용하는 경우, Pod 간 또는 외부 호스트에 대한 트래픽의 IPsec 암호화에 IPsec이 지원되지 않습니다.
  • 하나 이상의 인터페이스가 Open vSwitch(OVS)에 연결된 경우 모든 네트워크 인터페이스에서 ESP 하드웨어 오프로드를 사용할 수 없습니다. 클러스터에 IPsec을 활성화하면 OVS에 연결된 인터페이스에서 IPsec을 사용할 수 있습니다. 기본적으로 OpenShift Container Platform은 OVS에 연결된 모든 인터페이스에서 ESP 하드웨어 오프로드를 비활성화합니다.
  • OVS에 연결되지 않은 네트워크 인터페이스에 대해 IPsec을 활성화한 경우, 클러스터 관리자는 OVS에 연결되지 않은 각 인터페이스에서 ESP 하드웨어 오프로드를 수동으로 비활성화해야 합니다.

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

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

6.1. 작동 모드
링크 복사

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

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

비활성화됨

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

제공됨

full

Pod 간 트래픽은 "Pod 간 IPsec으로 암호화된 네트워크 트래픽 흐름 유형"에 설명된 대로 암호화됩니다. IPsec에 대한 필수 구성 단계를 완료한 후 외부 노드에 대한 트래픽을 암호화할 수 있습니다.

없음

외부

IPsec에 대한 필수 구성 단계를 완료한 후 외부 노드에 대한 트래픽을 암호화할 수 있습니다.

없음

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

외부 호스트로의 트래픽 암호화를 위한 IPsec 지원의 경우 다음 필수 구성 요소를 충족하는지 확인하세요.

  • OVN-Kubernetes 네트워크 플러그인의 ovnKubernetesConfig.gatewayConfig 사양에서 routingViaHost=true를 설정합니다.

  • NMState Operator를 설치합니다. 이 연산자는 IPsec 구성을 지정하는 데 필요합니다. 자세한 내용은 Kubernetes NMState Operator를 참조하세요.

    참고

    NMState Operator는 Google Cloud에서 IPsec을 구성하는 데만 지원됩니다.

  • 부탄도구( 부탄 )가 설치되었습니다. 부탄을 설치하려면 부탄 설치를 참조하세요.

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

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

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

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

UDP

500

IPsec IKE 패킷

4500

IPsec NAT-T 패킷

ESP

해당 없음

IPsec 캡슐화 보안 페이로드(ESP)

6.4. Pod 간 트래픽을 위한 IPsec 암호화
링크 복사

다음 섹션에서는 Pod-to-Pod 트래픽의 IPsec 암호화에 대해 구체적으로 어떤 Pod-to-Pod 트래픽이 암호화되는지, 어떤 종류의 암호화 프로토콜이 사용되는지, X.509 인증서가 어떻게 처리되는지 설명합니다. 이 섹션은 클러스터와 외부 호스트 간의 IPsec 암호화에는 적용되지 않습니다. 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 모드는 전송 모드 로, 원래 패킷의 IP 헤더에 ESP(Encapsulated Security Payload) 헤더를 추가하여 종단 간 통신을 암호화하고 패킷 데이터를 암호화하는 모드입니다. OpenShift Container Platform은 현재 Pod 간 통신을 위해 IPsec 터널 모드를 사용하거나 지원하지 않습니다.

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

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

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

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

OpenShift Container Platform은 외부 호스트로 전송되는 트래픽을 암호화하기 위해 IPsec을 사용하여 전송 중인 데이터의 기밀성과 무결성을 보장합니다. 이 기능을 사용하려면 사용자가 제공해야 하는 X.509 인증서가 필요합니다.

6.5.1. 지원 플랫폼
링크 복사

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

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

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

클러스터가 Red Hat OpenShift Container Platform에 대한 호스팅 제어 평면을 사용하는 경우 외부 호스트에 대한 트래픽 암호화를 위해 IPsec을 구성하는 것은 지원되지 않습니다.

6.5.2. 제한
링크 복사

다음 금지 사항을 준수하세요.

  • 현재 NMState 운영자는 외부 트래픽에 대한 IPsec을 구성할 때 IPv6 구성을 지원하지 않습니다.
  • 제공된 인증서 번들의 인증서 일반 이름(CN)은 ovs_ 접두사로 시작하면 안 됩니다. 이 이름은 각 노드의 NSS(Network Security Services) 데이터베이스에 있는 Pod 간 IPsec CN 이름과 충돌할 수 있기 때문입니다.

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

클러스터 관리자는 클러스터와 외부 IPsec 엔드포인트 간에 Pod 간 IPsec 암호화를 활성화할 수 있습니다.

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

  • 전체 : Pod 간 및 외부 트래픽 암호화
  • 외부 : 외부 트래픽 암호화
참고

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

전체 모드에서 IPsec을 활성화한 경우 클러스터 관리자는 networks.operator.openshift.io 에 전체 스키마를 추가하여 모드에 대한 옵션을 구성할 수 있습니다. 전체 스키마는 캡슐화 매개변수를 지원합니다. 이 매개변수를 사용하여 IPsec 트래픽에 대한 NAT-T(네트워크 주소 변환-트래버설) 캡슐화를 구성할 수 있습니다. 캡슐화 매개변수는 다음 값을 지원합니다.

  • '자동' 은 기본값이며 libreswan이 노드 내 트래픽에서 NAT(네트워크 주소 변환) 패킷을 감지하면 UDP 캡슐화를 활성화합니다.
  • 노드에서 사용 가능한 모든 트래픽 유형에 대해 UDP 캡슐화를 항상 활성화합니다. 이 옵션은 노드에서 NAT 패킷을 감지하기 위해 libreswan 에 의존하지 않습니다.

사전 요구 사항

  • 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 1
    외부 호스트로의 트래픽을 암호화하려면 '외부'를 지정하고, 포드 간 트래픽과 선택적으로 외부 호스트로의 트래픽을 암호화하려면 '전체'를 지정합니다. 기본적으로 IPsec은 비활성화되어 있습니다.

    IPsec이 전체 모드에서 활성화되고 캡슐화가 항상 으로 설정된 구성 예

    $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Full",
          "full":{
            "encapsulation": "Always"
          }}}}}}'
    Copy to Clipboard Toggle word wrap

  2. "외부 트래픽에 대한 IPsec 암호화 구성" 절차를 완료하여 IPsec을 사용하여 외부 트래픽을 암호화합니다.

검증

  1. OVN-Kubernetes 데이터 플레인 포드의 이름을 찾으려면 다음 명령을 입력하세요. 

    $ 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을 구성할 때 클러스터의 포드 간에 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

    여기서: <XXXXX>는 이전 단계의 포드에 대한 무작위 문자 시퀀스를 지정합니다.

    명령이 성공적으로 실행되면 상태가 true 로 표시됩니다.

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

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

참고

머신 구성을 적용한 후, 머신 구성 운영자(MCO)가 클러스터에서 영향을 받는 노드를 재부팅하여 새로운 머신 구성을 롤아웃합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 로컬 컴퓨터에 부탄 도구를 설치했습니다.
  • 클러스터에 NMState Operator를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 클러스터에 로그인합니다.
  • IPsec 엔드포인트에 대한 기존 PKCS#12 인증서와 PEM(Privacy Enhanced Mail) 형식의 CA 인증서가 있습니다.
  • 클러스터에서 전체 모드 또는 외부 모드로 IPsec을 활성화했습니다.
  • OVN-Kubernetes 네트워크 플러그인의 ovnKubernetesConfig.gatewayConfig 사양에서 routingViaHost 매개변수를 true 로 설정해야 합니다.

프로세스

  1. NMState Operator 노드 네트워크 구성 정책으로 IPsec 구성을 만듭니다. 자세한 내용은 nmstatectl을 사용하여 IPsec 기반 VPN 연결 구성을 참조하세요.

    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>"
  desiredState:
    interfaces:
    - name: <interface_name>
      type: ipsec
      libreswan:
        left: <cluster_node>
        leftid: '%fromcert'
        leftrsasigkey: '%cert'
        leftcert: left_server
        leftmodecfgclient: false
        right: <external_host>
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address>/32
        ikev2: insist
        type: transport
      Copy to Clipboard Toggle word wrap

      다음과 같습니다.

      kubernetes.io/hostname
      정책을 적용할 호스트 이름을 지정합니다. 이 호스트는 IPsec 구성에서 왼쪽 호스트 역할을 합니다.
      name
      호스트에 생성할 인터페이스의 이름을 지정합니다.
      왼쪽
      클러스터 측에서 IPsec 터널을 종료하는 클러스터 노드의 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [주체 대체 이름] 과 일치해야 합니다.
      right
      host.example.com 과 같은 외부 호스트 이름을 지정합니다. 이름은 제공된 PKCS#12 인증서의 SAN [주체 대체 이름] 과 일치해야 합니다.
      rightsubnet

      외부 호스트의 IP 주소(예: 10.1.2.3/32) 를 지정합니다.

      NMState IPsec 터널 구성 예

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

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

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

  2. 각 호스트의 네트워크 보안 서비스(NSS) 데이터베이스에 추가할 다음 인증서 파일을 제공합니다. 이러한 파일은 다음 단계에서 부탄 구성의 일부로 가져옵니다.

    • left_server.p12 : IPsec 엔드포인트에 대한 인증서 번들
    • ca.pem : 인증서에 서명한 인증 기관
  3. 클러스터에 인증서를 추가하려면 머신 구성을 만듭니다.

  4. 마운트된 비밀 파일에서 비밀번호를 읽습니다. 

    $ password=$(cat run/secrets/<left_server_password>)
    Copy to Clipboard Toggle word wrap
    • left_server_password :: 비밀번호가 포함된 파일의 이름입니다. 이 파일은 마운트된 비밀에 존재합니다.

  5. Red Hat Enterprise Linux(RHEL)에 미리 패키지되어 있는 pk12util 도구를 사용하여 다음 명령을 입력하여 PKCS#12 파일을 보호하는 비밀번호를 지정합니다. <password> 값을 자신의 비밀번호로 바꿔야 합니다. 

    $ pk12util -W "<password>" -i /etc/pki/certs/left_server.p12 -d /var/lib/ipsec/nss/
    Copy to Clipboard Toggle word wrap

  6. 제어 평면과 컴퓨팅 노드에 대한 Butane 구성 파일을 만들려면 다음 명령을 입력하세요.

    참고

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

    $ for role in master worker; do
  cat >> "99-ipsec-${role}-endpoint-config.bu" <<-EOF
  variant: openshift
  version: 4.19.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

  7. 이전 단계에서 생성한 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

  8. 클러스터에 머신 구성을 적용하려면 다음 명령을 입력하세요. 

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

    MCO(머신 구성 운영자)가 각 머신 구성 풀의 머신을 업데이트하면서 각 노드를 하나씩 재부팅합니다. 외부 IPsec 연결을 사용하려면 모든 노드가 업데이트될 때까지 기다려야 합니다.

검증

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

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

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

    참고

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

  2. 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 확장을 적용했는지 확인하세요. 

      $ 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.9. 외부 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.10. IPsec 암호화 비활성화
링크 복사

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

사전 요구 사항

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

프로세스

  1. IPsec 암호화를 비활성화하려면 다음 옵션 중 하나를 선택하세요.

    1. ipsecConfig.mode 매개변수가 External 또는 Full 로 설정되어 있고 ipsecConfig.full 스키마가 networks.operator.openshift.io 에 추가되지 않은 경우 다음 명령을 입력합니다. 

      $ oc patch networks.operator.openshift.io cluster --type=merge -p \
  '{
  "spec":{
    "defaultNetwork":{
      "ovnKubernetesConfig":{
        "ipsecConfig":{
          "mode":"Disabled"
        }}}}}'
      Copy to Clipboard Toggle word wrap

    2. ipsecConfig.mode 매개변수가 Full 로 설정되고 ipsecConfig.full 구성이 networks.operator.openshift.io 에 추가된 경우 다음 명령을 입력합니다. 

      $ oc patch networks.operator.openshift.io cluster --type='json' -p \
      '[{"op": "remove", "path": "/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig/full"},
      {"op": "replace", "path": "/spec/defaultNetwork/ovnKubernetesConfig/ipsecConfig/mode", "value": "Disabled"}]'
      Copy to Clipboard Toggle word wrap
  2. 선택 사항: IP 패킷의 IPsec ESP(Encapsulating Security Payload) 헤더에서 더 이상 오버헤드가 발생하지 않으므로 클러스터 MTU 크기를 46 바이트만큼 늘릴 수 있습니다.

7장. 제로 트러스트 네트워킹
링크 복사

제로 트러스트는 모든 상호작용이 신뢰할 수 없는 상태에서 시작된다는 전제에 기반하여 보안 아키텍처를 설계하는 접근 방식입니다. 이는 통신이 방화벽 내부에서 시작되는지 여부에 따라 신뢰성을 판단하는 기존 아키텍처와는 대조적입니다. 더 구체적으로 말하면, 제로 트러스트는 암묵적 신뢰 모델과 일회성 인증에 의존하는 보안 아키텍처의 격차를 메우려고 시도합니다.

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

제로 트러스트 네트워킹의 다음과 같은 대상 기능을 살펴보세요.

7.1. 신뢰의 뿌리
링크 복사

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

영향력:

  • OpenShift 컨테이너 플랫폼: OpenShift는 클러스터 리소스를 보호하는 데 사용되는 클러스터 CA를 설치 시 생성합니다. 하지만 OpenShift Container Platform은 클러스터의 서비스에 대한 인증서를 생성하고 서명할 수도 있으며, 요청 시 클러스터 CA 번들을 Pod에 삽입할 수도 있습니다. OpenShift Container Platform에서 생성하고 서명한 서비스 인증서의 TTL(수명)은 26개월이며 13개월마다 자동으로 교체됩니다. 필요한 경우 수동으로 회전할 수도 있습니다.
  • OpenShift cert-manager 연산자 : cert-manager를 사용하면 신뢰할 수 있는 외부 루트에서 서명된 키를 요청할 수 있습니다. 외부 발급자와 통합할 수 있는 구성 가능한 발급자가 많고 위임된 서명 인증서로 실행하는 방법도 있습니다. cert-manager API는 제로 트러스트 네트워킹에서 다른 소프트웨어가 필요한 인증서를 요청하는 데 사용할 수 있습니다(예: Red Hat OpenShift Service Mesh). 또는 고객 소프트웨어에서 직접 사용할 수도 있습니다.

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

모든 회선 트래픽이 암호화되어 있고, 종단점이 식별 가능한지 확인하세요. 이에 대한 예로는 상호 인증 방법인 mTLS(Mutual TLS)가 있습니다.

영향력:

7.3. 식별 및 인증
링크 복사

CA를 사용하여 인증서를 생성할 수 있는 기능을 갖추면 이를 사용하여 연결의 다른 쪽(사용자 또는 클라이언트 컴퓨터)의 신원을 확인하여 신뢰 관계를 구축할 수 있습니다. 또한 인증서가 손상된 경우 사용을 제한하기 위해 인증서 수명 주기를 관리해야 합니다.

영향력:

  • OpenShift Container Platform: 클라이언트가 신뢰할 수 있는 엔드포인트와 통신하고 있는지 확인하기 위한 클러스터 서명 서비스 인증서입니다 . 이렇게 하려면 서비스가 SSL/TLS를 사용해야 하고 클라이언트가 클러스터 CA를 사용해야 합니다. 클라이언트 신원은 다른 수단을 통해 제공되어야 합니다.
  • Red Hat Single Sign-On : 기업 사용자 디렉토리나 타사 ID 공급자와의 요청 인증 통합을 제공합니다.
  • Red Hat OpenShift Service Mesh : mTLS에 대한 연결의 투명한 업그레이드 , 자동 회전, 사용자 정의 인증서 만료 및 JSON 웹 토큰(JWT)을 통한 요청 인증.
  • OpenShift cert-manager Operator : 애플리케이션에서 사용할 인증서를 생성하고 관리합니다. 인증서는 CRD로 제어하고 비밀로 마운트할 수 있으며, 애플리케이션을 변경하여 cert-manager API와 직접 상호 작용할 수 있습니다.

7.4. 군 간 승인
링크 복사

요청자의 신원을 기반으로 서비스 접근을 제어할 수 있는 것이 중요합니다. 이 작업은 플랫폼을 통해 수행되므로 각 애플리케이션에서 이를 구현할 필요가 없습니다. 이를 통해 정책에 대한 감사 및 검사가 더 좋아집니다.

영향력:

7.5. 거래 수준 검증
링크 복사

연결을 식별하고 인증하는 기능 외에도 개별 거래에 대한 액세스를 제어하는 데도 유용합니다. 여기에는 소스, 관찰 가능성, 거래가 올바르게 형성되었는지에 대한 의미적 검증에 따른 속도 제한이 포함될 수 있습니다.

영향력:

7.6. 위험성 평가
링크 복사

클러스터 내 보안 정책의 수가 증가함에 따라 정책이 허용하는 것과 거부하는 것을 시각화하는 것이 점점 더 중요해지고 있습니다. 이러한 도구를 사용하면 클러스터 보안 정책을 보다 쉽게 만들고, 시각화하고, 관리할 수 있습니다.

영향력:

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

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

영향력:

7.8. 지속적이고 회고적인 평가를 위한 관찰성
링크 복사

클러스터를 실행한 후에는 트래픽을 관찰하고 트래픽이 정의된 규칙을 준수하는지 확인할 수 있어야 합니다. 이는 침입 탐지, 포렌식에 중요하며 운영 부하 관리에도 도움이 됩니다.

영향력:

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

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

클러스터에서 서비스를 실행하는 소프트웨어가 손상되지 않았다고 믿을 수 있는 것이 중요합니다. 예를 들어, 인증된 이미지가 신뢰할 수 있는 하드웨어에서 실행되도록 해야 하며, 엔드포인트 특성에 따라 엔드포인트와의 연결만 허용하는 정책이 필요할 수 있습니다.

영향력:

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

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

클러스터가 하위 도메인에 대한 CA를 생성하도록 허용하여 클러스터 외부로 신뢰를 확장할 수 있습니다. 또는 클러스터의 워크로드 ID를 원격 엔드포인트에 증명할 수도 있습니다.

영향력:

  • OpenShift cert-manager 연산자 : 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