Aktualisierung SUSE® Security

Aktualisierung der SUSE® Security-Komponenten

Es ist super einfach, Ihre SUSE® Security Container zu aktualisieren. Wenn eine neue Version verfügbar ist, ziehen Sie sie von Docker Hub. Es wird empfohlen, eine ‘rolling update’ Strategie zu verwenden, um jederzeit mindestens einen All-in-One- oder Controller-Container während eines Updates laufen zu lassen.

Updates des Host-Betriebssystems, Neustarts und Orchestrator-Updates können dazu führen, dass Pods verdrängt oder gestoppt werden. Wenn ein Controller betroffen ist und keine anderen aktiven Controller vorhanden sind, um den Zustand aufrechtzuerhalten, können die Controller für einige Zeit verfügbar sein, während neue Controller gestartet werden, ein Cluster mit einem Leader gebildet wird und versucht wird, auf das Sicherungsbackup des persistenten Speichers der Konfiguration zuzugreifen, um das Cluster wiederherzustellen. Seien Sie vorsichtig, wenn Sie Host- oder Orchestrator-Updates und Neustarts planen, die die Anzahl der zu jedem Zeitpunkt verfügbaren Controller beeinträchtigen können. Siehe das Pod Disruption Budget unten für mögliche Möglichkeiten, dies zu mildern.

Wenn das Deployment mit den SUSE® Security Helm-Charts durchgeführt wurde, kümmert sich das Aktualisieren um zusätzliche Dienste, Rollenbindungen oder andere Upgrade-Anforderungen.

Wenn Updates manuell durchgeführt werden oder nur ein All-in-One- oder Controller-Container läuft, beachten Sie bitte, dass die aktuellen Netzwerkverbindungsdaten NICHT gespeichert werden und verloren gehen, wenn der SUSE® Security Container gestoppt wird.

SUSE® Security unterstützt persistente Daten für die SUSE® Security Richtlinie und Konfiguration. Dies konfiguriert ein Echtzeit-Backup, um ein Volume unter /var/neuvector/ zu mounten. Der Hauptanwendungsfall ist, wenn das persistente Volume gemountet ist, dass die Konfiguration und Richtlinie zur Laufzeit im persistenten Volume gespeichert werden. Im Falle eines totalen Ausfalls des Clusters wird die Konfiguration automatisch wiederhergestellt, wenn das neue Cluster erstellt wird. Konfiguration und Richtlinie können auch manuell aus dem /var/neuvector/ Volume wiederhergestellt oder entfernt werden.

Wenn ein persistentes Volume nicht gemountet ist, speichert SUSE® Security die Konfiguration oder Richtlinie NICHT als persistente Daten. Stellen Sie sicher, dass Sie die Konfiguration und Richtlinie des Controllers sichern, bevor Sie den All-in-One- oder Controller-Container stoppen. Dies kann in den Einstellungen → Konfiguration erfolgen. Alternativ kann der Controller in einer HA-Konfiguration mit 3 oder 5 laufenden Controllern bereitgestellt werden, wobei die Richtlinie mit anderen Controllern bestehen bleibt, während einer aktualisiert wird.

Um SUSE® Security manuell mit docker-compose zu aktualisieren:

sudo docker-compose -f <filename> down

Wenn kein Dateiname angegeben ist, wird die Datei docker-compose.yml verwendet.

Stellen Sie sicher, dass die docker-compose.yml oder eine andere geeignete Datei mit der gewünschten Bildversion bearbeitet wird, falls erforderlich, dann:

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

Wir empfehlen, dass alle SUSE® Security-Komponenten gleichzeitig auf die neueste Version aktualisiert werden. Die Abwärtskompatibilität wird für mindestens eine kleinere Version unterstützt. Obwohl die meisten älteren Versionen abwärtskompatibel sind, kann es Ausnahmen geben, die unerwartetes Verhalten verursachen.

Rolling Updates

Orchestrierungstools wie Kubernetes, RedHat OpenShift und Rancher unterstützen Rolling Updates mit konfigurierbaren Richtlinien. Sie können diese Funktion nutzen, um die SUSE® Security-Container zu aktualisieren. Am wichtigsten ist, dass sich mindestens ein All-in-One/Controller im Betrieb befindet, damit Richtlinien, Protokolle und Verbindungsdaten nicht verloren gehen. Stellen Sie sicher, dass zwischen den Container-Updates mindestens 30 Sekunden liegen, damit ein neuer Leader gewählt und die Daten zwischen den Controllern synchronisiert werden können.

