기본 Calico 네트워크 정책

공용 VLAN을 사용하는 클러스터가 작성될 때 각 작업자 노드 및 해당 공용 네트워크 인터페이스에 대해 레이블이 HostEndpoint인 ibm.role: worker_public 리소스가 자동으로 작성됩니다. 이 HostEndpoint 는 ibm.role: worker_public 레이블을 선택하는 Calico 정책에 의해 특별히 허용되지 않는 한 공용 네트워크 인터페이스로 (부터) 의 모든 트래픽이 삭제되도록 합니다.

각 작업자 노드 및 해당 사설 네트워크 인터페이스에 대해 HostEndpoint 레이블이 있는 ibm.role: worker_private 리소스 또한 자동으로 작성됩니다. 모든 트래픽이 사설 네트워크 인터페이스로 (부터) 허용되도록 기본 allow-all-private-default 정책이 작성됩니다. 이 HostEndpoint 를 사용하면 클러스터 사용자가 ibm.role: worker_private 를 선택하고 주문 번호가 allow-all-private-default 보다 낮은 Calico 정책을 작성하여 사설 네트워크 트래픽을 더 쉽게 제한할 수 있습니다."

이러한 기본 호스트 정책( Calico )은 모든 공용 아웃바운드 네트워크 트래픽을 허용하고, Kubernetes NodePort, LoadBalancer, 및 Ingress 서비스와 같은 특정 클러스터 구성 요소에 대한 공용 인바운드 트래픽을 허용합니다. 모든 개인용 트래픽은 기본적으로 allow-all-private-default 정책에 의해 허용됩니다. 인터넷으로부터 기본 정책에 지정되지 않은 작업자 노드로의 기타 모든 인바운드 네트워크 트래픽은 차단됩니다. 기본 정책은 팟(Pod) 간 트래픽에는 영향을 미치지 않습니다.

기본 정책은 다음 클러스터 마스터 새로 고치기 또는 마스터 업데이트 시 다시 작성되므로 클러스터에서 제거하지 마십시오. 트래픽을 추가로 제한하려면 더 낮은 순서의 Calico 정책을 적용하여 트래픽을 차단하십시오. 차단 중인 항목을 완전히 이해하고 클러스터 컴포넌트에 차단하려는 트래픽이 필요하지 않은지 확인하십시오.

자동으로 클러스터에 적용되는 다음과 같은 기본 Calico 호스트 정책을 검토하십시오.

Calico CLI 설치 및 구성

Calico 정책을 확인, 관리 및 추가하려면 Calico CLI를 설치하여 구성하십시오.

1. 클러스터에 대한 컨텍스트를 설정하여 Calico 명령을 실행하십시오.

   • Red Hat OpenShift 버전 4.6 이상:

     1. 클러스터에 대한 kubeconfig 구성 파일을 다운로드하십시오.

        ibmcloud oc cluster config --cluster <cluster_name_or_ID>
        

     2. DATASTORE_TYPE 환경 변수를 kubernetes(으)로 설정하십시오.

        export DATASTORE_TYPE=kubernetes
        

2. 회사 네트워크 정책으로 인해 프록시 또는 방화벽을 사용하여 로컬 시스템에서 공용 엔드포인트에 액세스하지 못하는 경우 Calico 명령에 대한 TCP 액세스를 허용하십시오.

3. 다음 단계에 따라 calicoctl 명령행 도구를 설치하십시오.

   • Linux 및 OS X

     1. Calico 의 CLI 버전을 다운로드하세요. OS X의 경우, 시스템 환경설정 > 보안 및 개인 정보 보호 > 일반 으로 이동하여 다운로드한 파일의 실행을 수동으로 허용해야 할 수 있습니다.

     2. 파일을 /usr/local/bin 디렉토리로 이동하십시오.

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. 파일을 실행 파일로 설정하십시오.

        chmod +x /usr/local/bin/calicoctl
        

     4. /etc/calico 디렉토리에 이전 Calico 구성 파일 calicoctl.cfg가 없는지 확인하십시오. /etc/calico/calicoctl.cfg 파일이 있으면 이를 삭제하십시오.

   • <

     1. Calico CLI를 다운로드하십시오. 파일을 저장할 때 calicoctl.exe로 이름을 바꾸고 IBM Cloud CLI와 동일한 디렉토리에 저장하십시오. 이 설정을 사용하면 나중에 명령을 실행할 때 일부 파일 경로 변경이 필요하지 않습니다.

     2. KUBECONFIG 환경 변수를 1단계에 있는 네트워크 구성 파일로 설정하십시오.

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/calicoctl.cfg
        

