보안 전문가를 위한 Kubernetes 네트워크 정책 소개

메모. 번역: 기사의 저자인 Reuven Harrison은 소프트웨어 개발 분야에서 20년 이상의 경력을 갖고 있으며, 현재는 보안 정책 관리 솔루션을 만드는 회사인 Tufin의 CTO이자 공동 창업자입니다. 그는 Kubernetes 네트워크 정책을 클러스터의 네트워크 분할을 위한 상당히 강력한 도구로 보고 있지만 실제로 구현하기가 쉽지 않다고 생각합니다. 이 자료(상당히 방대함)는 전문가의 이 문제에 대한 인식을 높이고 필요한 구성을 만드는 데 도움을 주기 위해 작성되었습니다.

오늘날 애플리케이션 실행을 위해 Kubernetes를 선택하는 기업이 점점 늘어나고 있습니다. 이 소프트웨어에 대한 관심이 너무 높아서 일부에서는 Kubernetes를 "데이터 센터를 위한 새로운 운영 체제"라고 부릅니다. 점차적으로 Kubernetes(또는 k8s)는 네트워크 보안을 포함하여 성숙한 비즈니스 프로세스의 구성이 필요한 비즈니스의 중요한 부분으로 인식되기 시작했습니다.

Kubernetes 작업에 어리둥절해하는 보안 전문가에게 진짜 깨달음은 플랫폼의 기본 정책인 모든 것을 허용하는 것일 수 있습니다.

이 가이드는 네트워크 정책의 내부 구조를 이해하는 데 도움이 됩니다. 일반 방화벽 규칙과 어떻게 다른지 이해합니다. 또한 몇 가지 함정을 다루고 Kubernetes에서 애플리케이션을 보호하는 데 도움이 되는 권장 사항을 제공합니다.

Kubernetes 네트워크 정책

Kubernetes 네트워크 정책 메커니즘을 사용하면 네트워크 계층(OSI 모델의 세 번째 계층)에서 플랫폼에 배포된 애플리케이션의 상호 작용을 관리할 수 있습니다. 네트워크 정책에는 OSI 레이어 7 시행 및 위협 탐지와 같은 최신 방화벽의 일부 고급 기능이 부족하지만 좋은 출발점이 되는 기본 수준의 네트워크 보안을 제공합니다.

네트워크 정책은 포드 간의 통신을 제어합니다.

Kubernetes의 워크로드는 함께 배포된 하나 이상의 컨테이너로 구성된 포드에 분산됩니다. Kubernetes는 각 Pod에 다른 Pod에서 액세스할 수 있는 IP 주소를 할당합니다. Kubernetes 네트워크 정책은 클라우드의 보안 그룹이 가상 머신 인스턴스에 대한 액세스를 제어하는 ​​데 사용되는 것과 동일한 방식으로 포드 그룹에 대한 액세스 권한을 설정합니다.

네트워크 정책 정의

다른 Kubernetes 리소스와 마찬가지로 네트워크 정책은 YAML에 지정됩니다. 아래 예에서는 애플리케이션이 balance 액세스 postgres:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: balance
  policyTypes:
  - Ingress

(메모. 번역: 이 스크린샷은 이후의 모든 유사한 스크린샷과 마찬가지로 기본 Kubernetes 도구를 사용하지 않고 원본 기사 작성자의 회사에서 개발했으며 자료 끝에 언급된 Tufin Orca 도구를 사용하여 생성되었습니다.)

자체 네트워크 정책을 정의하려면 YAML에 대한 기본 지식이 필요합니다. 이 언어는 들여쓰기(탭이 아닌 공백으로 지정)를 기반으로 합니다. 들여쓰기된 요소는 그 위에 가장 가까운 들여쓰기된 요소에 속합니다. 새 목록 요소는 하이픈으로 시작하고 다른 모든 요소는 다음 형식을 갖습니다. 핵심 가치.

YAML에서 정책을 설명한 후 다음을 사용합니다. 쿠 베틀클러스터에 생성하려면 다음을 수행하세요.

kubectl create -f policy.yaml

네트워크 정책 사양

Kubernetes 네트워크 정책 사양에는 다음 네 가지 요소가 포함됩니다.