Beispiel für ein Kubernetes Rolling Update

Wenn Ihr Deployment oder Daemonset bereits läuft, können Sie die yaml-Datei auf die neue Version ändern und dann die Aktualisierung anwenden:

kubectl apply -f <yaml file>

Um von der Befehlszeile auf eine neue Version von SUSE® Security zu aktualisieren.

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

Um den Status des Rolling Updates zu überprüfen:

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

Um das Update-Rollback durchzuführen:

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

Aktualisierung der CVE-Datenbank für Schwachstellen

Das SUSE® Security Scanner-Bild wird regelmäßig auf Neuvector mit neuen CVE-Datenbank-Updates unter Verwendung des 'latest'-Tags aktualisiert.

Die Standard-SUSE® Security Bereitstellung umfasst die Bereitstellung von Scanner-Pods sowie einen Updater-Cron-Job, um die Scanner täglich zu aktualisieren.

Bitte sehen Sie sich den Abschnitt Aktualisierung der CVE-Datenbank für weitere Details an.

Die Version der CVE-Datenbank kann in der Konsole im Tab "Schwachstellen" eingesehen werden. Sie können auch das Updater-Container-Image inspizieren. Die neueste Versionsnummer der Datenbank ist ebenfalls hier aufgeführt.

docker inspect neuvector/updater

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

Sie können auch die Protokolle des Controllers/allinone auf 'Version' überprüfen. Zum Beispiel in 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

Pod Disruption Budget

Eine Kubernetes-Funktion ermöglicht es, sicherzustellen, dass zu jeder Zeit eine Mindestanzahl von Controllern läuft. Dies ist nützlich für das Entleeren von Knoten oder andere Wartungsaktivitäten, die Controller-Pods entfernen könnten. Erstellen und wenden Sie beispielsweise die Datei unten nv_pdb.yaml an, um sicherzustellen, dass zu jeder Zeit mindestens 2 Controller laufen.

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

Upgrade von SUSE® Security 4.x auf 5.1.x

Upgrade zuerst auf eine 5.1.x-Version wie 5.1.3, und sehen Sie sich dann den Abschnitt Kubernetes-Bereitstellungsabschnitt für das Aktualisieren auf 5.2.x+ an, um wichtige Änderungen an Dienstkonten und Bindungen zu berücksichtigen.

Für Helm-Benutzer, aktualisieren Sie auf SUSE® Security Helm-Chart 2.0.0 oder später (vor SUSE® Security 5.2.0). Wenn Sie einen Operator oder eine Helm-Installation auf OpenShift aktualisieren, beachten Sie die folgende Anmerkung.

Löschen Sie die alte neuvector-binding-customresourcedefinition-Clusterrolle.
```
kubectl delete clusterrole neuvector-binding-customresourcedefinition
```

Wenden Sie das neue Aktualisieren-Verb für die neuvector-binding-customresourcedefinition-Clusterrolle an.

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

Löschen Sie das alte CRD-Schema für Kubernetes 1.19+

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

Erstellen Sie ein neues CRD-Schema für 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

Erstellen Sie eine neue DLP-, WAP-, Admission-Clusterrolle und Clusterrollenbindung.

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

Aktualisieren Sie die Bildnamen und -pfade für das Abrufen von SUSE® Security Bildern aus dem Docker Hub (docker.io). Die Bilder befinden sich in der SUSE® Security Docker-Hub-Registry. Verwenden Sie das entsprechende Versions-Tag für den Manager, Controller, Enforcer und lassen Sie die Version für Scanner und Updater als 'latest'. Beispiel:
- neuvector/manager:5.1.3
- neuvector/controller:5.1.3
- neuvector/enforcer:5.1.3
- neuvector/scanner:latest
- neuvector/updater:latest

Optional können Sie alle Verweise auf die SUSE® Security Lizenz und Geheimnisse in Helm-Charts, Deployment-YAML, ConfigMap, Skripten usw. entfernen, da diese nicht mehr erforderlich sind, um die Bilder abzurufen oder SUSE® Security zu verwenden.

Hinweis zu SCC und Upgrade über Operator/Helm

Privileged SCC wird dem in der Deployment-YAML angegebenen Service-Konto durch die Operator-Version 1.3.4 und höher in neuen Deployments hinzugefügt. Im Falle eines Upgrades des SUSE® Security Operators von einer vorherigen Version auf 1.3.4 oder Helm auf 2.0.0, löschen Sie bitte Privileged SCC vor dem Upgrade.

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