Bereitstellung SUSE® Security

Planung von Bereitstellungen

Die SUSE® Security Container in einer Standardbereitstellung umfassen den Controller, Manager, Enforcer, Scanner und Updater. Die Platzierung, wo diese Container (auf welchen Knoten) bereitgestellt werden, muss berücksichtigt werden, und geeignete Labels, Taints oder Toleranzen müssen erstellt werden, um sie zu steuern.

Der Enforcer sollte auf jedem Host/Knoten bereitgestellt werden, auf dem die Anwendungscontainer, die von SUSE® Security überwacht und geschützt werden sollen, ausgeführt werden.

Der Controller verwaltet den Cluster der Enforcer und kann auf demselben Knoten wie ein Enforcer oder auf einem separaten Verwaltungs-Knoten bereitgestellt werden. Der Manager sollte auf dem Knoten bereitgestellt werden, auf dem der Controller läuft, und wird Konsolenzugriff auf den Controller bieten. Andere erforderliche SUSE® Security Container wie der Manager, Scanner und Updater werden im Best Practices-Leitfaden, auf den unten verwiesen wird, ausführlicher beschrieben.

Wenn Sie dies noch nicht getan haben, ziehen Sie die Bilder vom SUSE® Security Docker Hub.

Die Bilder befinden sich im 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.3.2

  • neuvector/controller:5.3.2

  • neuvector/enforcer:5.3.2

  • neuvector/scanner:latest

  • neuvector/updater:latest

Bitte stellen Sie sicher, dass Sie die Bildreferenzen in den entsprechenden YAML-Dateien aktualisieren.

Wenn Sie mit dem aktuellen SUSE® Security Helm-Chart (v1.8.9+) bereitstellen, sollten die folgenden Änderungen an values.yml vorgenommen werden:

  • Aktualisieren Sie das Registry auf docker.io

  • Aktualisieren Sie die Bildnamen und Tags auf die aktuelle Version auf Docker Hub, wie oben gezeigt

  • Lassen Sie die imagePullSecrets leer

Best Practices, Tipps, Fragen und Antworten zum Bereitstellen und Verwalten von SUSE® Security

Bereitstellung mit Helm oder Operatoren

Automatisierte Bereitstellung mit Helm finden Sie unter https://github.com/neuvector/neuvector-helm.

Die Bereitstellung mit einem Operator, einschließlich des RedHat-zertifizierten Operators und des Kubernetes-Community-Operators, wird unterstützt, mit einer allgemeinen Beschreibung hier. Der SUSE® Security RedHat-Operator befindet sich unter https://access.redhat.com/containers/#/registry.connect.redhat.com/neuvector/neuvector_operator, und der Community_Operator unter https://operatorhub.io/operator/neuvector_operator.

Bereitstellung mit ConfigMap

Die automatisierte Bereitstellung auf Kubernetes wird mit einer ConfigMap unterstützt. Bitte sehen Sie sich den Abschnitt Bereitstellung mit ConfigMap für weitere Details an.

Bereitstellung der Controller

Wir empfehlen, mehrere Controller für eine Konfiguration für hohe Verfügbarkeit (HA) auszuführen. Die Controller verwenden das konsensbasierte RAFT-Protokoll, um einen Leader zu wählen, und wenn der Leader ausfällt, einen neuen Leader zu bestimmen. Aus diesem Grund sollte die Anzahl der aktiven Controller eine ungerade Zahl sein, zum Beispiel 3, 5, 7 usw.

Controller HA

Die Controller synchronisieren alle Daten untereinander, einschließlich Konfiguration, Richtlinien, Gespräche, Ereignisse und Benachrichtigungen.

Wenn der primäre aktive Controller ausfällt, wird automatisch ein neuer Leader gewählt und übernimmt.

Treffen Sie besondere Vorkehrungen, um sicherzustellen, dass immer ein Controller läuft und bereit ist, insbesondere während Updates und Neustarts des Host-Betriebssystems oder der Orchestrierungsplattform.

Backups und persistente Daten

Stellen Sie sicher, dass Sie die Konfigurationsdatei regelmäßig aus der Konsole exportieren und als Sicherung speichern.

Wenn Sie mehrere Controller in einer HA-Konfiguration betreiben, werden alle Daten zwischen den Controllern synchronisiert, solange mindestens ein Controller immer aktiv ist.

Wenn Sie Protokolle wie Verstöße, Bedrohungen, Schwachstellen und Ereignisse speichern möchten, aktivieren Sie bitte den SYSLOG-Server in den Einstellungen.

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/ vom Controller-Pod zu mounten. Der Hauptanwendungsfall besteht darin, dass, wenn das persistente Volume gemountet ist, die Konfiguration und die Richtlinie zur Laufzeit in diesem Volume gespeichert werden. Im Falle eines totalen Ausfalls des Clusters wird die Konfiguration automatisch wiederhergestellt, wenn das neue Cluster erstellt wird. Die Konfiguration und Richtlinie können auch manuell vom /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 Settings → Configuration 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.

Beispiel für ein persistentes Volume