1. podSelector: 이 정책(대상)의 영향을 받는 포드를 정의합니다. - 필수입니다.
2. policyTypes: 여기에 포함된 정책 유형을 나타냅니다. 수신 및/또는 송신 - 선택 사항이지만 모든 경우에 명시적으로 지정하는 것이 좋습니다.
3. ingress: 허용 정의 들어오는 대상 포드에 대한 트래픽 - 선택 사항입니다.
4. egress: 허용 정의 나가는 대상 Pod의 트래픽은 선택 사항입니다.

Kubernetes 웹사이트에서 가져온 예(저는 role 에 app)는 네 가지 요소가 모두 사용되는 방법을 보여줍니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:    # <<<
    matchLabels:
      app: 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

XNUMX가지 요소를 모두 포함할 필요는 없습니다. 필수일 뿐입니다 podSelector, 원하는 대로 다른 매개변수를 사용할 수 있습니다.

생략하는 경우 policyTypes, 정책은 다음과 같이 해석됩니다.

• 기본적으로 수신측을 정의한다고 가정합니다. 정책에 이를 명시적으로 명시하지 않으면 시스템은 모든 트래픽이 금지된 것으로 가정합니다.
• 송신 측의 동작은 해당 송신 매개변수의 유무에 따라 결정됩니다.

실수를 피하기 위해 나는 권장합니다 항상 명시적으로 해라 policyTypes.

위의 논리에 따르면, 매개변수가 ingress 및 / 또는 egress 생략하면 정책이 모든 트래픽을 거부합니다(아래 "스트리핑 규칙" 참조).

기본 정책은 허용입니다.

정책이 정의되지 않으면 Kubernetes는 기본적으로 모든 트래픽을 허용합니다. 모든 포드는 서로 자유롭게 정보를 교환할 수 있습니다. 이는 보안 관점에서 직관에 반하는 것처럼 보일 수 있지만 Kubernetes는 원래 개발자가 애플리케이션 상호 운용성을 지원하도록 설계했다는 점을 기억하세요. 네트워크 정책은 나중에 추가되었습니다.

네임스페이스

네임스페이스는 Kubernetes 협업 메커니즘입니다. 논리적 환경을 서로 격리하도록 설계되었으며, 공간 간 통신은 기본적으로 허용됩니다.

대부분의 Kubernetes 구성 요소와 마찬가지로 네트워크 정책은 특정 네임스페이스에 있습니다. 블록에서 metadata 정책이 속하는 공간을 지정할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: my-namespace  # <<<
spec:
...

메타데이터에 네임스페이스가 명시적으로 지정되지 않은 경우 시스템은 kubectl에 지정된 네임스페이스를 사용합니다(기본적으로). namespace=default):

kubectl apply -n my-namespace -f namespace.yaml

나는 추천한다 네임스페이스를 명시적으로 지정, 한 번에 여러 네임스페이스를 대상으로 하는 정책을 작성하지 않는 한.

예비 선거 요소 podSelector 정책에서는 정책이 속한 네임스페이스에서 포드를 선택합니다(다른 네임스페이스의 포드에 대한 액세스는 거부됨).

마찬가지로, podSelector 수신 및 송신 블록에서 물론 Pod를 다음과 결합하지 않는 한 자체 네임스페이스에서만 Pod를 선택할 수 있습니다. namespaceSelector (이 내용은 "네임스페이스 및 포드를 기준으로 필터링" 섹션에서 설명합니다.)

정책 명명 규칙

정책 이름은 동일한 네임스페이스 내에서 고유합니다. 같은 공간에 같은 이름을 가진 두 개의 정책이 있을 수는 없지만, 다른 공간에 같은 이름을 가진 정책은 있을 수 있습니다. 이는 여러 공간에 걸쳐 동일한 정책을 다시 적용하려는 경우에 유용합니다.

특히 이름 지정 방법 중 하나가 마음에 듭니다. 네임스페이스 이름과 대상 Pod를 결합하는 것으로 구성됩니다. 예를 들어:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres  # <<<
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

레이블

Pod 및 네임스페이스와 같은 Kubernetes 개체에 사용자 지정 레이블을 연결할 수 있습니다. 라벨(라벨 - 태그)는 클라우드의 태그와 동일합니다. Kubernetes 네트워크 정책은 라벨을 사용하여 선택합니다. 꼬투리적용 대상:

podSelector:
  matchLabels:
    role: db

… 또는 네임스페이스적용됩니다. 이 예시에서는 해당 라벨이 있는 네임스페이스의 모든 Pod를 선택합니다.

namespaceSelector:
  matchLabels:
    project: myproject