4. Calico 구성이 올바르게 작동하고 있는지 확인하십시오.

   calicoctl get nodes
   

   출력 예

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

Calico 플러그인, 컴포넌트 또는 기본 Calico 설정 변경은 지원되지 않습니다. 예를 들어, 새 Calico 플러그인 버전을 배치하거나 Calico 컴포넌트, 기본 IPPool 리소스 또는 Calico 노드에 대한 디먼 세트 및 배치를 수정하지 마십시오. 대신, 문서에 따라 Calico MTU를 변경하거나 필요한 경우 Calico CNI의 포트 맵 플러그인을 사용 안함으로 설정할 수 있습니다.

네트워크 정책 보기

클러스터에 적용되는 기본 및 추가된 네트워크 정책에 대한 세부사항을 보십시오.

시작하기 전에 Calico CLI를 설치하고 구성한 후 클러스터에 대한 컨텍스트를 설정하여 Calico 명령을 실행하십시오.

1. Calico 호스트 엔드포인트를 보십시오.

   calicoctl get hostendpoint -o yaml
   

2. 클러스터에 대해 생성된 모든 Calico 네트워크 정책을 확인합니다. 이 목록에는 팟(Pod) 또는 호스트에 아직 적용되지 않았을 수 있는 정책이 포함됩니다. Calico 정책을 적용하려면 Calico 네트워크 정책의 선택자와 일치하는 Kubernetes pod 또는 Calico HostEndpoint 가 존재해야 합니다.

   네트워크 정책은 특정 네임스페이스에 적용됩니다

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   글로벌 네트워크 정책은 특정 네임스페이스에 한정되지 않습니다

   calicoctl get GlobalNetworkPolicy -o wide
   

3. 네트워크 정책의 세부사항을 보십시오.

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. 클러스터에 대한 모든 글로벌 네트워크 정책의 세부사항을 보십시오.

   calicoctl get GlobalNetworkPolicy -o yaml
   

네트워크 정책 추가

일반적으로 기본 정책은 변경할 필요가 없습니다. 고급 시나리오에만 변경사항이 필요할 수 있습니다. 변경해야 하는 경우 사용자 고유의 네트워크 정책을 작성할 수 있습니다.

Kubernetes 네트워크 정책을 생성하려면 Kubernetes 네트워크 정책 문서를 참조하십시오.

Calico 정책을 작성하려면 다음 단계를 사용하십시오. 시작하기 전에 Calico CLI를 설치하고 구성한 후 클러스터에 대한 컨텍스트를 설정하여 Calico 명령을 실행하십시오.

1. Calico Calico v3 정책 구문을 사용하여 구성 스크립트( )를 작성하여 .yaml개인 네트워크 정책 또는 글로벌 네트워크 정책을 정의하십시오. 이러한 구성 파일에는 이러한 정책이 적용되는 팟(Pod), 네임스페이스 또는 호스트를 설명하는 선택기가 포함됩니다.

2. 클러스터에 정책을 적용하십시오. Windows 시스템이 있는 경우 --config=<filepath>/calicoctl.cfg 옵션을 포함하십시오.

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Calico 및 Kubernetes 네트워크 정책은 새 연결만 차단하며 정책이 적용되기 전에 존재했던 연결을 인터럽트하지 않습니다. 따라서 새 정책 또는 변경된 정책을 적용한 후 작동 중이며 필요 이상으로 차단하지 않는지 테스트하려면 다음을 수행하십시오.

1. 정책의 영향을 받을 수 있는 팟 (Pod) 을 다시 시작하십시오. 더 좋은 방법은 모든 팟 (Pod) 을 다시 시작하는 것입니다. 선택기가 올바르지 않고 사용자가 생각하는 것보다 더 많은 영향을 미치는 경우에만 해당됩니다.

