☰

Apache Ignite 시작을 방해하지 않는 NetworkPolicy를 사용하여 송신 트래픽을 화이트리스트에 추가하는 방법은 무엇입니까?

tag-icon • tag-icon networking kubernetes port policy-routing network-namespace
Apache Ignite 시작을 방해하지 않는 NetworkPolicy를 사용하여 송신 트래픽을 화이트리스트에 추가하는 방법은 무엇입니까?

Apache Ignite가 상태 비저장 데이터베이스/캐시로 사용되는 다소 복잡한 마이크로서비스 아키텍처가 있습니다. Ignite 는 그 중 Pod유일한 것이며 아키텍처는 보안 감사를 통과해야 합니다. 트래픽 에 대해 가장 제한적인 기준을 적용하지 않으면 보안 감사를 통과할 수 없습니다 . Ignite 자체에 필요하지 않은 가능한 모든 트래픽을 제한해야 합니다.PodNamespaceNetworkPolicyegress

처음에는 이렇게 생각했습니다.좋습니다. Ignite는 다른 포드로 트래픽을 푸시하지 않으므로 Pod(그 안에 다른 포드는 없습니다 ) Ignite가 유일한 곳 에서 Namespace모든 트래픽을 제한하여 쉽게 수행할 수 있습니다 !egressNamespacePod...


글쎄요, 실제로는 별로 효과가 없었습니다. egressIgnite 문서에 언급된 모든 포트에 대한 트래픽을 허용하더라도 규칙에 따라 시작이 실패하고 다음과 IgniteSpiException같은 메시지가 표시됩니다.Ignite 포드 IP 주소를 검색하지 못했습니다., Caused by: java.net.ConnectException: Operation timed out (Connection timed out).

문제는 다음과 같습니다.TcpDiscoveryKubernetsIpFinder특히 Ignite 노드의 IP 주소를 등록하기 위해 getRegisteredAddresses(...)내부에서 일부 송신 트래픽을 수행하는 방법이 특히 그렇습니다. Namespace물론 발견 포트 47500이 허용되지만 상황이 바뀌지는 않습니다. Ignite의 기능은 다른 s Pod의 다른 s와 함께 적용되는 규칙 Namespace없이 작동합니다 . 이는 (나에게) , , a 에 egress관한 구성 및 Ignite 자체의 xml 구성 등이 올바른 것 같다는 것을 의미합니다. 다른 네임스페이스의 트래픽을 제한하는 규칙 도 예상대로 작동하여 원하는 트래픽을 정확하게 허용합니다.ClusterRoleClusterRoleBindingServiceNamespaceingress

제가 적용한 정책은 다음과 같습니다.

[작동 중, 원치 않는 트래픽만 차단]:

## Denies all Ingress traffic to all Pods in the Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress-in-cache-ns
  namespace: cache-ns
spec:
  # selecting nothing here will deny all traffic between pods in the namespace
  podSelector:
    matchLabels: {}
  # traffic routes to be considered, here: incoming exclusively
  policyTypes:
    - Ingress

## Allows necessary ingress traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol-cache-ns
  namespace: cache-ns
# defines the pod(s) that this policy is targeting
spec:
  policyTypes:
    - Ingress
  podSelector:
    matchLabels:
      app: ignite
  # <----incoming traffic----
  ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            zone: somewhere-else
        podSelector:
          matchExpressions:
            - key: app
              operator: In
              values: [some-pod, another-pod]  # dummy names, these Pods don't matter at all
      ports:
        - port: 11211   # JDBC
          protocol: TCP
        - port: 47100   # SPI communication
          protocol: TCP
        - port: 47500   # SPI discovery (CRITICAL, most likely...)
          protocol: TCP
        - port: 10800   # SQL
          protocol: TCP
# ----outgoing traffic---->
# NONE AT ALL

이 두 가지를 적용하면 모든 것이 잘 작동하지만 보안 감사에서는 다음과 같이 표시됩니다.
에 대한 제한은 어디에 있습니까 egress? 이 경로를 사용하는 포드 중 하나가 이전에 해킹되었기 때문에 이 노드가 허용된 경로를 통해 해킹된 경우 어떻게 되나요? 그러면 C&C 서버를 호출할 수 있습니다! 이 구성은 허용되지 않습니다. 아키텍처를 강화하세요!