한 가지 주의 사항: 사용 시 namespaceSelector 선택한 네임스페이스에 올바른 레이블이 포함되어 있는지 확인하세요.. 다음과 같은 내장 네임스페이스가 있다는 점에 유의하세요. default и kube-system, 기본적으로 라벨을 포함하지 않습니다.

다음과 같이 스페이스에 라벨을 추가할 수 있습니다.

kubectl label namespace default namespace=default

동시에 섹션의 네임스페이스 metadata 레이블이 아닌 실제 공간 이름을 참조해야 합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default   # <<<
spec:
...

소스 및 대상

방화벽 정책은 소스와 대상이 포함된 규칙으로 구성됩니다. Kubernetes 네트워크 정책은 적용되는 포드 세트인 대상에 대해 정의된 다음 수신 및/또는 송신 트래픽에 대한 규칙을 설정합니다. 이 예시에서 정책의 대상은 네임스페이스의 모든 포드가 됩니다. default 열쇠가 있는 라벨 포함 app 그리고 의미 db:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: 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

일부 ingress 이 정책에서는 대상 Pod로 들어오는 트래픽을 엽니다. 즉, 수신은 소스이고 대상은 해당 대상입니다. 마찬가지로 송신은 대상이고 대상은 소스입니다.

이는 Ingress → Target의 두 가지 방화벽 규칙과 동일합니다. 목표 → 출구.

송신 및 DNS(중요!)

나가는 트래픽을 제한함으로써, DNS에 특별한 주의를 기울이세요 - Kubernetes는 이 서비스를 사용하여 서비스를 IP 주소에 매핑합니다. 예를 들어, 다음 정책은 애플리케이션을 허용하지 않았기 때문에 작동하지 않습니다. balance DNS에 액세스:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  policyTypes:
  - Egress

DNS 서비스에 대한 액세스를 열어 문제를 해결할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:               # <<<
    ports:            # <<<
    - protocol: UDP   # <<<
      port: 53        # <<<
  policyTypes:
  - Egress

마지막 요소 to 비어 있으므로 간접적으로 선택합니다. 모든 네임스페이스의 모든 포드, 허용 balance 적절한 Kubernetes 서비스(일반적으로 해당 공간에서 실행됨)에 DNS 쿼리를 보냅니다. kube-system).

이 접근 방식은 효과적이지만 지나치게 관대하고 불안하다, DNS 쿼리가 클러스터 외부로 전달될 수 있기 때문입니다.

세 가지 연속 단계를 거쳐 개선할 수 있습니다.

1. DNS 쿼리만 허용 이내 추가하여 클러스터 namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector: {} # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

2. 네임스페이스 내에서만 DNS 쿼리를 허용합니다. kube-system.

이렇게 하려면 네임스페이스에 레이블을 추가해야 합니다. kube-system: kubectl label namespace kube-system namespace=kube-system - 그리고 이를 다음을 사용하여 정책에 기록합니다. namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
  - to:
    - namespaceSelector:         # <<<
        matchLabels:             # <<<
          namespace: kube-system # <<<
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

3. 편집증적인 사람들은 더 나아가 DNS 쿼리를 특정 DNS 서비스로 제한할 수 있습니다. kube-system. "네임스페이스 및 포드로 필터링" 섹션에서는 이를 달성하는 방법을 설명합니다.

또 다른 옵션은 네임스페이스 수준에서 DNS를 확인하는 것입니다. 이 경우 각 서비스마다 열 필요가 없습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.dns
  namespace: default
spec:
  podSelector: {} # <<<
  egress:
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: UDP
      port: 53
  policyTypes:
  - Egress

널 (null) podSelector 네임스페이스의 모든 Pod를 선택합니다.

첫 번째 일치 및 규칙 순서

기존 방화벽에서는 패킷에 대한 작업(허용 또는 거부)이 만족하는 첫 번째 규칙에 따라 결정됩니다. Kubernetes에서는 정책의 순서가 중요하지 않습니다.

기본적으로 정책이 설정되지 않은 경우 Pod 간 통신이 허용되며 자유롭게 정보를 교환할 수 있습니다. 정책 수립을 시작하면 정책 중 하나 이상의 영향을 받는 각 포드는 이를 선택한 모든 정책의 분리(논리적 OR)에 따라 격리됩니다. 정책의 영향을 받지 않는 포드는 열린 상태로 유지됩니다.

