Mise à jour SUSE® Security

Mise à jour SUSE® Security des composants

Il est très facile de mettre à jour vos SUSE® Security conteneurs. S’il y a une nouvelle version disponible, tirez-la depuis Docker Hub. Il est recommandé d’utiliser une ‘rolling update’ stratégie pour maintenir au moins un conteneur Allinone ou Controller en fonctionnement à tout moment pendant une mise à jour.

Les mises à jour du système d’exploitation hôte, les redémarrages et les mises à jour de l’orchestrateur peuvent entraîner l’éviction ou l’arrêt des pods. Si un Controller est affecté, et qu’aucun autre Controller n’est actif pour maintenir l’état, les Controllers peuvent être disponibles pendant un certain temps pendant que de nouveaux controllers sont démarrés, qu’un cluster se forme avec un leader, et qu’on tente d’accéder à la sauvegarde du stockage persistant de la configuration pour restaurer le cluster. Faites attention lors de la planification des mises à jour et des redémarrages de l’hôte ou de l’orchestrateur qui peuvent affecter le nombre de controllers disponibles à tout moment. Voir le budget de perturbation des pods ci-dessous pour des moyens possibles d’atténuer cela.

Si le déploiement a été effectué à l’aide des SUSE® Security charts Helm, la mise à jour s’occupera des services supplémentaires, des liaisons de rôle ou d’autres exigences de mise à niveau.

Si les mises à jour sont effectuées manuellement ou s’il n’y a qu’un seul Allinone ou Controller en cours d’exécution, veuillez noter que les données de connexion réseau actuelles NE SONT PAS stockées et seront perdues lorsque le SUSE® Security conteneur sera arrêté.

SUSE® Security prend en charge les données persistantes pour la SUSE® Security stratégie et la configuration. Cela configure une sauvegarde en temps réel pour monter un volume à /var/neuvector/. Le cas d’utilisation principal est que, lorsque le volume persistant est monté, la configuration et la stratégie sont stockées pendant l’exécution dans le volume persistant. En cas de défaillance totale du cluster, la configuration est automatiquement restaurée lorsque le nouveau cluster est créé. La configuration et la stratégie peuvent également être restaurées ou supprimées manuellement du volume /var/neuvector/.

Si un volume persistant n’est pas monté, SUSE® Security NE stocke PAS la configuration ou la stratégie en tant que données persistantes. Assurez-vous de sauvegarder la configuration et la stratégie du Controller avant d’arrêter le conteneur allinone ou controller. Cela peut être fait dans les Paramètres → Configuration. Alternativement, le contrôleur peut être déployé dans une configuration HA avec 3 ou 5 contrôleurs en fonctionnement, auquel cas la stratégie persistera avec d’autres contrôleurs pendant qu’un est en cours de mise à jour.

Pour mettre à jour SUSE® Security manuellement en utilisant docker-compose :

sudo docker-compose -f <filename> down

Si aucun nom de fichier n’est spécifié, le fichier docker-compose.yml est utilisé.

Assurez-vous que le fichier docker-compose.yml ou un autre fichier approprié est modifié avec la version d’image souhaitée, si nécessaire, puis :

$sudo docker-compose -f <filename> up -d

Nous recommandons que tous les SUSE® Security composants soient mis à jour vers la version la plus récente en même temps. La compatibilité descendante est prise en charge pour au moins une version mineure en arrière. Bien que la plupart des anciennes versions soient compatibles avec les versions antérieures, il peut y avoir des exceptions qui provoquent un comportement inattendu.

Mises à jour progressives

Des outils d’orchestration tels que Kubernetes, RedHat OpenShift et Rancher prennent en charge les mises à jour progressives avec des stratégies configurables. Vous pouvez utiliser cette fonctionnalité pour mettre à jour les SUSE® Security conteneurs. Le plus important sera de s’assurer qu’il y a au moins un Allinone/Controller en fonctionnement afin que les stratégies, les journaux et les données de connexion ne soient pas perdus. Assurez-vous qu’il y a un minimum de 30 secondes entre les mises à jour des conteneurs afin qu’un nouveau leader puisse être élu et que les données soient synchronisées entre les contrôleurs.

Exemple de mise à jour progressive Kubernetes

Si votre Déploiement ou Daemonset est déjà en cours d’exécution, vous pouvez modifier le fichier yaml vers la nouvelle version, puis appliquer la mise à jour :

kubectl apply -f <yaml file>

Pour mettre à jour vers une nouvelle version de SUSE® Security depuis la ligne de commande.

kubectl set image deployment/neuvector-controller-pod neuvector-controller-pod=neuvector/controller:4.2.2 -n neuvector
kubectl set image deployment/neuvector-manager-pod neuvector-manager-pod=neuvector/manager:4.2.2 -n neuvector
kubectl set image DaemonSet/neuvector-enforcer-pod neuvector-enforcer-pod=neuvector/enforcer:4.2.2 -n neuvector

Pour vérifier l’état de la mise à jour progressive :

kubectl rollout status -n neuvector ds/neuvector-enforcer-pod
kubectl rollout status -n neuvector deployment/neuvector-controller-pod  # same for manager, scanner etc

Pour le retour à l’état initial de la mise à jour :

kubectl rollout undo -n neuvector ds/neuvector-enforcer-pod
kubectl rollout undo -n neuvector deployment/neuvector-controller-pod  # same for manager, scanner etc

Mise à jour de la base de données des vulnérabilités CVE

L’image du SUSE® Security Scanner est régulièrement mise à jour sur neuvector avec de nouvelles mises à jour de la base de données CVE, en utilisant le tag 'latest'.