[원하는/필요한 트래픽 차단]:

일반적으로 모든 트래픽을 거부합니다.

## Denies all traffic to all Pods in the Namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-traffic-in-cache-ns
  namespace: cache-ns
spec:
  # selecting nothing here will deny all traffic between pods in the namespace
  podSelector:
    matchLabels: {}
  # traffic routes to be considered, here: incoming exclusively
  policyTypes:
    - Ingress
    - Egress   # <------ THIS IS THE DIFFERENCE TO THE WORKING ONE ABOVE

...나중에 특정 경로를 허용합니다.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: netpol-cache-ns-egress
  namespace: cache-ns
# defines the pod(s) that this policy is targeting
spec:
  policyTypes:
    - Egress
  podSelector:
    matchLabels:
      app: ignite
  ----outgoing traffic---->
  egress:
    # [NOT SUFFICIENT]
    # allow egress to this namespace at specific ports
    - to:
      - namespaceSelector:
          matchLabels:
            zone: cache-zone
      ports:
        - protocol: TCP
          port: 10800
        - protocol: TCP
          port: 47100   # SPI communication
        - protocol: TCP
          port: 47500
    # [NOT SUFFICIENT]
    # allow dns resolution in general (no namespace or pod restriction)
    - ports:
      - protocol: TCP
        port: 53
      - protocol: UDP
        port: 53
    # [NOT SUFFICIENT]
    # allow egress to the kube-system (label is present!)
    - to:
      - namespaceSelector:
          matchLabels:
            zone: kube-system
    # [NOT SUFFICIENT]
    # allow egress in this namespace and for the ignite pod
    - to:
      - namespaceSelector:
          matchLabels:
            zone: cache-zone
        podSelector:
          matchLabels:
            app: ignite
    # [NOT SUFFICIENT]
    # allow traffic to the IP address of the ignite pod
    - to:
      - ipBlock:
          cidr: 172.21.70.49/32  # won't work well since those addresses are dynamic
      ports:
        - port: 11211   # JDBC
          protocol: TCP
        - port: 47100   # SPI communication
          protocol: TCP
        - port: 47500   # SPI discovery (CRITICAL, most likely...)
          protocol: TCP
        - port: 49112   # JMX
          protocol: TCP
        - port: 10800   # SQL
          protocol: TCP
        - port: 8080    # REST
          protocol: TCP
        - port: 10900   # thin clients
          protocol: TCP

사용된 Apache Ignite 버전은 2.10.0입니다.

이제 모든 독자에게 질문은 다음과 같습니다.

Ignite가 시작되고 올바르게 작동하도록 Egress내부에서 절대 최소값으로 제한하려면 어떻게 해야 합니까 ? 클러스터 외부를 Namespace거부하는 것으로 충분합니까 ?Egress

정보에 근거한 추측이나 힌트를 얻기 위해 더 필요한 것이 있으면 yaml언제든지 댓글로 요청해 주세요. 그리고 태그가 부적절해 보인다면 죄송합니다 . stackoverflow에 있는
태그를 찾을 수 없습니다 .kubernetes-networkpolicy

업데이트:

쇼를 nslookup -debug kubernetes.default.svc.cluster.local제한하는 정책 없이 Ignite Pod 내부에서 실행egress

BusyBox v1.29.3 (2019-01-24 07:45:07 UTC) multi-call binary.

Usage: nslookup HOST [DNS_SERVER]

Query DNS about HOST

NetworkPolicy특정 포트, 포드 및 네임스페이스로 제한하는 (모든)이 적용되 자마자 EgressIgnite 포드가 시작을 거부하고 조회가 kubernetes.default.svc.cluster.local더 이상 도달하지 않습니다.

EgressDNS가 허용되었습니다(UDP 53 to k8s-app: kube-dns) ⇒ 여전히 IP 조회가 불가능합니다.

관련 정보