탈지 룰을 사용하여 이 동작을 변경할 수 있습니다.

스트리핑 규칙(“거부”)

방화벽 정책은 일반적으로 명시적으로 허용되지 않는 모든 트래픽을 거부합니다.

Kubernetes에는 거부 작업이 없습니다.그러나 빈 소스 포드 그룹(수신)을 선택하여 일반(허용) 정책을 사용하여 유사한 효과를 얻을 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Ingress

이 정책은 네임스페이스의 모든 포드를 선택하고 수신을 정의되지 않은 상태로 유지하여 모든 수신 트래픽을 거부합니다.

비슷한 방식으로 네임스페이스에서 나가는 모든 트래픽을 제한할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress

유의 사항 네임스페이스의 Pod에 대한 트래픽을 허용하는 추가 정책은 이 규칙보다 우선 적용됩니다. (방화벽 구성에서 거부 규칙 앞에 허용 규칙을 추가하는 것과 유사)

모두 허용(Any-Any-Any-Allow)

모두 허용 정책을 생성하려면 위의 거부 정책을 빈 요소로 보완해야 합니다. ingress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
  namespace: default
spec:
  podSelector: {}
  ingress: # <<<
  - {}     # <<<
  policyTypes:
  - Ingress

다음에서 액세스할 수 있습니다. 모든 네임스페이스(및 모든 IP)의 모든 포드를 네임스페이스의 모든 포드로 default. 이 동작은 기본적으로 활성화되어 있으므로 일반적으로 추가로 정의할 필요가 없습니다. 그러나 때로는 문제를 진단하기 위해 일부 특정 권한을 일시적으로 비활성화해야 할 수도 있습니다.

액세스만 허용하도록 규칙 범위를 좁힐 수 있습니다. 특정 포드 세트 (app:balance) 네임스페이스에 default:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-to-balance
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: balance
  ingress: 
  - {}
  policyTypes:
  - Ingress

다음 정책은 클러스터 외부의 모든 IP에 대한 액세스를 포함하여 모든 수신 및 송신 트래픽을 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}
  policyTypes:
  - Ingress
  - Egress

여러 정책 결합

정책은 세 가지 수준에서 논리적 OR을 사용하여 결합됩니다. 각 포드의 권한은 포드에 영향을 미치는 모든 정책의 분리에 따라 설정됩니다.

1. 들판에서 from и to 세 가지 유형의 요소를 정의할 수 있습니다(모두 OR를 사용하여 결합됨).

• namespaceSelector — 전체 네임스페이스를 선택합니다.
• podSelector — 포드를 선택합니다.
• ipBlock — 서브넷을 선택합니다.

또한 하위 섹션의 요소 수(동일한 요소라도) from/to 제한되지 않습니다. 모두 논리적 OR로 결합됩니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

2. 정책 섹션 내부 ingress 많은 요소를 가질 수 있다 from (논리적 OR로 결합) 마찬가지로 섹션 egress 많은 요소를 포함할 수 있음 to (또한 분리로 결합됨):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
  - from:
    - podSelector:
        matchLabels:
          app: admin
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

3. 다양한 정책도 논리적 OR로 결합됩니다.

하지만 이들을 결합할 때 한 가지 제한 사항이 있습니다. 지시 된 크리스 쿠니: Kubernetes는 서로 다른 정책만 결합할 수 있습니다. policyTypes (Ingress 또는 Egress). 수신(또는 송신)을 정의하는 정책은 서로 덮어쓰게 됩니다.

네임스페이스 간의 관계

기본적으로 네임스페이스 간 정보 공유가 허용됩니다. 이는 네임스페이스로 나가거나 들어오는 트래픽을 제한하는 거부 정책을 사용하여 변경할 수 있습니다(위의 "스트리핑 규칙" 참조).

네임스페이스에 대한 액세스를 차단한 후에는(위의 "스트리핑 규칙" 참조) 다음을 사용하여 특정 네임스페이스로부터의 연결을 허용함으로써 거부 정책에 대한 예외를 만들 수 있습니다. namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: # <<<
        matchLabels:
          namespace: default
  policyTypes:
  - Ingress

결과적으로 네임스페이스의 모든 포드는 default 포드에 액세스할 수 있습니다. postgres 네임스페이스에서 database. 하지만 다음에 대한 액세스를 공개하고 싶다면 어떻게 해야 할까요? postgres 네임스페이스의 특정 포드만 default?

