Déploiement de Rancher

Déployer et gérer SUSE® Security via les extensions Rancher ou Apps et Marketplace

SUSE® Security peut être déployé facilement soit via les extensions Rancher pour les clients Prime, soit via Apps et Marketplace de Rancher. Le déploiement par défaut (basé sur Helm) de SUSE® Security déploiera SUSE® Security conteneurs dans l’espace de noms cattle-neuvector-system.

Seuls les déploiements de SUSE® Security via les extensions Rancher (SUSE® Security) de la version 2.7.0+ de Rancher, ou Apps et Marketplace de la version 2.6.5+ de Rancher peuvent être gérés directement (authentification unique à la console SUSE® Security) via Rancher. Si des clusters sont ajoutés à Rancher avec SUSE® Security déjà déployé, ou si SUSE® Security a été déployé directement sur le cluster, ces clusters ne seront pas activés pour l’intégration SSO.

SUSE® Security Extension UI pour Rancher

Les clients Prime de Rancher peuvent facilement déployer SUSE® Security et l’extension UI SUSE® Security pour Rancher. Cela permettra aux utilisateurs Prime de surveiller et de gérer certaines fonctions et événements de SUSE® Security directement via l’interface utilisateur de Rancher. Pour les utilisateurs de la communauté, veuillez consulter la section Déployer SUSE® Security ci-dessous pour déployer depuis Apps et Marketplace de Rancher.

La première étape consiste à activer la capacité des extensions Rancher globalement si elle n’est pas déjà activée.
Installez l’extension SUSE® Security-UI à partir de la liste des extensions disponibles
Rechargez l’extension une fois l’installation terminée
Sur votre cluster sélectionné, installez l’App SUSE® Security à partir de l’onglet SUSE® Security si l’App SUSE® Security n’est pas déjà installée. Cela devrait vous amener aux étapes d’installation de l’App. Pour plus de détails sur ce processus d’installation, consultez la section Déployer SUSE® Security ci-dessous.
Le SUSE® Security tableau de bord devrait maintenant être affiché depuis le menu SUSE® Security pour ce cluster. Depuis ce tableau de bord, un résumé de la santé de la sécurité du cluster peut être surveillé. Il y a des éléments interactifs dans le tableau de bord, tels que l’invocation d’un assistant pour améliorer votre score (risque de sécurité), y compris la possibilité d’activer la numérisation automatisée des vulnérabilités si elle n’est pas activée.

De plus, les liens en haut à droite du tableau de bord fournissent des liens pratiques de connexion unique (SSO) vers la console complète SUSE® Security pour une analyse et une configuration plus détaillées.

Pour désinstaller l’extension, retournez à la page des extensions

désinstaller

La désinstallation de l’extension UI SUSE® Security ne désinstallera PAS l’App SUSE® Security de chaque cluster. Le menu SUSE® Security reviendra à fournir un lien SSO vers la console SUSE® Security.

Déployer SUSE® Security

Tout d’abord, trouvez le chart SUSE® Security dans les charts Rancher, sélectionnez-le et examinez les instructions et les différentes valeurs de configuration. (Optionnel) Créez un projet dans lequel déployer si désiré, par exemple SUSE® Security. Remarque : Si vous voyez plus d’un chart SUSE® Security, ne sélectionnez pas celui qui est destiné à mettre à niveau les déploiements de charts Helm SUSE® Security 4.x hérités.

rancher_chart

Déployez le chart SUSE® Security, en configurant d’abord des valeurs appropriées pour un déploiement Rancher, telles que :

Type d’exécution de conteneur, par exemple docker pour RKE et containerd pour RKE2, ou sélectionnez la valeur K3s si vous utilisez K3s.
Type de service du gestionnaire : changez en LoadBalancer si disponible sur les déploiements dans le cloud public. Si l’accès est uniquement souhaité via Rancher, toute valeur autorisée fonctionnera ici. Voir la note importante ci-dessous concernant le changement du mot de passe administrateur par défaut dans SUSE® Security.
Indiquez si ce cluster sera soit un primaire fédéré multi-cluster, soit distant (ou sélectionnez les deux si l’une ou l’autre option est souhaitée).
Volume persistant pour les sauvegardes de configuration

nv_values

Cliquez sur 'Installer' après avoir examiné et mis à jour les valeurs du chart.

Après un déploiement SUSE® Security réussi, vous verrez un résumé des déploiements, des ensembles de daemon et des tâches cron pour SUSE® Security. Vous pourrez également voir les services déployés dans le menu Découverte des services à gauche.

déployé

Gérer SUSE® Security

