개요
k8s에서 network ploicy를 사용하여 network 보안을 어떻게 처리하는지 알아보겠습니다.
Network Policy란?
network 방향 및 port를 기반으로 cluster 내부의 Pod들 간의 network traffic을 제어하는 object입니다.
기본 동작 원리
NetworkPolicy가 없는 경우
모든 트래픽이 기본적으로 허용됩니다.
NetworkPolicy가 적용된 경우
해당 Pod에 대한 Traffic 은 기본적으로 차단되며, 정책에 따라 허용된 Traffic 통과됩니다.
단, ipBlock 설정을 통해서 cluster 외부와의 통신을 허용해 줄 수는 있습니다.
NetworkPolicy 자체는 외부 IP 주소를 직접 차단하는 메커니즘을 제공하지 않습니다.
동작 원리
아래 그림으로 설명을 하면 Web Pod , API Pod , DB Pod가 서로 통신하고 있는 상태입니다.
이 상태에서 DB Pod에서 API Pod의 요청만 받고 싶을 때는 Network Policy를 DB Pod에 적용하여 3306에 대한 ingress(inboud)만 허용해 주면 됩니다.
그러면 Network Policy 구조를 알아보겠습니다.
Network Policy 구조
network policy의 구조는 podSelector, policyType, ingress, egress로 크게 이루어져 있습니다.
podSelector로 Pod를 선택하고 선택된 Pod의 Network에 방향에 맞게 policyType과 ingress, egress를 설정하여 허용할 IP와 port를 설정하면 됩니다.
아래는 k8s 공식 페이지의 yaml 파일입니다.
ingress / egress 동시 설정
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
ports:
- protocol: TCP
port: 6379
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
여기서 유의 사항으로는 룰의 매칭 조건을 알아야 합니다.
"-" 를 한개의 Rule로 봅니다.
- "-" 를 개별 Rule로 인식하여 or 조건으로 동작
- "-" 안의 Rule들은 And 조건으로 동작
예를 들어 아래 설정에서 ipblock, namespaceSelector, podSelector는 각각 개별 룰로 취급되며 or 조건으로 동작합니다.
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
그러나 아래 설정에서는 ipblock과 namespaceSelector는 and로 동작하고 podSelector는 개별 룰로 취급 or 조건으로 동작합니다.
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
egress 에서 여러 Pod로 나가기 설정
1개의 pod에서 여러개의 pod로 나가는 port 허용하는 방법
- to , port를 쌍으로 하여 rule을 만들면 됩니다.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
name: internal
policyTypes:
- Egress
egress:
- to:
- podSelector:
matchLabels:
name: payrool
ports:
- port: 8080
- to:
- podSelector:
matchLabels:
name: mysql
ports:
- port: 3306
Network Policy 확인
kubectl get networkplicies
Network Policy 설정 값이 없다면?
NetworkPolicy를 정의할 때 ingress와 egress 섹션을 설정하는 것은 네트워크 트래픽을 제어하는 데 사용됩니다.
그러나 섹션들의 설정이 NetworkPolicy오브젝트에 없거나 비어 있을 경우, 그리고 policyTypes 필드에 명시적으로 Ingress 또는 Egress가 지정되어 있을 경우의 행동은 다음과 같습니다
policyTypes 필드가 설정 된 경우
policyTypes에 ingress또는 egress가 포함되어있다면 기본 설정은 Traffic 차단입니다.
Ingress 섹션
NetworkPolicy에 ingress 섹션이 없거나 비어 있고, policyTypes에 Ingress가 포함되어 있다면, 해당 정책이 적용되는 대상 포드로의 모든 들어오는 트래픽이 차단됩니다.
Egress 섹션
NetworkPolicy에 egress 섹션이 없거나 비어 있고, policyTypes에 Egress가 포함되어 있다면, 해당 정책이 적용되는 대상 포드로부터의 모든 나가는 트래픽이 차단됩니다.
policyTypes 필드가 설정되지 않은 경우
ingress 규칙이 제공되면 기본적으로 Ingress 유형이 적용되고, egress 규칙이 제공되면 Egress 유형이 적용됩니다.
policyTypes 필드가 설정되어 있지 않고 ingress와 egress 규칙도 제공되지 않으면 (아무 설정 없음)
기본적으로 어떠한 네트워크 트래픽도 차단되지 않습니다.
따라서, NetworkPolicy를 사용하여 모든 트래픽을 막고 싶다면, 다음과 같이 policyTypes에 Ingress와 Egress를 모두 명시하고, 규칙을 비워두어야 합니다:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-all-traffic
spec:
podSelector: {} # 이 정책을 적용할 포드 선택
policyTypes:
- Ingress
- Egress
ingress: [] # 비어 있는 규칙은 모든 ingress 트래픽 차단
egress: [] # 비어 있는 규칙은 모든 egress 트래픽 차단
이 설정은 podSelector에 의해 선택된 모든 포드로의 모든 들어오는 트래픽과 나가는 트래픽을 차단합니다.
k8s 공식 사이트
https://kubernetes.io/docs/concepts/services-networking/network-policies/
정리
network 방향 및 port를 기반으로 cluster 내부의 Pod들 간의 network traffic을 제어하는 object입니다.
NetworkPolicy 자체는 외부 IP 주소를 직접 차단하는 메커니즘을 제공하지 않습니다.
network policy의 구조는 podSelector, policyType, ingress, egress로 크게 이루어져 있습니다.
podSelector로 Pod를 선택하고 선택된 Pod의 격리할 Network에 방향에 맞게 policyType과 ingress, egress를 설정하면 됩니다.
Next Post
'Cloud > k8s-CKA' 카테고리의 다른 글
[CKA] 46. k8s 문제 풀이(업데이트, 출력형식, PV) (0) | 2023.11.15 |
---|---|
[CKA] 45. Troubleshooting (0) | 2023.11.07 |
[CKA] 43. k8s 각종 보안 (image, securityContext) (0) | 2023.11.05 |
[CKA] 42. service account (0) | 2023.11.04 |
[CKA] 41. Authorization (권한부여) (0) | 2023.10.28 |