2. ibmcloud ks cluster master refresh -c CLUSTER-ID 를 실행하여 클러스터 마스터 팟 (Pod) 을 다시 시작하십시오. 이는 kubelet및 기타 컴포넌트에서 마스터로의 기존 연결을 인터럽트하고 강제로 다시 연결합니다. 이는 새 정책 및 변경된 정책이 마스터 구성요소에 대한 필수 연결을 차단하는지 여부를 표시합니다.

3. Red Hat OpenShift on IBM Cloud 콘솔에 연결하여 정책 변경사항이 해당 컴포넌트에 필요한 연결을 차단하지 않도록 하십시오.

NLB 또는 NodePort 서비스에 대한 인바운드 트래픽 제어

기본적으로 Kubernetes NodePort및 LoadBalancer 서비스는 모든 공용 및 사설 클러스터 인터페이스에서 앱을 사용할 수 있도록 합니다. 그러나 사용자는 Calico 정책을 사용하여 트래픽 소스 또는 대상을 기반으로 서비스에 대한 수신 트래픽을 차단할 수 있습니다.

기본 설정인 Kubernetes 및 Calico 정책은 이러한 서비스에 대해 생성된 DNAT Iptables 규칙 때문에 Kubernetes NodePort 및 LoadBalancer 서비스를 보호하는 데 적용하기 어렵습니다. 그러나 Kubernetes가 일반 DNAT를 사용하여 트래픽을 팟(Pod)에 전달하기 전에 Iptables 규칙을 생성하고 적용하기 때문에 Pre-DNAT 정책은 특정 트래픽이 앱에 도달하지 못하도록 차단합니다.

Calico Pre-DNAT 네트워크 정책의 몇 가지 일반적인 사용법은 다음과 같습니다.

• 사설 네트워크 로드 밸런서(NLB) 서비스의 공용 노트 포트에 대한 트래픽 차단: NLB 서비스는 NLB IP 주소 및 포트를 통해 앱을 사용할 수 있도록 하고, 서비스의 노드 포트를 통해 앱을 사용할 수 있도록 합니다. 클러스터 내의 모든 노드에 대한 모든 IP 주소(공인 및 사설)에서 노드 포트에 액세스할 수 있습니다.
• 에지 작업자 노드에서 실행되는 클러스터의 공용 노드 포트에 대한 트래픽 차단: 노드 포트를 차단하면 에지 작업자 노드가 수신 트래픽을 처리하는 유일한 작업자 노드가 됩니다.
• 특정 소스 IP 주소 또는 CIDR로부터의 트래픽을 차단
• 특정 소스 IP 주소 또는 CIDR로부터의 트래픽만 허용하고 다른 모든 트래픽을 차단

소스 IP 주소를 허용하거나 차단하는 방법을 보려면 Calico 네트워크 정책을 사용하여 트래픽 차단 튜토리얼을 참고하십시오.

공용 또는 사설 네트워크 트래픽을 제한하는 예제 Calico 정책

클러스터 작업자에서 공용/개인용 네트워크 트래픽을 추가로 제한하는 예제 Calico 공용 네트워크 정책 세트를 제공합니다. 이러한 정책은 클러스터 배포에 필요한 트래픽은 허용하고 다른 특정 트래픽은 차단합니다.

이러한 정책은 모든 것을 차단하거나 자체적으로 준수 요구사항을 충족할 필요가 없습니다. 이는 시작점으로 사용하기 위한 것이며 고유한 유스 케이스를 충족하도록 편집해야 합니다. 자세한 정보는 README를 참조하십시오.

Red Hat OpenShift on IBM Cloud 및 기타 IBM Cloud에 대해 새 위치가 사용으로 설정될 때마다 이러한 위치의 서브넷이 Calico 정책에 추가됩니다. 이러한 정책에 대한 업데이트가 있는지 GitHub 저장소를 감시 하십시오.

아래 퍼블릭 및 프라이빗 네트워크 정책 섹션에서 allow-egress-pods-public, allow-public-services-pods, allow-opensift-console, allow-kube-system-to-olm, allow-opensift-metrics, allow-egress-pods-private 또는 allow-private-services-pods 샘플 정책은 더 이상 사용하지 않는 것을 권장합니다. 이러한 정책은 클러스터의 모든 파드로부터의 이그레스를 제어합니다. 파드와의 트래픽을 제어하려면 각 파드를 동일하게 취급하는 이러한 포괄적인 정책을 사용하는 대신 Kubernetes NetworkPolicy 사용하여 특정 네임스페이스와 파드를 대상으로 해야 한다.

