[CKA] Network Policy

[CKA] Network Policy

 

데이터베이스 파드(DB Pod)를 다른 pod에서 접근할 수 없도록 보호하려고 한다.하지만 API Pod에서의 접근은 허용한다.기본적으로 kubernetes는 모든 트래픽을 허용하지만 데이터베이스 파드로 들어오고 나가는 모든것을 차단하고 싶다. 그래서 네트워크 정책을 생성한다. 우리는 그것을 DB 정책이라고 부른다. 첫번째 단계는 보호하려는 pod에 네트워크 정책을 연결하는것이다. (label, selector 이용)

 

하지만 아직 정책 유형(policyTypes)을 지정하지 않았기 때문에 여전히 트래픽을 차단하지 않는다. 따라서 지정된 정책 유형이 없는경우 네트워크 정책으로 보호되지 않는다. Ingress(수신) 및 Egress(송신) 를 모두 차단하고 싶다면 정책 유형에 추가하고 모든 유입을 차단해야한다.

그러나  우리는 포트 3306에서 데이터베이스를 쿼리할 수 있으려면 API 포드가 필요하다. 여기에서 Ingress(수신) 및 Egress(송신) 가 둘 다 필요할까? DB Pod 관점에서 보면 API Pod 에서  들어오는 트래픽을 허용하려고 한다. 수신이므로 Ingress가 필요하다. API Pod는 데이터베이스 쿼리를 생성하고 데이터베이스 Pod는 결과를 반환한다. 결과를 API Pod 로 돌려 보내려면 별도의 규칙이 필요할까? 아니다.  들어오는 트래픽을 허용하면 해당 트래픽에 대한 응답 또는 응답이 자동으로 다시 허용된다. 그래서 이 경우에는 API Pod에서 데이터베이스 Pod로의 트래픽을 허용하는 Ingress 규칙만 있으면 API 포드가 데이터베이스에 연결하여 쿼리를 실행하고 쿼리 결과를 검색할 수 있다.

따라서 어떤 유형의 규칙을 만들 것인지 결정할 때는 요청이 발생하는 방향에 대해서만 고려하면 됩니다. 이 경우 직선으로 표시되며 점선으로 표시되는 응답에 대해서는 걱정할 필요가 없다. 그러나 이 규칙이 데이터베이스 포드가 API 포드에 연결하거나 API에 호출할 수 있음을 의미하지는 않는다. 예를 들어, 데이터베이스 포드가 API 포드에 API 호출을 시도하면 데이터베이스 포드에서 발생하는 송신 트래픽이므로 허용되지 않으며 특정 송신 규칙을 정의해야 한다. 따라서 단일 네트워크 정책은 Ingress 유형의 규칙, Egress 유형의 규칙 또는 경우에 따라 둘 다 가질 수 있다. 파드가 수신 연결을 허용하고 외부 연결를 하려는 경우에는 Ingress 정책 유형만 필요하다.

 

이제 정책 유형을 결정했으므로 다음 단계는 해당 정책의 구체적인 내용을 정의하는 것이다.수신의 경우 Ingress이라는 섹션을 생성하여 여러 규칙을 지정할 수 있다.

각 규칙에는 from 및 ports 필드가 있다. From 필드는 데이터베이스 Pod로 통과할 수 있는 트래픽의 소스를 정의한다. 여기서는 파드 셀렉터를 사용하여 API 파드의 label을 제공한다. ports 필드는 데이터베이스 Pod에서 트래픽이 이동할 수 있는 port를 정의한다. 이 경우에는 TCP 프로토콜이 적용된 3306이다. 이렇게 하면 API Pod의 트래픽을 제외한 DB Pod로의 모든 트래픽을 차단하는 정책이 생성된다.

 

metadata: 
	name: db-policy
    namespace: prod

그럼 클러스터에 레이블이 동일하지만 네임스페이스가 다른 여러 API 파드가 있으면 어떻게 될까? 여기에는 dev, prod 환경을 위한 서로 다른 네임스페이스가 있으며 이러한 각 환경에 동일한 레이블이 있는 API 파드가 있다. 먼저 prod 네임스페이스(기본 네임스페이스가 아닌 네임스페이스)에 대한 네트워크 정책을 생성하는 경우 네트워크 정책 개체 정의에 prod로 정의된 네임스페이스가 있어야 한다.
이제 기본적으로 이 정책은 네트워크 정책의 네임스페이스와 동일한 네임스페이스이지만 데이터베이스 포드에 도달하기 위해 일치하는 레이블인 prod 네임스페이스에서만 포드를 허용한다.

 

ingress: 
	- from:
	  - podSelector:
		matchLabels:
            		name: api-pod
        namespaceSelector
        	matchLabels:
            		name: staging

