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 機能を許可しない

NET_ADMIN と NET_RAW の Linux 機能は、ポッド ネットワークに侵入した攻撃者によって悪用される可能性があります。信頼されていないコンテナでは、これらの 2 つの機能を無効にする必要があります。デフォルトでは、権限のないコンテナに 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 Secret へのアクセスを NCP ポッドに限定します。
  • このようなアクセスを必要としないポッドから Kubernetes ネットワーク API へのアクセスをブロックします。
  • Kubernetes RBAC ポリシーを追加し、Kubernetes API にアクセスできるポッドを指定します。

NCP ポッドの推奨 RBAC ポリシー

ServiceAccount で NCP ポッドを作成し、このアカウントに最小の権限セットを付与します。また、他のポッドまたは ReplicationControllers には、NCP ReplicationController および NSX Node Agent のボリュームとしてマウントされる ConfigMap と TLS Secret へのアクセスを許可しません。

次の例は、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 Secret とプライベート キーのペアには、Kubernetes API サーバにアクセスできる任意のポッドからアクセスできます。ポッドがサービス アカウントなしで作成された場合、同じ名前空間のデフォルトのサービス アカウントが自動的に割り当てられます。これにより、Kubernetes API にアクセスするトークンが自動的にマウントされます。これらのトークンへのアクセスは、トークンを必要とするポッドにのみ許可する必要があります。