팟(Pod) 간의 트래픽 제어

Kubernetes 정책은 내부 네트워크 트래픽으로부터 팟(Pod)을 보호합니다. 네임스페이스 내에서 서로 간에 또는 네임스페이스 간에 앱 마이크로서비스를 격리하기 위한 단순 Kubernetes 네트워크 정책을 작성할 수 있습니다.

기본적으로 모든 팟(Pod)은 클러스터 내의 다른 모든 팟(Pod)에 액세스할 수 있습니다. 또한 모든 팟(Pod)은 팟(Pod) 네트워크에서 노출된 모든 서비스(예: 메트릭 서비스, 클러스터 DNS, API 서버 또는 수동으로 클러스터에 작성하는 서비스)에 액세스할 수 있습니다.

거부된 트래픽 로깅

클러스터의 특정 팟(Pod)에 대해 거부된 트래픽 요청을 로깅하기 위해 Calico 로그 네트워크 정책을 작성할 수 있습니다.

트래픽을 앱 팟(Pod)으로 제한하도록 네트워크 정책을 설정하는 경우, 이러한 정책에서 허용하지 않는 트래픽 요청은 거부되고 삭제됩니다. 일부 시나리오에서 사용자는 거부된 트래픽 요청에 대한 자세한 정보를 원할 수 있습니다. 예를 들어, 사용자는 네트워크 정책 중 하나에 의해 지속적으로 거부되는 일부 비정상적인 트래픽을 발견할 수 있습니다. 잠재적인 보안 위협을 모니터링하기 위해, 사용자는 정책이 지정된 앱 팟(Pod)에 대해 시도된 조치를 거부할 때마다 기록하도록 로깅을 설정할 수 있습니다.

이 절에서는 Kubernetes 네트워크 정책으로 거부되는 트래픽을 로깅하는 방법을 보여줍니다. Calico 네트워크 정책으로 거부되는 트래픽을 로깅하려면 학습 5의 Calico 네트워크 정책 튜토리얼을 참조하십시오.

시작하기 전에 Calico CLI를 설치하고 구성한 후 클러스터에 대한 컨텍스트를 설정하여 Calico 명령을 실행하십시오.

1. 수신 트래픽을 차단하거나 제한하는 기존 Kubernetes 네트워크 정책을 작성하거나 사용하십시오.

   1. Kubernetes 네트워크 정책을 작성하십시오. 예를 들어, 팟(Pod) 간의 트래픽을 제어하기 위해 NGINX 앱에 대한 액세스를 제한하는 이름이 access-nginx인 다음의 예제 Kubernetes 정책을 사용할 수 있습니다. "run=nginx"로 레이블 지정된 팟(Pod)에 대한 수신 트래픽은 "run=access" 레이블이 있는 팟(Pod)에서만 허용됩니다. "run=nginx" 앱 팟(Pod)으로의 기타 모든 수신 트래픽은 차단됩니다.

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
       name: access-nginx
      spec:
       podSelector:
         matchLabels:
           run: nginx
       ingress:
         - from:
           - podSelector:
               matchLabels:
                 run: access
      

   2. 정책을 적용하십시오.

      oc apply -f <policy_name>.yaml
      

