8.2. 관리자 네트워크 정책
8.2.1. OVN-Kubernetes AdminNetworkPolicy
8.2.1.1. AdminNetworkPolicy
관리NetworkPolicy (ANP)는 클러스터 범위의 CRD(사용자 정의 리소스 정의)입니다. AWS 관리자의 Red Hat OpenShift Service는 네임스페이스를 생성하기 전에 네트워크 정책을 생성하여 ANP를 사용하여 네트워크를 보호할 수 있습니다. 또한 NetworkPolicy 오브젝트에서 덮어쓸 수 없는 클러스터 범위 수준에서 네트워크 정책을 생성할 수 있습니다.
AdminNetworkPolicy 와 NetworkPolicy 오브젝트의 주요 차이점은 전자는 관리자용이고 후자는 테넌트 소유자용이고 네임스페이스 범위가 지정되는 동안 클러스터 범위라는 것입니다.
관리자는 ANP를 사용하여 다음을 지정할 수 있습니다.
-
평가 순서를 결정하는
우선순위값입니다. 우선 순위가 가장 높은 값이 낮을 수 있습니다. - 정책이 적용되는 네임스페이스 또는 네임스페이스 세트로 구성된 Pod 세트입니다.
-
제목을 향하는 모든 인그레스 트래픽에 적용할 수신 규칙 목록입니다. -
제목의 모든 송신 트래픽에 적용할 송신 규칙
목록입니다.
AdminNetworkPolicy 예
예 8.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
- 1
- ANP의 이름을 지정합니다.
- 2
spec.priority필드는 클러스터의 0-99 값에서 최대 100개의 ANP를 지원합니다. 우선 순위가 가장 높은 값이 낮을 수 있습니다. 동일한 우선 순위로AdminNetworkPolicy를 생성하면 결정적이지 않은 결과가 생성됩니다.- 3
- ANP 리소스를 적용할 네임스페이스를 지정합니다.
- 4
- ANP에는 ingress 및 egress 규칙이 모두 있습니다.
spec.ingress필드의 ANP 규칙은Pass,Deny및Allowfor theaction필드를 허용합니다. - 5
ingress.name의 이름을 지정합니다.- 6
namespaceSelector.matchLabels에서 선택한 네임스페이스 내에서 Ingress 피어로 Pod를 선택하려면podSelector.matchLabels를 지정합니다.- 7
- ANP에는 수신 및 송신 규칙이 모두 있습니다.
spec.egress필드에 대한 ANP 규칙은Pass,Deny및Allowfor theaction필드를 허용합니다.
8.2.1.1.1. 규칙에 대한 AdminNetworkPolicy 작업
관리자는 AdminNetworkPolicy 규칙에 대한 작업 필드로 Allow,Deny 또는 Pass 를 설정할 수 있습니다. OVN-Kubernetes는 계층화된 ACL을 사용하여 네트워크 트래픽 규칙을 평가하므로 관리자가 이를 수정하거나, 규칙을 삭제하거나, 우선 순위 규칙을 설정하여만 변경할 수 있는 매우 강력한 정책 규칙을 설정할 수 있습니다.
AdminNetworkPolicy 허용 예
우선 순위 9에 정의된 다음 ANP는 모니터링 네임스페이스에서 클러스터의 테넌트(다른 모든 네임스페이스)로 모든 수신 트래픽을 허용합니다.
예 8.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
# ...
이는 관련된 모든 당사자가 해결할 수 없기 때문에 강력한 Allow ANP의 예입니다. 테넌트는 NetworkPolicy 오브젝트를 사용하여 자체적으로 모니터링되는 것을 차단할 수 없으며 모니터링 테넌트도 모니터링할 수 있거나 모니터링할 수 없습니다.
AdminNetworkPolicy 거부 예
우선순위 5에 정의된 다음 ANP는 모니터링 네임스페이스의 모든 수신 트래픽이 제한된 테넌트( 보안: restricted)로 차단되도록 합니다.
예 8.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
# ...
이는 강력한 Deny ANP로, 관련된 모든 당사자가 해결할 수 없는 강력한 Deny ANP입니다. 제한된 테넌트 소유자는 모니터링 트래픽을 허용하도록 권한을 부여할 수 없으며 인프라의 모니터링 서비스는 이러한 민감한 네임스페이스에서 아무것도 스크랩할 수 없습니다.
강력한 Allow 예제와 결합할 때 block-monitoring ANP는 우선순위가 높은 우선 순위 값을 가지므로 제한된 테넌트가 모니터링되지 않습니다.
AdminNetworkPolicy Pass 예
우선순위 7에 정의된 다음 ANP는 모니터링 네임스페이스에서 내부 인프라 테넌트(네트러블 security가 있는 네임스페이스)로 들어오는 모든 수신 트래픽을 ACL의 계층 2로 전달되고 네임스페이스의 NetworkPolicy 오브젝트에 의해 평가됩니다.
예 8.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
# ...
이 예는 테넌트 소유자가 정의한 NetworkPolicy 오브젝트에 결정을 위임하기 때문에 강력한 Pass 작업 ANP입니다. 이 pass-monitoring ANP를 사용하면 모든 테넌트 소유자가 내부 보안 수준에서 그룹화하여 네임스페이스 범위 NetworkPolicy 오브젝트를 사용하여 인프라의 모니터링 서비스에서 메트릭을 스크랩해야 하는지 여부를 선택할 수 있습니다.
8.2.2. OVN-Kubernetes BaselineAdminNetworkPolicy
8.2.2.1. BaselineAdminNetworkPolicy
BMC( BaselineAdminNetworkPolicy )는 클러스터 범위의 CRD(사용자 정의 리소스 정의)입니다. AWS 관리자의 Red Hat OpenShift Service는 BANP를 사용하여 NetworkPolicy 오브젝트를 사용하는 사용자가 덮어쓸 수 있는 선택적 기본 네트워크 정책 규칙을 설정하고 시행할 수 있습니다. BANP에 대한 규칙 작업은 허용 또는 거부 됩니다.
BaselineAdminNetworkPolicy 리소스는 전달된 트래픽 정책이 클러스터의 NetworkPolicy 오브젝트와 일치하지 않는 경우 가드레일 정책으로 사용할 수 있는 클러스터 싱글톤 오브젝트 입니다. BANP는 클러스터 내 트래픽이 기본적으로 차단되는 가드레일을 제공하는 기본 보안 모델로 사용할 수 있으며 사용자는 알려진 트래픽을 허용하기 위해 NetworkPolicy 오브젝트를 사용해야 합니다. BANP 리소스를 생성할 때 이름으로 default 를 사용해야 합니다.
관리자는 BANP를 사용하여 다음을 지정할 수 있습니다.
-
네임스페이스 또는 네임스페이스 세트로 구성된
제목입니다. -
제목을 향하는 모든 인그레스 트래픽에 적용할 수신 규칙 목록입니다. -
제목의 모든 송신 트래픽에 적용할 송신 규칙
목록입니다.
BaselineAdminNetworkPolicy 예
예 8.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
- 1
- BANP는 싱글톤 오브젝트이므로 정책 이름을
기본값으로 설정해야 합니다. - 2
- ANP를 적용할 네임스페이스를 지정합니다.
- 3
- BANP에는 ingress 및 egress 규칙이 모두 있습니다.
spec.ingress및spec.egress필드에 대한 BANP 규칙은Deny및Allowfor theaction필드를 허용합니다. - 4
ingress.name의 이름을 지정- 5
- BANP 리소스를 적용하려면 에서 Pod를 선택하도록 네임스페이스를 지정합니다.
- 6
- BANP 리소스를 적용할 Pod의
podSelector.matchLabels이름을 지정합니다.
BaselineAdminNetworkPolicy Deny 예
다음 BANP 싱글톤은 관리자가 내부 보안 수준에서 테넌트로 들어오는 모든 수신 모니터링 트래픽에 대한 기본 거부 정책을 설정하도록 합니다. "AdminNetworkPolicy Pass example"과 결합하면 이 거부 정책은 ANP pass-monitoring 정책에서 전달하는 모든 인그레스 트래픽에 대한 보호 정책 역할을 합니다.
예 8.6. guardrail Deny 규칙의 YAML 파일의 예
apiVersion: policy.networking.k8s.io/v1alpha1
kind: BaselineAdminNetworkPolicy
metadata:
name: default
spec:
subject:
namespaces:
matchLabels:
security: internal
ingress:
- name: "deny-ingress-from-monitoring"
action: "Deny"
from:
- namespaces:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
Baseline 리소스와 함께 AdminNetworkPolicy 작업 필드의 Pass 값과 함께 AdminNetworkPolicy 리소스를 사용하여 다중 테넌트 정책을 생성할 수 있습니다. 이 다중 테넌트 정책을 사용하면 한 테넌트에서 두 번째 테넌트에서 데이터를 동시에 수집하지 않고 애플리케이션에서 모니터링 데이터를 수집할 수 있습니다.
관리자는 "AdminNetworkPolicy Pass 작업 예"와 "BaselineAdminNetwork Policy Deny example"을 모두 적용하면 테넌트는 BANP 전에 평가할 NetworkPolicy 리소스를 생성하도록 선택할 수 있는 기능을 남겨 둡니다.
예를 들어 Tenant 1은 다음 NetworkPolicy 리소스를 설정하여 수신 트래픽을 모니터링할 수 있습니다.
예 8.7. NetworkPolicy예
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-monitoring
namespace: tenant 1
spec:
podSelector:
policyTypes:
- Ingress
ingress:
- from:
- namespaceSelector:
matchLabels:
kubernetes.io/metadata.name: monitoring
# ...
이 시나리오에서 Tenant 1의 정책은 "AdminNetworkPolicy Pass 작업 예제" 및 "BaselineAdminNetwork Policy Deny example" 이전에 평가되며 보안 수준 internal 이 있는 테넌트로 들어오는 모든 수신 모니터링 트래픽을 거부합니다. Tenant 1의 NetworkPolicy 오브젝트를 사용하면 애플리케이션에서 데이터를 수집할 수 있습니다. 테넌트 2 그러나 NetworkPolicy 오브젝트가 없는 사용자는 데이터를 수집할 수 없습니다. 관리자는 기본적으로 내부 테넌트를 모니터링하지 않았으며 대신 테넌트가 NetworkPolicy 오브젝트를 사용하여 BANP의 기본 동작을 재정의할 수 있는 BANP를 생성했습니다.