그러나 어떤 이유로 스테이징 네임스페이스(다른 네임스페이스)의 포드가 프로덕션 네임스페이스의 데이터베이스에 연결되기를 원한다면 어떻게 할까? 이를 위해, 우리는 파드셀렉터 속성과 함께 네임스페이스셀렉터 속성을 추가한다.  이 작업을 수행하려면 먼저 네임스페이스에 이 레이블 세트가 있어야한다. 데이터베이스 포드에 도달할 수 있는 네임스페이스 트래픽을 정의하는 데 도움이 된다. 그럼 네임스페이스 셀렉터만 있고 포드 셀렉터는 없는 경우 어떻게 될까? 스테이징 네임스페이스 안의 API 파드말고도 스테이징 네임스페이스 안의 모든 파드가 Proc 네임스페이스의 데이터베이스 파드에 접근할 수 있다. 그러나 이 네임스페이스 외부의 파드는 통과할 수 없다.

이제 네임스페이스 셀렉터를 다시 prod로 변경하고 다른 사용 사례를 살펴보자. 예를 들어 Kubernetes 클러스터 외부에 백업 서버가 있고 이 서버가 데이터베이스 포드에 연결되도록 허용하려고 한다. 이제 이 백업 서버는 Kubernetes 클러스터에 배포되지 않았으므로 트래픽을 정의하는 데 사용하는 포드 선택기 및 네임스페이스 선택기 필드는 클러스터의 포드가 아니기 때문에 작동하지 않는다.

 

그러나 백업 서버의 IP 주소는 알고 있으며 이 주소는 192.168.5.10이다. 특정 IP 주소에서 발생하는 트래픽을 허용하도록 네트워크 정책을 구성할 수 있다. 이를 위해 IP 블록 정의로 알려진 새로운 유형의 정의를 추가합니다. IpBlock을 사용하면 트래픽이 데이터베이스 포드에 도달하도록 허용할 수 있는 IP 주소 범위를 지정할 수 있다. 레이블별로 포드를 선택할 수 있는 포드 선택기가 있고 레이블별로 네임스페이스를 선택할 수 있는 네임스페이스 선택기가 있으며 IP 주소 범위를 선택하는 IP 블록 선택기가 있다.

이러한 규칙은 개별 규칙으로 개별적으로 전달되거나 단일 규칙의 일부로 함께 전달될 수 있다. 이 예제에서는 from 섹션 아래에 두 개의 요소가 있다. 이것이 두 가지 규칙이다. 첫 번째 규칙에는 포드 선택기와 네임스페이스 선택기가 함께 있고, 두 번째 규칙에는 IP 블록 선택기가 있다. 그래서 이것은 OR 연산처럼 작동한다. 이러한 조건 중 하나를 충족하는 소스로부터의 트래픽은 통과할 수 있다. 그러나 첫 번째 규칙에는 두 개의 선택기가 포함되어 있다. 이는 소스로부터의 트래픽이 통과하려면 이 두 가지 기준을 모두 충족해야 한다는 것을 의미하고 AND 연산처럼 작동한다.

 

그럼 네임스페이스 셀렉터 앞에 대시를 추가하여 분리하면 어떨까? 그럼 그것들은 두 개의 별개의 규칙이된다. 따라서 첫 번째 규칙과 일치하는 트래픽, 즉 동일한 네임스페이스에 있는 레이블 API 포드와 일치하는 모든 포드에서, 두 번째 규칙과 일치하는 트래픽이 허용된다. 우리는 세 가지 별도의 규칙을 가지고 있으며, 어디서든 거의 모든 트래픽이 DB 포드에 허용된다. 그래서 이와 같은 작은 변화가 큰 영향을 미칠 수 있다. 따라서 요구사항에 따라 이러한 규칙을 어떻게 조합할 수 있는지 이해하는 것이 중요하다.

이제 Egress에 대해 알아보자. 예를 들어 백업 서버가 백업을 시작하는 대신 백업 서버로 백업을 푸시하는 DB 포드의 에이전트가 있다고 가정해 보자. 이 경우 트래픽은 데이터베이스 포드에서 외부 백업 서버로 전송된다. 이를 위해 egress 규칙을 정의해야 한다.

먼저 정책 유형에 권한을 추가한 다음 새 권한 섹션을 추가하여 정책의 세부 사항을 정의한다. from이 아니라 to로 정의하는것이 유일한 차이점이다. 포드, 네임스페이스 또는 IP 블록 선택기와 같은 선택기를 사용할 수 있다. 그리고 이 경우 데이터베이스 서버가 외부에 있으므로 IP 블록 선택기를 사용하여 서버에 CIDR 블록을 제공한다. 요청을 보낼 포트가 80이므로 80를 포트로 지정한다. 따라서 이 규칙은 데이터베이스 포드에서 지정된 주소의 외부 백업 서버로 전송되는 트래픽을 허용한다.

 

출처:

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/learn/lecture/24458474#announcements