2. 이전 단계에서 작성한 Calico 정책에 의해 거부된 모든 트래픽을 로깅하려면 이름이 log-denied-packets인 Calico NetworkPolicy를 작성하십시오. 다음 Calico 정책은 1단계에서설명한 예제 access-nginx Kubernetes 정책과 동일한 팟 (Pod) 선택기를 사용하지만, 구문은 Kubernetes NetworkPolicy대신 Calico NetworkPolicy 이므로 약간 다릅니다. 또한 모든 Kubernetes NetworkPolicy 는 Calico 에 의해 1000 순서로 평가되므로 Kubernetes NetworkPolicy다음에 평가되도록 주문 번호 3000 가 추가됩니다. 이러한 두 가지 정책을 적용하면 다음과 같은 결과를 얻을 수 있습니다.

   • nginx팟 (Pod) 으로 들어오는 새 연결은 먼저 Kubernetes NetworkPolicy (order 1000) 에 대해 평가됩니다. run=access 레이블이 있는 팟 (Pod) 에서 수신되는 연결은 즉시 허용되며, 이는 다른 정책이 평가되지 않음을 의미합니다.

   • 연결이 run=access 레이블이 없는 팟 (Pod) 에서 오는 경우 (또는 팟 (Pod) 이 아닌 경우), 해당 Kubernetes NetworkPolicy 는 아무 것도 수행하지 않으며 Calico 는 다음에 log-denied-packets 정책을 평가합니다. 이 정책은 nginx팟 (Pod) 이 있는 작업자의 syslog에 패킷을 로그합니다.

   • 그런 다음 Calico 는 연결에 적용할 다른 모든 정책을 확인하고 연결을 찾을 수 없으므로 패킷이 삭제됩니다. 이는 명시적으로 허용되지 않는 정책이 있는 팟 (Pod) 에 대한 트래픽이 삭제되기 때문입니다.

     apiVersion: projectcalico.org/v3
     kind: NetworkPolicy
     metadata:
       name: log-denied-packets
     spec:
       types:
       - Ingress
       ingress:
       - action: Log
         destination: {}
         source: {}
       selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
       order: 3000
     

   types

   이 Ingress 정책은 모든 수신 트래픽 요청에 적용됩니다. Ingress 값은 모든 수신 트래픽에 대한 일반 용어이며 IBM Ingress ALB에서의 트래픽만을 나타내지는 않습니다. | ingress

   : action: Log 조치는 이 정책과 일치하는 요청에 대한 로그 항목을 작업자 노드의 /var/log/syslog 경로에 씁니다.

   destination: selector가 이 정책을 특정 레이블의 모든 팟(Pod)에 적용하므로 대상은 지정되지 않습니다.

   source: 이 정책은 임의의 소스의 요청에 적용됩니다.

   selector

   선택기는 원래 access-nginx Kubernetes NetworkPolicy와 동일한 트래픽을 대상으로 해야 합니다. 이는 Calico 정책이므로 원래 run == 'nginx' 외에 정책의 네임스페이스에 있는 모든 팟 (Pod) 에 적용됨을 표시하기 위해 projectcalico.org/orchestrator == 'k8s' 를 포함해야 합니다.

   order

   Calico 정책에는 수신 요청 패킷에 적용되는 시점을 판별하는 순서가 있습니다. 낮은 순서(예: 1000)의 정책이 우선 적용됩니다. 높은 순서의 정책은 낮은 순서 정책 이후에 적용됩니다. 예를 들어, 매우 높은 우선순위의 정책( 3000)은 낮은 우선순위의 정책이 모두 적용된 후에 마지막에 적용됩니다. 수신 요청 패킷은 Iptables 규칙 체인을 거치며 우선 낮은 순서 정책의 규칙을 일치시키려고 시도합니다. 패킷이 규칙과 일치하면 패킷이 허용됩니다. 그러나 패킷이 어떤 규칙과도 일치하지 않으면 이는 최상위 순서의 Iptables 규칙 체인의 마지막 규칙에 도달합니다. 이 정책이 체인의 마지막 정책이 되도록 하려면, 1단계에서 작성한 정책보다 훨씬 높은 순서(예: 3000)를 사용하십시오. Kubernetes NetworkPolicy 는 1000 순서대로 적용됩니다.

3. 정책을 적용하십시오. 윈도우 기기를 사용하는 경우, --config=<filepath>/calicoctl.cfg 옵션을 포함시키십시오.

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

4. 1단계에서 작성한 정책에서 허용되지 않는 요청을 전송하여 로그 항목을 생성하십시오. 예를 들어, 허용되지 않는 팟(Pod) 또는 IP 주소에서 네트워크 정책으로 보호되는 팟(Pod)에 ping을 실행하십시오.

5. /var/log/syslog 경로에 작성된 로그 항목을 확인하십시오. 로그 항목의 DST(대상) 또는 SRC(소스) IP 주소는 프록시, NAT(Network Address Translation) 및 기타 네트워킹 프로세스로 인해 예상과는 다를 수 있습니다. 로그 항목이 다음과 유사하게 나타납니다.

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. 선택사항: /var/log/syslog의 로그를 IBM Cloud Logs로 전달하십시오.