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.
La stratégie RBAC recommandée se trouve déjà dans le fichier YAML NCP et sera efficace lorsque vous installerez NCP.