네임스페이스 및 Pod로 필터링

Kubernetes 버전 1.11 이상에서는 연산자를 결합할 수 있습니다. namespaceSelector и podSelector 논리 AND를 사용합니다. 다음과 같습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          namespace: default
      podSelector: # <<<
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

이것이 일반적인 OR 대신 AND로 해석되는 이유는 무엇입니까?

참고 podSelector 하이픈으로 시작하지 않습니다. YAML에서 이는 다음을 의미합니다. podSelector 그리고 그 앞에 서서 namespaceSelector 동일한 목록 요소를 참조하십시오. 따라서 논리 AND로 결합됩니다.

앞에 하이픈 추가 podSelector 결과적으로 이전 목록 요소와 결합되는 새로운 목록 요소가 나타납니다. namespaceSelector 논리적 OR을 사용합니다.

특정 라벨이 있는 포드를 선택하려면 모든 네임스페이스에서, 공백을 입력하세요 namespaceSelector:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database.postgres
  namespace: database
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          app: admin
  policyTypes:
  - Ingress

여러 레이블이 I와 팀을 이룹니다.

여러 개체(호스트, 네트워크, 그룹)가 있는 방화벽에 대한 규칙은 논리적 OR을 사용하여 결합됩니다. 패킷 소스가 일치하면 다음 규칙이 작동합니다. Host_1 또는 Host_2:

| Source | Destination | Service | Action |
| ----------------------------------------|
| Host_1 | Subnet_A    | HTTPS   | Allow  |
| Host_2 |             |         |        |
| ----------------------------------------|

반대로 Kubernetes에서는 podSelector 또는 namespaceSelector 논리적 AND로 결합됩니다. 예를 들어 다음 규칙은 두 라벨이 모두 있는 포드를 선택합니다. role=db И version=v2:

podSelector:
  matchLabels:
    role: db
    version: v2

정책 대상 선택기, 포드 선택기, 네임스페이스 선택기 등 모든 유형의 연산자에 동일한 논리가 적용됩니다.

서브넷 및 IP 주소(IPBlock)

방화벽은 VLAN, IP 주소 및 서브넷을 사용하여 네트워크를 분할합니다.

Kubernetes에서 IP 주소는 포드에 자동으로 할당되고 자주 변경될 수 있으므로 레이블은 네트워크 정책에서 포드와 네임스페이스를 선택하는 데 사용됩니다.

서브넷(ipBlocks)은 수신(ingress) 또는 송신(egress) 외부(North-South) 연결을 관리할 때 사용됩니다. 예를 들어 이 정책은 네임스페이스의 모든 포드에 열립니다. default Google DNS 서비스에 액세스:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 8.8.8.8/32
    ports:
    - protocol: UDP
      port: 53

이 예에서 빈 포드 선택기는 "네임스페이스의 모든 포드 선택"을 의미합니다.

이 정책은 8.8.8.8에 대한 액세스만 허용합니다. 다른 IP에 대한 접근은 금지됩니다. 따라서 본질적으로 내부 Kubernetes DNS 서비스에 대한 액세스가 차단되었습니다. 그래도 열고 싶다면 이를 명시적으로 지정하세요.

보통 ipBlocks и podSelectors 포드의 내부 IP 주소는 포드에서 사용되지 않으므로 상호 배타적입니다. ipBlocks. 표시함으로써 내부 IP 포드, 실제로 이러한 주소를 사용하는 포드와의 연결을 허용하게 됩니다. 실제로는 어떤 IP 주소를 사용해야 할지 알 수 없으므로 포드를 선택하는 데 이를 사용해서는 안 됩니다.

반대 예로 다음 정책은 모든 IP를 포함하므로 다른 모든 Pod에 대한 액세스를 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0

포드의 내부 IP 주소를 제외하고 외부 IP에만 액세스를 열 수 있습니다. 예를 들어 포드의 서브넷이 10.16.0.0/14인 경우:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-any
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 10.16.0.0/14

포트 및 프로토콜

일반적으로 포드는 하나의 포트를 수신합니다. 이는 정책에서 포트 번호를 지정하지 않고 모든 것을 기본값으로 둘 수 없음을 의미합니다. 그러나 정책을 최대한 제한적으로 만드는 것이 좋습니다. 따라서 어떤 경우에는 여전히 포트를 지정할 수 있습니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
      - port: 443      # <<<
        protocol: TCP  # <<<
      - port: 80       # <<<
        protocol: TCP  # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

