NCP를 배포할 때에는 Kubernetes와 NSX-T Data Center 환경 둘 다를 보호하기 위한 조치를 취하는 것이 중요합니다.

NCP가 지정된 노드에서만 실행되도록 제한

NCP는 NSX-T Data Center 관리부에 액세스할 수 있어야 하며 지정된 인프라 노드에서만 실행되도록 제한해야 합니다. 적절한 레이블을 사용하여 이러한 노드를 식별할 수 있습니다. 그런 다음 이 레이블의 nodeSelector를 NCP ReplicationController 사양에 적용해야 합니다. 예를 들면 다음과 같습니다.

  nodeSelector:
      nsx-infra: True

선호도와 같은 기타 메커니즘을 사용하여 노드에 포드를 할당할 수도 있습니다. 자세한 내용은 https://kubernetes.io/docs/concepts/configuration/assign-pod-node 항목을 참조하십시오.

Docker Engine이 최신 버전인지 확인

Docker는 정기적으로 보안 업데이트를 릴리스합니다. 이러한 업데이트를 적용하기 위해서는 자동화된 절차를 구현해야 합니다.

신뢰할 수 없는 컨테이너의 NET_ADMIN 및 NET_RAW 기능 허용 안 함

Linux 기능인 NET_ADMIN 및 NET_RAW는 공격자가 포드 네트워크를 손상시키는 데 악용될 수 있습니다. 신뢰할 수 없는 컨테이너의 이러한 두 가지 기능을 사용하지 않도록 설정해야 합니다. 기본적으로 NET_ADMIN 기능은 권한 없는 컨테이너에 부여되지 않습니다. 포드 사양에서 명시적으로 사용하도록 설정하거나 컨테이너를 권한 모드로 설정하는 경우 주의해야 합니다. 또한, 신뢰할 수 없는 컨테이너의 경우 컨테이너 사양의 SecurityContext 구성에서 삭제된 기능 목록에 NET_RAW를 지정하여 NET_RAW를 사용하지 않도록 설정합니다. 예를 들면 다음과 같습니다.

    securityContext:
       capabilities:
          drop:
            - NET_RAW
            - ...

역할 기반 액세스 제어

Kubernetes는 RBAC(역할 기반 액세스 제어) API를 사용하여 권한 결정을 내리고 관리자가 정책을 동적으로 구성할 수 있도록 합니다. 자세한 내용은 https://kubernetes.io/docs/admin/authorization/rbac 항목을 참조하십시오.

일반적으로 클러스터 관리자는 권한 있는 액세스 및 역할을 갖는 유일한 사용자입니다. 사용자 및 서비스 계정의 경우 액세스 권한을 부여할 때 최소 권한 원칙을 따라야 합니다.

다음 지침이 권장됩니다.

  • Kubernetes API 토큰에 대한 액세스를 해당 토큰이 필요한 포드로 제한합니다.
  • NCP ConfigMap 및 NSX API 클라이언트 인증서의 TLS 암호에 대한 액세스를 NCP 포드로 제한합니다.
  • 이러한 액세스가 필요 없는 포드의 Kubernetes 네트워킹 API 액세스를 차단합니다.
  • Kubernetes API에 액세스할 수 있는 포드를 지정하는 Kubernetes RBAC 정책을 추가합니다.

NCP 포드에 대한 권장 RBAC 정책

ServiceAccount 아래에 NCP 포드를 생성하고 이 계정에 최소한의 권한 집합을 부여합니다. 또한, 다른 포드 또는 ReplicationController가 NCP ReplicationController 및 NSX 노드 에이전트의 볼륨으로 마운트된 ConfigMap 및 TLS 암호에 액세스하도록 허용하지 마십시오.

다음 예제는 NCP에 대한 역할 및 역할 바인딩을 지정하는 방법을 보여 줍니다.

  # Create a ServiceAccount for NCP namespace
  apiVersion: v1
  kind: ServiceAccount
  metadata:
   name: ncp-svc-account
   namespace: nsx-system
  
  ---
  
  # Create ClusterRole for NCP
  kind: ClusterRole
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-cluster-role
  rules:
   - apiGroups:
     - ""
     - extensions
     - networking.k8s.io
     resources:
       - deployments
       - endpoints
       - pods
       - pods/log
       - namespaces
       - networkpolicies
       # Move 'nodes' to ncp-patch-role when hyperbus is disabled.
       - nodes
       - replicationcontrollers
       # Remove 'secrets' if not using Native Load Balancer.
       - secrets
     verbs:
       - get
       - watch
       - list
  
  ---
  
  # Create ClusterRole for NCP to edit resources
  kind: ClusterRole
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-patch-role
  rules:
   - apiGroups:
     - ""
     - extensions
     resources:
       - ingresses
       - services
     verbs:
       - get
       - watch
       - list
       - update
       - patch
   - apiGroups:
     - ""
     - extensions
     resources:
       - ingresses/status
       - services/status
     verbs:
       - replace
       - update
       - patch
  ---
  
  # Bind ServiceAccount created for NCP to its ClusterRole
  kind: ClusterRoleBinding
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-cluster-role-binding
  roleRef:
   # Comment out the apiGroup while using OpenShift
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: ncp-cluster-role
  subjects:
   - kind: ServiceAccount
     name: ncp-svc-account
     namespace: nsx-system
  
  ---
  
  # Bind ServiceAccount created for NCP to the patch ClusterRole
  kind: ClusterRoleBinding
  # Set the apiVersion to v1 while using OpenShift
  apiVersion: rbac.authorization.k8s.io/v1beta1
  metadata:
   name: ncp-patch-role-binding
  roleRef:
   # Comment out the apiGroup while using OpenShift
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: ncp-patch-role
  subjects:
   - kind: ServiceAccount
     name: ncp-svc-account
     namespace: nsx-system
참고: NSX-T Data Center 클라이언트 인증서 및 개인 키 쌍에 대해 Kubernetes API를 사용하여 생성된 TLS 암호를 사용하면 Kubernetes API 서버에 액세스할 수 있는 모든 포드에 액세스할 수 있습니다. 마찬가지로 서비스 계정 없이 생성된 포드에는 Kubernetes API에 액세스할 수 있도록 하기 위해 토큰을 자동으로 마운트하는 동일한 네임스페이스의 기본 서비스 계정이 자동으로 할당됩니다. 따라서 이러한 토큰에 대한 액세스는 해당 토큰이 필요한 포드로 제한해야 합니다.