Le SUSE® Security déploiement par défaut inclut le déploiement de pods de scanner ainsi qu’un travail cron Updater pour mettre à jour les scanners chaque jour.

Veuillez consulter la section Mettre à jour la base de données CVE pour plus de détails.

La version de la base de données CVE peut être vue dans la Console dans l’onglet Vulnérabilités. Vous pouvez également inspecter l’image du conteneur Updater. Le dernier numéro de version de la base de données est également indiqué ici.

docker inspect neuvector/updater

"Labels": {
                "neuvector.image": "neuvector/updater",
                "neuvector.role": "updater",
                "neuvector.vuln_db": "1.255"
            }

Vous pouvez également inspecter les journaux du contrôleur/allinone pour 'version.' Par exemple dans Kubernetes :

kubectl logs neuvector-controller-pod-777fdc5668-4jkjn -n neuvector | grep version

2019-07-29T17:04:02.43 |DEBU|SCN|main.dbUpdate: New DB found - create=2019-07-24T11:59:13Z version=1.576
2019-07-29T17:04:02.454|DEBU|SCN|memdb.ReadCveDb: New DB found - update=2019-07-24T11:59:13Z version=1.576
2019-07-29T17:04:12.224|DEBU|SCN|main.scannerRegister: - version=1.576

Budget de perturbation des pods

Une fonctionnalité de Kubernetes permet de garantir qu’un nombre minimum de contrôleurs fonctionnent à tout moment. Ceci est utile pour le drainage des nœuds ou d’autres activités de maintenance qui pourraient entraîner la suppression de pods de contrôleur. Par exemple, créez et appliquez le fichier ci-dessous nv_pdb.yaml pour garantir qu’il y ait au moins 2 contrôleurs fonctionnant à tout moment.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: neuvector-controller-pdb
  namespace: neuvector
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: neuvector-controller-pod

Mise à niveau de SUSE® Security 4.x vers 5.1.x

Mettez d’abord à niveau vers une version 5.1.x telle que 5.1.3, puis consultez la section de déploiement Kubernetes pour la mise à niveau vers 5.2.x+ pour des changements importants concernant les comptes de services et les liaisons.

Pour les utilisateurs de Helm, mettez à jour vers le SUSE® Security chart Helm 2.0.0 ou ultérieur (avant SUSE® Security 5.2.0). Si vous mettez à jour un opérateur ou une installation Helm sur OpenShift, consultez la note ci-dessous.

Supprimez l’ancienne définition de rôle de cluster neuvector-binding-customresourcedefinition
```
kubectl delete clusterrole neuvector-binding-customresourcedefinition
```

Appliquez le nouveau verbe de mise à jour pour le rôle de cluster neuvector-binding-customresourcedefinition

kubectl create clusterrole neuvector-binding-customresourcedefinition --verb=watch,create,get,update --resource=customresourcedefinitions

Supprimez l’ancien schéma crd pour Kubernetes 1.19+

kubectl delete -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/crd-k8s-1.19.yaml

Créez un nouveau schéma crd pour Kubernetes 1.19+

kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/waf-crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/dlp-crd-k8s-1.19.yaml
kubectl apply -f https://raw.githubusercontent.com/neuvector/manifests/main/kubernetes/5.0.0/admission-crd-k8s-1.19.yaml

Créez un nouveau rôle de cluster DLP, WAP, Admission et un lien de rôle de cluster

kubectl create clusterrole neuvector-binding-nvwafsecurityrules --verb=list,delete --resource=nvwafsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvwafsecurityrules --clusterrole=neuvector-binding-nvwafsecurityrules --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-nvadmissioncontrolsecurityrules --verb=list,delete --resource=nvadmissioncontrolsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvadmissioncontrolsecurityrules --clusterrole=neuvector-binding-nvadmissioncontrolsecurityrules --serviceaccount=neuvector:default
kubectl create clusterrole neuvector-binding-nvdlpsecurityrules --verb=list,delete --resource=nvdlpsecurityrules
kubectl create clusterrolebinding neuvector-binding-nvdlpsecurityrules --clusterrole=neuvector-binding-nvdlpsecurityrules --serviceaccount=neuvector:default

Mettez à jour les noms et les chemins d’image pour récupérer les SUSE® Security images depuis Docker Hub (docker.io). Les images se trouvent sur le SUSE® Security registre Docker Hub. Utilisez le tag de version approprié pour le manager, le contrôleur, l’enforcer, et laissez la version comme 'latest' pour le Scanner et l’Updater. Par exemple :
- neuvector/manager:5.1.3
- neuvector/controller:5.1.3
- neuvector/enforcer:5.1.3
- neuvector/scanner:latest
- neuvector/updater:latest

En option, supprimez toutes les références à la licence SUSE® Security et aux secrets dans les charts Helm, le yaml de déploiement, le configmap, les scripts, etc., car ceux-ci ne sont plus nécessaires pour tirer les images ou commencer à utiliser SUSE® Security.

Remarque concernant SCC et la mise à niveau via Operator/Helm

Le SCC privilégié est ajouté au compte de service spécifié dans le yaml de déploiement par la version 1.3.4 de l’Operator et au-delà dans les nouveaux déploiements. Dans le cas de la mise à niveau de SUSE® Security l’Operator d’une version précédente à 1.3.4 ou de Helm à 2.0.0, veuillez supprimer le SCC privilégié avant la mise à niveau.

oc delete rolebinding -n neuvector system:openshift:scc:privileged