참고로 선택자는 ports 블록의 모든 요소에 적용됩니다. to 또는 from, 포함하는. 서로 다른 요소 집합에 대해 서로 다른 포트를 지정하려면 분할하세요. ingress 또는 egress 여러 하위 섹션으로 to 또는 from 각 포트를 등록할 때:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default.postgres
  namespace: default
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: indexer
    ports:             # <<<
     - port: 443       # <<<
       protocol: TCP   # <<<
  - from:
    - podSelector:
        matchLabels:
          app: admin
    ports:             # <<<
     - port: 80        # <<<
       protocol: TCP   # <<<
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
  - Ingress

기본 포트 작동:

• 포트 정의를 완전히 생략하는 경우(ports), 이는 모든 프로토콜과 모든 포트를 의미합니다.
• 프로토콜 정의(protocol), 이는 TCP를 의미합니다.
• 포트 정의를 생략하는 경우(port), 이는 모든 포트를 의미합니다.

모범 사례: 기본값에 의존하지 말고 필요한 사항을 명시적으로 지정하세요.

서비스 포트가 아닌 포드 포트를 사용해야 한다는 점에 유의하세요(자세한 내용은 다음 단락에서 설명).

Pod 또는 서비스에 대한 정책이 정의되어 있나요?

일반적으로 Kubernetes의 Pod는 서비스(서비스를 구현하는 Pod로 트래픽을 리디렉션하는 가상 로드 밸런서)를 통해 서로 액세스합니다. 네트워크 정책이 서비스에 대한 액세스를 제어한다고 생각할 수도 있지만 그렇지 않습니다. Kubernetes 네트워크 정책은 서비스 포트가 아닌 포드 포트에서 작동합니다.

예를 들어 서비스가 포트 80을 수신하지만 해당 Pod의 포트 8080으로 트래픽을 리디렉션하는 경우 네트워크 정책에서 정확히 8080을 지정해야 합니다.

이러한 메커니즘은 차선책으로 간주되어야 합니다. 서비스의 내부 구조(팟이 수신 대기하는 포트)가 변경되면 네트워크 정책을 업데이트해야 합니다.

Service Mesh를 사용한 새로운 아키텍처 접근 방식 (예를 들어 아래 Istio에 대해 참조하세요 - 대략적인 번역) 이 문제에 대처할 수 있습니다.

Ingress와 Egress를 모두 등록해야 합니까?

짧은 대답은 '예'입니다. Pod A가 Pod B와 통신하려면 나가는 연결 생성이 허용되어야 하며(이를 위해서는 송신 정책을 구성해야 함) Pod B가 들어오는 연결을 수락할 수 있어야 합니다( 이를 위해서는 수신 정책)이 필요합니다.

그러나 실제로는 기본 정책을 사용하여 단방향 또는 양방향 연결을 허용할 수 있습니다.

어떤 포드라면-출처 한 명 이상의 사람이 선택하게 됩니다. 출구-정치인에 대한 제한은 그들의 분리에 따라 결정됩니다. 이 경우 Pod에 대한 연결을 명시적으로 허용해야 합니다.수취인에게. 정책에 따라 Pod가 선택되지 않은 경우 해당 Pod의 나가는(송신) 트래픽이 기본적으로 허용됩니다.

마찬가지로 포드의 운명은 다음과 같습니다.수신인, 하나 이상의 선택됨 입구-정치인들은 그들의 분리에 의해 결정될 것입니다. 이 경우 소스 Pod에서 트래픽을 수신하도록 명시적으로 허용해야 합니다. 정책에 따라 포드가 선택되지 않은 경우 해당 포드에 대한 모든 수신 트래픽은 기본적으로 허용됩니다.

아래의 Stateful 또는 Stateless를 참조하세요.

로그

Kubernetes 네트워크 정책은 트래픽을 기록할 수 없습니다. 이로 인해 정책이 의도한 대로 작동하는지 여부를 판단하기가 어렵고 보안 분석이 매우 복잡해집니다.

외부 서비스에 대한 트래픽 제어

Kubernetes 네트워크 정책에서는 송신 섹션에 정규화된 도메인 이름(DNS)을 지정하는 것을 허용하지 않습니다. 이 사실은 고정 IP 주소가 없는 외부 대상(예: aws.com)으로 트래픽을 제한하려고 할 때 상당한 불편을 초래합니다.

