Beim Bereitstellen von NCP ist es wichtig, Schritte zum Sichern der Kubernetes- und der NSX-T Data Center-Umgebungen auszuführen.

Beschränken der NCP-Ausführung auf bestimmte Knoten

NCP hat Zugriff auf die NSX-T Data Center-Managementebene und die Ausführung sollte auf bestimmte Infrastrukturknoten beschränkt werden. Sie können diese Knoten mit einer entsprechenden Kennzeichnung identifizieren. Anschließend sollte ein nodeSelector-Objekt für diese Kennzeichnung auf die NCP ReplicationController-Spezifikation angewendet werden. Beispiel:

  nodeSelector:
      nsx-infra: True

Sie können auch andere Mechanismen wie die Affinität verwenden, um Knoten Pods zuzuweisen. Weitere Informationen finden Sie unter https://kubernetes.io/docs/concepts/configuration/assign-pod-node.

Stellen Sie sicher, dass die Docker-Engine aktuell ist

Docker veröffentlicht regelmäßig Sicherheits-Updates. Ein automatisierter Vorgang sollte implementiert werden, um diese Updates anzuwenden.

Nichtzulassen von NET_ADMIN- und NET_RAW-Funktionen nicht vertrauenswürdiger Container

Die Linux-Funktionen NET_ADMIN und NET_RAW können von Angreifern ausgenutzt werden, um das Pod-Netzwerk zu gefährden. Sie sollten diese beiden Funktionen der nicht vertrauenswürdigen Container deaktivieren. Standardmäßig wird die NET_ADMIN-Funktion auf einem nicht Container ohne Berechtigungen nicht gewährt. Seien Sie vorsichtig, wenn sie von einer Pod-Spezifikation explizit aktiviert oder der Container auf den privilegierten Modus festgelegt wird. Deaktivieren Sie darüber hinaus für nicht vertrauenswürdigen Container NET_RAW, indem Sie NET_RAW in der Liste der verworfenen Funktionen in der SecurityContext-Konfiguration der Container-Spezifikation angeben. Beispiel:

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

Rollenbasierte Zugriffssteuerung

Kubernetes verwendet die APIs für die rollenbasierte Zugriffssteuerung (RBAC) für Autorisierungsfestlegungen und ermöglicht Administratoren damit die dynamische Konfiguration von Richtlinien. Weitere Informationen finden Sie unter https://kubernetes.io/docs/admin/authorization/rbac.

Normalerweise ist der Cluster-Administrator der einzige Benutzer mit privilegiertem Zugriff und privilegierten Rollen. Für Benutzer und Dienstkonten muss beim Gewährend des Zugriffs das Prinzip der geringsten Berechtigung befolgt werden.

Die folgenden Richtlinien werden empfohlen:

  • Beschränken Sie den Zugriffs auf Kubernetes-API-Token auf Pods, die sie benötigen.
  • Beschränken Sie den Zugriff auf die geheimen TLS-Schlüssel des NCP ConfigMap- und NSX-API-Clientzertifikats auf den NCP-Pod.
  • Blockieren Sie den Zugriff auf Kubernetes-Netzwerk-API von Pods, die diesen Zugriff nicht benötigen.
  • Fügen Sie eine Kubernetes RBAC-Richtlinie hinzu, um anzugeben, welche Pods auf die Kubernetes-API zugreifen können.

Empfohlene RBAC-Richtlinie für den NCP-Pod

Erstellen Sie den NCP-Pod unter einem Dienstkonto, und weisen Sie diesem Konto einen minimale Berechtigungen zu. Gewähren Sie darüber hinaus anderen Pods oder ReplicationController-Objekten keinen Zugriff auf die geheimen ConfigMap- und TLS-Schlüssel, die als Volumes für den NCP ReplicationController- und NSX-Knotenagent bereitgestellt wurden.

Das folgende Beispiel zeigt, wie Sie Rollen und Rollenbindungen für NCP angeben:

  # 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
Hinweis: Der geheime TLS-Schlüssel, der mithilfe der Kubernetes-API für das NSX-T Data Center-Clientzertifikat erstellt wird, und das private Schlüsselpaar sind für Pods zugänglich, die Zugriff auf den Kubernetes-API-Server haben. Wird ein Pod ohne Dienstkonto erstellt, wird ihm gleichermaßen automatisch das Standard-Dienstkonto zugewiesen, das den Token automatisch für den Zugriff auf die Kubernetes-API bereitstellt. Aus diesem Grund muss der Zugriff auf diese Token auf Pods beschränkt werden, die sie benötigen.