在部署 NCP 时,请务必采取措施以保护 Kubernetes 和 NSX-T Data Center 环境。

将 NCP 限制为仅在指定的节点上运行

NCP 有权访问 NSX-T Data Center 管理层面,应将其限制为仅在指定的基础架构节点上运行。您可以使用相应的标签指定这些节点。然后,应将该标签的 nodeSelector 应用于 NCP ReplicationController 规范。例如,

  nodeSelector:
      nsx-infra: True

也可以使用其他机制(如关联性)以将 pod 分配给节点。有关详细信息,请参见 https://kubernetes.io/docs/concepts/configuration/assign-pod-node

确保 Docker 引擎是最新的

Docker 定期发布安全更新。应实施一个自动化过程以应用这些更新。

禁止不受信任的容器的 NET_ADMIN 和 NET_RAW 功能

攻击者可能会利用 Linux 功能 NET_ADMIN 和 NET_RAW 以破坏 pod 网络。您应该禁用不受信任的容器的这两个功能。默认情况下,不会为非特权容器授予 NET_ADMIN 功能。如果 pod 规范明确启用该功能,或者将容器设置为特权模式,请务必小心。此外,对于不受信任的容器,请在容器规范的 SecurityContext 配置上的弃用的功能列表中指定 NET_RAW 以禁用 NET_RAW。例如,

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

基于角色的访问控制

Kubernetes 使用基于角色的访问控制 (RBAC) API 帮助作出授权决定,从而允许管理员动态配置策略。有关详细信息,请参见 https://kubernetes.io/docs/admin/authorization/rbac

通常,群集管理员是唯一具有访问特权和角色的用户。对于用户和服务帐户,必须在授予访问权限时遵循最小特权原则。

建议使用以下准则:

  • 将对 Kubernetes API 令牌的访问限制为需要它们的 pod。
  • 将对 NCP ConfigMap 和 NSX API 客户端证书的 TLS 密钥的访问限制为 NCP pod。
  • 阻止不需要访问 Kubernetes 网络 API 的 pod 进行该类访问。
  • 添加 Kubernetes RBAC 策略以指定哪些 pod 有权访问 Kubernetes API。

NCP pod 的建议 RBAC 策略

使用 ServiceAccount 创建 NCP pod,并为该帐户授予一组最小特权。此外,不允许其他 pod 或 ReplicationController 访问 ConfigMap 和 TLS 密钥,它们是作为 NCP ReplicationController 和 NSX 节点代理的卷挂载的。

以下示例说明了如何为 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
注: 有权访问 Kubernetes API 服务器的任何 pod 都可以访问使用 Kubernetes API 为 NSX-T Data Center 客户端证书和私钥对创建的 TLS 密钥。同样,在不使用服务帐户创建 pod 时,将在相同的命名空间中自动为其分配默认服务帐户,这会自动挂载令牌以访问 Kubernetes API。因此,必须将对这些令牌的访问限制为需要它们的 pod。