Vous verrez maintenant un élément de menu SUSE® Security à gauche, et en le sélectionnant, vous afficherez un bouton/tile SUSE® Security, qui, lorsqu’il est cliqué, vous amènera à la console SUSE® Security, dans un nouvel onglet.

nv_console

Lorsque cette méthode d’accès par SSO (Single Sign On) est utilisée pour la première fois, un utilisateur correspondant dans le cluster SUSE® Security est créé pour la connexion de l’utilisateur Rancher. Le même nom d’utilisateur que l’utilisateur connecté de Rancher sera créé dans SUSE® Security, avec un rôle d’administrateur ou de fedAdmin, et le fournisseur d’identité comme Rancher.

utilisateurs

Notez dans la capture d’écran ci-dessus que deux utilisateurs Rancher, admin et gkosaka, ont été automatiquement créés pour le SSO. Si un autre utilisateur est créé manuellement dans SUSE® Security, le fournisseur d’identité sera listé comme SUSE® Security, comme indiqué ci-dessous. Cet utilisateur local peut se connecter directement à la console SUSE® Security sans passer par Rancher.

local

Il est recommandé de se connecter directement à la console SUSE® Security en tant qu’admin/admin pour changer manuellement le mot de passe administrateur en un mot de passe fort. Cela ne changera que le mot de passe de l’utilisateur administrateur du fournisseur d’identité SUSE® Security (vous pouvez voir un autre utilisateur administrateur dont le fournisseur d’identité est Rancher). Alternativement, incluez un ConfigMap comme secret dans le déploiement initial depuis Rancher (voir les valeurs du chart pour les paramètres de ConfigMap) pour définir le mot de passe administrateur par défaut sur un mot de passe fort.

Ressources de permission SSO NeuVector/Rancher

L’interface utilisateur de Rancher v2.9.2 permet de sélectionner des ressources de permission NeuVector lors de la création de Global/Cluster/Project/Namespaces rôles. Lorsqu’un utilisateur de Rancher se voit attribuer un rôle avec une ressource de permission NeuVector, la session SSO NeuVector de l’utilisateur se voit attribuer la permission NeuVector respective en conséquence. Cela vise à fournir aux utilisateurs SSO des rôles personnalisés autres que les rôles réservés admin/reader/fedAdmin/fedReader.

Voici les ressources de permission mappées utilisées avec les rôles Global/Cluster/Project/Namespaces applicables.

Ressources de permission mappées pour le rôle `Global/Cluster`

Les utilisateurs devront ajouter manuellement * (Verbes) / services/proxy (Ressource) aux rôles Global/Cluster liés à NeuVector.

Groupes API :

permission.neuvector.com

Verbes :

get    // for read-only(i.e. view)
*      // for read/write(i.e. modify)

Ressources :

NeuVector, à portée de cluster

AdmissionControl
Authentication
CI Scan
Cluster
Federation
Vulnerability

NeuVector, dans un espace de noms

AuditEvents
Authorization
Compliance
Events
Namespace
RegistryScan
RuntimePolicy
RuntimeScan
SecurityEvents
SystemConfig

Ressources de permission mappées pour le rôle `Project/Namespace`

Les utilisateurs devront ajouter manuellement * (Verbes) / services/proxy (Ressource) aux rôles Project/Namespace liés à NeuVector.

Groupes API :

permission.neuvector.com

Verbes :

get    // for read-only(i.e. view)
*      // for read/write(i.e. modify)

Ressources :

NeuVector, dans un espace de noms

AuditEvents
Authorization
Compliance
Events
Namespace
RegistryScan
RuntimePolicy
RuntimeScan
SecurityEvents
SystemConfig

Désactivation de SUSE® Security/Rancher SSO

Pour désactiver la possibilité de se connecter à SUSE® Security depuis Rancher Manager, allez dans Paramètres → Configuration.

rancher_sso

Déploiements Hérités de Rancher

Le fichier d’exemple déploiera un gestionnaire et 3 contrôleurs. Il déploiera un enforceur sur chaque nœud. Voir la section inférieure pour spécifier des nœuds de gestionnaire ou de contrôleur dédiés en utilisant des étiquettes de nœud. Remarque : Il n’est pas recommandé de déployer (mettre à l’échelle) plus d’un gestionnaire derrière un équilibreur de charge en raison de problèmes potentiels d’état de session.

Le déploiement sur Rancher 2.x/Kubernetes doit suivre la section de référence Kubernetes et/ou le déploiement basé sur Helm.