정책 확인

방화벽은 잘못된 정책에 대해 경고하거나 거부할 수도 있습니다. Kubernetes도 몇 가지 확인을 수행합니다. kubectl을 통해 네트워크 정책을 설정할 때 Kubernetes는 해당 정책이 올바르지 않다고 선언하고 수락을 거부할 수 있습니다. 다른 경우에는 Kubernetes가 정책을 가져와 누락된 세부정보로 채웁니다. 다음 명령을 사용하여 볼 수 있습니다.

kubernetes get networkpolicy <policy-name> -o yaml

Kubernetes 유효성 검사 시스템은 오류가 없는 것이 아니며 일부 유형의 오류를 놓칠 수 있다는 점을 명심하세요.

Исполнение

Kubernetes는 네트워크 정책 자체를 구현하지 않으며 CNI(컨테이너 네트워킹 인터페이스)라는 기본 시스템에 제어 부담을 위임하는 API 게이트웨이일 뿐입니다. 적절한 CNI를 할당하지 않고 Kubernetes 클러스터에 정책을 설정하는 것은 방화벽에 정책을 설치하지 않고 방화벽 관리 서버에 정책을 만드는 것과 같습니다. 적절한 CNI를 보유하고 있는지 또는 Kubernetes 플랫폼의 경우 클라우드에서 호스팅되는지 확인하는 것은 귀하에게 달려 있습니다. (제공자 목록을 볼 수 있습니다. 여기에 — 대략. 트랜스.), CNI를 설정하는 네트워크 정책을 활성화합니다.

적절한 도우미 CNI 없이 네트워크 정책을 설정하면 Kubernetes에서 경고를 표시하지 않습니다.

상태 저장 또는 상태 비저장?

내가 만난 모든 Kubernetes CNI는 상태 저장형입니다(예: Calico는 Linux conntrack을 사용함). 이를 통해 포드는 재설정할 필요 없이 시작된 TCP 연결에서 응답을 수신할 수 있습니다. 그러나 나는 상태 저장을 보장하는 Kubernetes 표준을 알지 못합니다.

고급 보안 정책 관리

Kubernetes에서 보안 정책 시행을 개선하는 몇 가지 방법은 다음과 같습니다.

1. Service Mesh 아키텍처 패턴은 사이드카 컨테이너를 사용하여 서비스 수준에서 상세한 원격 측정 및 트래픽 제어를 제공합니다. 예를 들어 우리는 이스 티오.
2. 일부 CNI 공급업체는 Kubernetes 네트워크 정책을 뛰어넘도록 도구를 확장했습니다.
3. 투핀 오르카 Kubernetes 네트워크 정책에 대한 가시성과 자동화를 제공합니다.

Tufin Orca 패키지는 Kubernetes 네트워크 정책을 관리합니다(위 스크린샷의 소스이기도 함).

추가 정보

• GKE의 Ahmet Alp Balkan이 작성한 네트워크 정책의 예;
• 공식 Kubernetes 웹사이트의 문서;
• Kubernetes 네트워킹 모델 가이드;
• 네트워크 정책 확인 스크립트.

결론

Kubernetes 네트워크 정책은 클러스터 분할을 위한 좋은 도구 세트를 제공하지만 직관적이지 않고 미묘한 부분이 많습니다. 이러한 복잡성으로 인해 많은 기존 클러스터 정책에 버그가 있다고 생각합니다. 이 문제에 대한 가능한 해결책에는 정책 정의 자동화 또는 기타 분할 도구 사용이 포함됩니다.

이 가이드가 몇 가지 질문을 해결하고 발생할 수 있는 문제를 해결하는 데 도움이 되기를 바랍니다.

번역가의 추신

블로그에서도 읽어보세요.

• "Istio를 사용한 마이크로서비스로 돌아가기": 1부(주요 기능 소개), 파트 2(라우팅, 트래픽 제어), 3부(보안);
• "Kubernetes의 네트워킹에 대한 그림 가이드": 파트 1 및 2(네트워크 모델, 오버레이 네트워크), 3부(서비스 및 트래픽 처리);
• «보안에 민감한 환경의 Docker 및 Kubernetes";
• «9 Kubernetes 보안 모범 사례";
• «쿠버네티스 해킹의 피해자가 되지 않는 11가지 방법".

출처 : habr.com