Lorsque vous déployez NCP, il est important de prendre des mesures pour sécuriser les environnements Kubernetes et NSX-T Data Center.

Restreindre NCP pour ne fonctionner que sur des nœuds désignés

NCP a accès au plan de gestion de NSX-T Data Center et doit être restreint pour ne fonctionner que sur les nœuds d'infrastructure désignés. Vous pouvez identifier ces nœuds avec une étiquette appropriée. Un nodeSelector pour cette étiquette doit ensuite être appliqué au ReplicationController NCP specification/. Par exemple,

  nodeSelector:
      nsx-infra: True

Vous pouvez également utiliser d'autres mécanismes, tels que l'affinité, pour attribuer des espaces à des nœuds. Pour plus d'informations, consultez https://kubernetes.io/docs/concepts/configuration/assign-pod-node.

Vérifier que le moteur de Docker est à jour

Docker publie périodiquement des mises à jour de sécurité. Une procédure automatique doit être implémentée pour appliquer ces mises à jour.

Interdire les capacités NET_ADMIN et NET_RAW de conteneurs non approuvés

Les capacités NET_ADMIN et NET_RAW de Linux peuvent être exploitées par des personnes mal intentionnées pour compromettre le réseau de l'espace. Vous devez désactiver ces deux capacités de conteneurs non approuvés. Par défaut, la capacité NET_ADMIN n'est pas accordée à un conteneur sans privilège. Faites attention si une spécification d'espace l'active explicitement ou définit le conteneur en mode privilégié. En outre, pour les conteneurs non approuvés, désactivez NET_RAW en spécifiant NET_RAW dans la liste des capacités abandonnées dans la configuration SecurityContext de la spécification du conteneur. Par exemple,

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

Contrôle d'accès basé sur les rôles

Kubernetes utilise des API de contrôle d'accès basé sur les rôles (RBAC) pour prendre les décisions d'autorisation, ce qui permet aux administrateurs de configurer des stratégies de manière dynamique. Pour plus d'informations, consultez https://kubernetes.io/docs/admin/authorization/rbac.

En général, l'administrateur de cluster est le seul utilisateur avec un accès et des rôles avec privilèges. Pour les comptes d'utilisateur et de service, la séparation des privilèges doit être respectée lorsque vous accordez l'accès.

Les directives suivantes sont recommandées :

  • Restreindre l'accès aux jetons Kubernetes API aux espaces qui en ont besoin.
  • Restreindre l'accès aux secrets TLS du certificat client NCP ConfigMap et NSX API à l'espace NCP.
  • Bloquer l'accès à l'API de mise en réseau de Kubernetes depuis les espaces qui ne nécessitent pas ce type d'accès.
  • Ajouter une stratégie RBAC Kubernetes pour spécifier les espaces qui peuvent avoir accès à l'API Kubernetes.

Stratégie RBAC recommandée pour l'espace NCP

Créez l'espace NCP sous un ServiceAccount et donnez à ce compte un ensemble de privilèges minimal. De plus, n'autorisez pas les autres espaces ou ReplicationControllers à accéder aux ConfigMap et Secrets TLS qui sont montés en tant que volumes pour ReplicationController NCP et l'agent de nœud NSX.

L'exemple suivant montre comment spécifier des rôles et des liaisons de rôle pour 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
Note : Le Secret TLS qui est créé à l'aide de l'API Kubernetes pour le certificat client NSX-T Data Center et la paire de clés privées sont accessibles à tous les espaces qui ont accès au serveur API Kubernetes. De même, quand un espace est créé sans compte de service, il se voit attribuer automatiquement le compte de service par défaut dans le même espace de noms, ce qui monte automatiquement le jeton pour accéder à l'API Kubernetes. Par conséquent, l'accès à ces jetons doit être limité aux espaces qui en ont besoin.