Déployez le catalogue docker-compose-dist.yml, les contrôleurs seront déployés sur les nœuds étiquetés, les enforceurs seront déployés sur le reste des nœuds. (Le fichier d’exemple peut être modifié afin que les enforceurs ne soient déployés que sur les nœuds spécifiés.)
Choisissez l’un des contrôleurs pour que le gestionnaire se connecte. Modifiez le fichier de catalogue du gestionnaire docker-compose-manager.yml, définissez CTRL_SERVER_IP sur l’IP du contrôleur, puis déployez le catalogue du gestionnaire.

Voici les fichiers compose d’exemple. Si vous souhaitez déployer uniquement un ou deux des composants, utilisez simplement cette section du fichier.

Fichier d’exemple Compose pour Rancher Manager/Controller/Enforcer :

manager:
   scale: 1
   image: neuvector/manager
   restart: always
   environment:
     - CTRL_SERVER_IP=controller
   ports:
     - 8443:8443
controller:
   scale: 3
   image: neuvector/controller
   restart: always
   privileged: true
   environment:
     - CLUSTER_JOIN_ADDR=controller
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
     - /proc:/host/proc:ro
     - /sys/fs/cgroup:/host/cgroup:ro
     - /var/neuvector:/var/neuvector
enforcer:
   image: neuvector/enforcer
   pid: host
   restart: always
   privileged: true
   environment:
     - CLUSTER_JOIN_ADDR=controller
   volumes:
     - /lib/modules:/lib/modules
     - /var/run/docker.sock:/var/run/docker.sock
     - /proc:/host/proc:ro
     - /sys/fs/cgroup/:/host/cgroup/:ro
   labels:
     io.rancher.scheduler.global: true

Déployer sans mode privilégié

Sur certains systèmes, le déploiement sans utiliser le mode privilégié est pris en charge. Ces systèmes doivent prendre en charge la possibilité d’ajouter des capacités en utilisant le paramètre cap_add et de définir le profil apparmor.

Consultez les sections sur le déploiement avec Docker-Compose, Docker UCP/Datacenter pour obtenir des exemples de fichiers Compose.

Voici un fichier Rancher Compose d’exemple pour un déploiement sans mode privilégié :

manager:
   scale: 1
   image: neuvector/manager
   restart: always
   environment:
     - CTRL_SERVER_IP=controller
   ports:
     - 8443:8443
controller:
   scale: 3
   image: neuvector/controller
   pid: host
   restart: always
   cap_add:
     - SYS_ADMIN
     - NET_ADMIN
     - SYS_PTRACE
   security_opt:
     - apparmor=unconfined
     - seccomp=unconfined
     - label=disable
   environment:
     - CLUSTER_JOIN_ADDR=controller
   volumes:
     - /var/run/docker.sock:/var/run/docker.sock
     - /proc:/host/proc:ro
     - /sys/fs/cgroup:/host/cgroup:ro
     - /var/neuvector:/var/neuvector
enforcer:
   image: neuvector/enforcer
   pid: host
   restart: always
   cap_add:
     - SYS_ADMIN
     - NET_ADMIN
     - SYS_PTRACE
     - IPC_LOCK
   security_opt:
     - apparmor=unconfined
     - seccomp=unconfined
     - label=disable
   environment:
     - CLUSTER_JOIN_ADDR=controller
   volumes:
     - /lib/modules:/lib/modules
     - /var/run/docker.sock:/var/run/docker.sock
     - /proc:/host/proc:ro
     - /sys/fs/cgroup/:/host/cgroup/:ro
   labels:
     io.rancher.scheduler.global: true

Utilisation des étiquettes de nœud pour les nœuds de gestionnaire et de contrôleur

Pour contrôler sur quels nœuds le gestionnaire et le contrôleur sont déployés, étiquetez chaque nœud. Choisissez les nœuds où les contrôleurs doivent être déployés. Étiquetez-les avec "nvcontroller=true". Avec le fichier d’exemple actuel, pas plus d’un contrôleur ne peut s’exécuter sur le même nœud.

Pour le nœud du gestionnaire, étiquetez-le “nvmanager=true”.

Ajoutez des étiquettes dans le fichier yaml. Par exemple, pour le gestionnaire :

   labels:
     io.rancher.scheduler.global: true
     io.rancher.scheduler.affinity:host_label: "nvmanager=true"

Pour le contrôleur :

   labels:
     io.rancher.scheduler.global: true
     io.rancher.scheduler.affinity:host_label: "nvcontroller=true"

Pour l’exécuteur, afin d’empêcher son exécution sur un nœud de contrôleur (si désiré) :

  labels:
     io.rancher.scheduler.global: true
     io.rancher.scheduler.affinity:host_label_ne: "nvcontroller=true"