Das im Cluster definierte PersistentVolume ist für die Unterstützung von persistenten Volumes erforderlich. Die Anforderung für SUSE® Security ist, dass der Zugriffsmodus ReadWriteMany (RWX) sein muss. Nicht alle Speichertypen unterstützen den RWX-Zugriffsmodus. Zum Beispiel müssen Sie auf GKE möglicherweise ein RWX-persistentes Volume mit NFS-Speicher erstellen.

Sobald das PersistentVolume erstellt ist, muss ein PersistentVolumeClaim wie unten für den Controller erstellt werden. Derzeit wird das persistente Volume nur für die SUSE® Security Konfigurationssicherungsdateien im Controller (Richtlinien, Regeln, Benutzerdaten, Integrationen usw.) und die Ergebnisse des Registry-Scans verwendet.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: neuvector-data
  namespace: neuvector
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 1Gi

Hier ist ein Beispiel für IBM Cloud:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: neuvector-data
  namespace: neuvector
  labels:
    billingType: "hourly"
    region: us-south
    zone: sjc03
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
      iops: "100"
  storageClassName: ibmc-file-retain-custom

Nachdem der Persistent Volume Claim erstellt wurde, ändern Sie die SUSE® Security Beispiel-YAML-Datei wie unten gezeigt (alter Abschnitt auskommentiert):

...
spec:
  template:
    spec:
      volumes:
        - name: nv-share
#         hostPath:                        // replaced by persistentVolumeClaim
#           path: /var/neuvector        // replaced by persistentVolumeClaim
          persistentVolumeClaim:
            claimName: neuvector-data

Fügen Sie auch die folgende Umgebungsvariable in den Controller- oder All-in-One-Beispiel-YAMLs für die Unterstützung von persistenten Volumes hinzu. Dies wird dazu führen, dass der Controller die Sicherungskonfiguration beim Starten liest.

            - name: CTRL_PERSIST_CONFIG

ConfigMaps und Persistenter Speicher

Sowohl die ConfigMaps als auch die Sicherung des persistenten Speichers werden nur gelesen, wenn ein neuer SUSE® Security Cluster bereitgestellt wird oder der Cluster ausfällt und neu gestartet wird. Sie werden während der Rolling-Upgrades nicht verwendet.

Das Backup der Konfiguration des persistenten Speichers wird zuerst gelesen, dann werden die ConfigMaps angewendet, sodass die Einstellungen der ConfigMap Vorrang haben. Alle Einstellungen der ConfigMap (z. B. Updates) werden ebenfalls im persistenten Speicher gespeichert.

Für weitere Informationen siehe den Abschnitt ConfigMaps.

Aktualisierung der CVE-Schwachstellendatenbank in der Produktion

Bitte sehen Sie sich jeden Beispielabschnitt an, um Anweisungen zur Aktualisierung der CVE-Datenbank zu erhalten.

Die Version der CVE-Datenbank kann in der Konsole im Tab für Schwachstellen angezeigt werden. Sie können auch das Container-Image des Updaters inspizieren.

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

Nach dem Ausführen des Updates überprüfen Sie die Protokolle des Controllers/All-in-One auf 'Version.' 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

Zugriff auf die Konsole

Standardmäßig wird die Konsole als Dienst auf Port 8443 oder als NodePort mit einem zufälligen Port auf jedem Host bereitgestellt. Bitte sehen Sie sich den ersten Abschnitt Grundlagen → Mit Manager verbinden für Optionen an, um HTTPS zu deaktivieren oder auf die Konsole über eine Unternehmensfirewall zuzugreifen, die den Port 8443 für den Konsolenzugriff nicht zulässt.

Verwaltung von Host-Updates oder automatischem Skalieren von Knoten mit einem Pod-Störungsbudget

Wartungs- oder Skalierungsaktivitäten können die Controller auf Knoten beeinflussen. Public Cloud-Anbieter unterstützen die Möglichkeit, Knoten automatisch zu skalieren, was Pods, einschließlich der SUSE® Security Controller, dynamisch verdrängen kann. Um Störungen der Controller zu verhindern, kann ein SUSE® Security Pod-Störungsbudget erstellt werden.

Erstellen Sie beispielsweise die untenstehende Datei nv_pdb.yaml, um sicherzustellen, dass jederzeit mindestens 2 Controller ausgeführt werden.

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

Dann

kubectl create -f nv_pdb.yaml

Für weitere Details: https://kubernetes.io/docs/tasks/run-application/configure-pdb/

Bereitstellung ohne privilegierten Modus

Auf einigen Systemen wird die Bereitstellung ohne Verwendung des privilegierten Modus unterstützt. Diese Systeme müssen seccomp-Funktionen und das Setzen des AppArmor-Profils unterstützen.

Siehe den Abschnitt über Docker-Bereitstellung für Beispiel-Compose-Dateien.

Multi-Site, Multi-Cluster-Architektur

Für Unternehmen mit mehreren Standorten, an denen für jeden Standort ein separates SUSE® Security Cluster bereitgestellt werden kann, wird die folgende Referenzarchitektur vorgeschlagen. Jedes Cluster hat seine eigene Gruppe von Controllern und wird separat verwaltet.

Multi-Site

Siehe eine detailliertere Beschreibung in dieser Datei > SUSE® Security Multi-Site-Architektur