33. Nessus-Komponenten bereitstellen

Geschätzte Dauer: 1 Tag

Eigentümer der betriebsbereiten Komponente: VULN

Kompetenzprofil: Deployment Engineer

Letzte Aktualisierung: 18. August 2025

Nessus ist ein Sicherheitsscanner für die Support- und Betriebssysteme von Google Distributed Cloud (GDC) mit Air Gap. Es hilft dem Team des Operations Center, Sicherheitslücken in Hardware und Software zu überwachen und darauf zu reagieren.

In diesem Dokument werden die Schritte für die Bereitstellung von Nessus beschrieben. Es wird davon ausgegangen, dass der Bediener, der diese Schritte ausführt, eine OC-Workstation mit PowerShell und WSL verwendet.

33.1. Hinweise

• Zugriff erforderlich

  • Folgen Sie IAM-R0005:
    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-root im Stammadministratorcluster ab.
    • Rufen Sie die Rolle role/system-artifact-management-admin im Namespace gpc-system des Stammadministratorclusters ab.

• Erforderliche Tools

  • kubectl
  • gdcloud
  • helm
  • yq
  • docker

• Lizenzierung

  • Eine Nessus-Lizenz
    • Folgen Sie der Anleitung unter NES-G0004 – How to perform Nessus license preactivation (NES-G0004 – Nessus-Lizenz voraktivieren), um das Voraktivierungs-Bundle „GDCH 1“ vorzubereiten.

Hinweis :gdcloud wird möglicherweise nicht standardmäßig aufgelöst. Wenn nicht, korrigieren Sie den Pfad mit PATH=/root/release:${PATH:?} und versuchen Sie es noch einmal.

33.1.1. Best Practices

33.1.1.1. Upgrades

Bei Upgrades von Versionen vor 1.14 müssen Sie vor der Installation die Option „Optional: Uninstall“ (Optional: Deinstallieren) in jedem Hauptabschnitt dieses Leitfadens ausführen.

Bei Neuinstallationen folgen Sie dem Abschnitt „Optional: Deinstallieren“ in jedem Hauptabschnitt dieses Leitfadens.

33.1.1.2. Umgang mit Versionsabweichungen zwischen Organisationen und Zonen

Es sollte keine Probleme aufgrund von Versionsabweichungen zwischen Organisationen und Zonen geben. Bitte folgen Sie der organisationsspezifischen Anleitung und berücksichtigen Sie dabei die Version der Organisation. Jede Bereitstellung ist dann pro Zone unabhängig.

33.1.2. Tenable.sc-Lizenz

Tenablesc ist eine lizenzierte Drittanbieter-Software, für deren Betrieb eine Lizenzdatei erforderlich ist. Bevor Sie fortfahren, muss eine Tenable-Lizenz gemäß der SBOM erworben werden. In besonderen Fällen können wir möglicherweise eine Lizenz ausstellen.

Die Lizenzdatei sollte einen Namen wie SecurityCenter-<version>-1000IPs-<uid>.key haben. Suchen Sie diese Datei und notieren Sie sich den Speicherort, da sie direkt in die Tenable.sc-Benutzeroberfläche hochgeladen werden muss.

Voraussetzungen:

• Eine TenableSC-Lizenzdatei mit einem IP-Limit von mindestens 1.000 und dem Hostnamen tenablesc-as1

33.2. Nessus-Bereitstellungsdateien suchen

Bevor Sie Nessus bereitstellen, führen Sie die folgenden Schritte mit Windows PowerShell aus, um die Nessus-Installationsdateien zu finden:

1. Auf die Nessus-Helm-Charts und das VM-Image zugreifen:

   Im OC sind sie unter \\<dc-prefix>-hyperv1\OpsCenter\tenable-nessus verfügbar.

   ./operations_center/tenable-nessus/
   ├── rhel-8.6-x86_64-kvm-tenablesc.qcow2    # Tenable.sc server image
   ├── tenablesc-automation-bundle-v6n.tar    # Tenable.sc automation bundle
   ├── tenablesc-admin.tgz                    # Ops admin Tenable.sc Helm chart
   └── tenablesc-vms.tgz                      # Ops admin Tenable.sc Helm chart for VM
   

2. Verschieben Sie diese Dateien zur späteren Verwendung auf Ihre lokale Workstation:

   # Eg "\\dc1-hyperv1\OpsCenter\tenable-nessus\*"
   $OPS_TENABLE_RESOURCES = ""
   
   mkdir $env:USERPROFILE\tenable-nessus
   Copy-Item ${OPS_TENABLE_RESOURCES} $env:USERPROFILE\tenable-nessus
   

33.3. Nessus-Voraktivierungs-Bundle finden

Wichtig: Dieser Schritt ist für Upgrades nicht erforderlich.

Das Nessus-Voraktivierungs-Bundle ist spezifisch für jede Installation von Nessus und kann daher nicht im Operations Center-Bundle enthalten sein. Folgen Sie der Nessus-Anleitung NES-G0004 – How to perform Nessus license preactivation (NES-G0004 – So führen Sie die Voraktivierung der Nessus-Lizenz durch), um das Voraktivierungs-Bundle „GDCH 1“ vorzubereiten, bevor Sie fortfahren.

1. Rufen Sie nessus-preact-gdch1.tar.gz auf einem mit dem Internet verbundenen Computer selbst oder über einen Google Engineering-POC ab.

2. Übertragen Sie diese Datei auf Ihre Workstation und legen Sie sie unter $env:USERPROFILE\tenable-nessus ab.

3. Das Verzeichnis $env:USERPROFILE\tenable-nessus muss das Voraktivierungs-Bundle enthalten:

   $env:USERPROFILE\tenable-nessus
   ├── nessus-preact-gdch1.tar.gz             # GDCH Nessus Preactivation File
   

33.4. WSL öffnen

Für die verbleibenden Schritte auf der Seite ist WSL für alle Befehle erforderlich, sofern nicht anders angegeben.

1. Optional: Sudo ist erforderlich. Wenn Sie das Passwort des Sudo-Nutzers nicht kennen, führen Sie den folgenden Befehl aus, um das Passwort des WSL-Sudo-Nutzers oc-it festzulegen:

   /mnt/c/Windows/System32/wsl.exe --distribution "${WSL_DISTRO_NAME}" --user root --exec passwd oc-it
   

33.5. Umgebungsvariablen festlegen

Führen Sie die folgenden Schritte aus, um die erforderlichen Umgebungsvariablen festzulegen:

1. Definieren Sie die Umgebungsvariable ROOT_ADMIN_CLUSTER_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Administratorclusters sein, die als Voraussetzung generiert wurde:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Definieren Sie einen Alias für den ausgewählten kubectl-Befehl für den Administratorcluster im aktuellen Terminal:

   alias kra='kubectl --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}'
   

3. Legen Sie die Variable USERPROFILE fest.

   export USERPROFILE=$(wslpath $(cmd.exe /c "<nul set /p=%UserProfile%" 2>/dev/null))
   

   $USERPROFILE verweist jetzt auf denselben Ort wie $env:USERPROFILE.

33.5.1. Umgebungsvariablen für die V1-Organisation festlegen

1. Definieren Sie die Umgebungsvariable ORG_ADMIN_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des ausgewählten Administratorclusters der Organisation sein, die als Voraussetzung generiert wurde:

   ORG_ADMIN_KUBECONFIG=
   

2. Definieren Sie einen Alias für den ausgewählten kubectl-Befehl für den Administratorcluster der Organisation im aktuellen Terminal:

   alias kna='kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}'
   

3. Definieren Sie die Umgebungsvariable ORG_SYSTEM_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des ausgewählten Systemclusters sein, die als Voraussetzung generiert wurde:

   ORG_SYSTEM_KUBECONFIG=
   

4. Definieren Sie im aktuellen Terminal einen Alias für den ausgewählten kubectl-Befehl für den Systemcluster:

   alias knu='kubectl --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}'
   

33.5.2. Umgebungsvariablen für die V2-Organisation festlegen

1. Definieren Sie die Umgebungsvariable ORG_MGMT_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Management-Plane-API-Servers der ausgewählten V2-Organisation sein, die als Voraussetzung generiert wurde:

   ORG_MGMT_KUBECONFIG=
   

2. Definieren Sie einen Alias für den ausgewählten kubectl-Befehl für den Administratorcluster der Organisation im aktuellen Terminal:

   alias kna='kubectl --kubeconfig ${ORG_MGMT_KUBECONFIG:?}'
   

3. Definieren Sie die Umgebungsvariable ORG_INFRA_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur Kubeconfig des API-Servers der Steuerungsebene der ausgewählten Organisation der Version 2 sein, die als Voraussetzung generiert wurde:

   ORG_INFRA_KUBECONFIG=
   

4. Definieren Sie im aktuellen Terminal einen Alias für den ausgewählten kubectl-Befehl für den Systemcluster:

   alias knu='kubectl --kubeconfig ${ORG_INFRA_KUBECONFIG:?}'
   

33.6. Voraktivierungs-Bundle hochladen

Wichtig: Dieser Schritt ist für Upgrades nicht erforderlich.

Führen Sie die folgenden Schritte aus, um das Artefakt in die Harbor-Registry hochzuladen.

1. Konvertieren Sie das Bundle mit den entsprechenden Metadaten in das OCI-Format:

   BUNDLE_PATH=${USERPROFILE:?}/tenable-nessus/nessus-preact-gdch1.tar.gz
   BUNDLE_OCI_PATH=${USERPROFILE:?}/tenable-nessus/nessus-preact-gdch1-oci
   BUNDLE_TAG=$(date '+%Y%m%d%H%M%S')
   gdcloud artifacts oci build-from-tar ${BUNDLE_PATH:?} ${BUNDLE_OCI_PATH:?} \
       --version "${BUNDLE_TAG:?}" \
       --index-annotations "org.google.gpc.harbor.tag=${BUNDLE_TAG:?},com.gpc.oci.image.flat=true" \
       --manifest-annotations "org.google.gpc.harbor.project=gpc-system-nessus-updates,org.google.gpc.harbor.repo=nessus-preactivation,com.gpc.oci.image.flat=true" \
       --layer-media-type="application/vnd.unknown.layer.v1.tar"
   

2. Installieren Sie das Harbor-CA-Zertifikat:

   HARBOR_URL=$(kra get harborcluster harbor -n harbor-system -o=jsonpath='{.spec.externalURL}')
   
   HARBOR_IP=${HARBOR_URL#https://}
   
   sudo mkdir -p /etc/docker/certs.d/${HARBOR_IP:?}
   CA_CRT=$(kra get secret trust-store-internal-only -n anthos-creds -o jsonpath='{.data.ca\.crt}')
   
   sudo sh -c "echo ${CA_CRT} | openssl base64 -A -d > /etc/docker/certs.d/${HARBOR_IP:?}/ca.crt"
   

   So finden Sie das Betriebssystem:

   sudo sh -c "hostnamectl"
   

   Führen Sie für Rocky Linux als Betriebssystem Folgendes aus:

   sudo update-ca-trust extract
   

   Wenn Sie Ubuntu als Betriebssystem verwenden, führen Sie Folgendes aus:

   sudo update-ca-certificates
   

3. Laden Sie das Voraktivierungs-Bundle in Harbor hoch:

   • Ideale Methode: Authentifizierung mit gdcloud auth login.

     INFRA_CONSOLE_URL="https://$(kra get dnsregistrations.network.private.gdc.goog -n gpc-system infra-console -o jsonpath='{.status.fqdn}')"
     
     gdcloud config set core/organization_console_url ${INFRA_CONSOLE_URL:?}
     gdcloud auth login
     gdcloud auth configure-docker
     
     gdcloud system container-registry load-oci ${BUNDLE_OCI_PATH:?} --create-release-metadata=false --skip-failover-registry
     

   • Sicherungsmethode: kubeconfig.

     gdcloud system container-registry load-oci ${BUNDLE_OCI_PATH:?} --create-release-metadata=false --use-ip-port=true  --skip-failover-registry --kubeconfig=${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}
     

33.7. Nessus installieren

Warnung :Bei Upgrades von Versionen vor 1.14 müssen Sie vor der Installation den Abschnitt „Optional: Deinstallieren“ befolgen.

1. Installation von Nessus auslösen:

   cat <<EOF | kra apply -f -
   apiVersion: vulnerabilitymanagement.private.gdc.goog/v1alpha1
   kind: ParentNessusManagerConfig
   metadata:
       name: parent-nessus-manager-config
       namespace: tenable-nessus-system
   spec:
       preactivationUrlBundleTag: "${BUNDLE_TAG:?}"
       installedAt: "$(date -u +"%Y-%m-%dT%H:%M:%SZ")"
   EOF
   

2. Warten Sie etwa 1,5 Stunden, bis die Installation abgeschlossen ist.

33.7.1. Optional: Nessus deinstallieren

Dieser Abschnitt enthält die Befehle zum Entfernen der Nessus-Bereitstellung aus allen erforderlichen Clustern.

Warnung: Deinstallieren Sie Ihre vorhandene Nessus-Bereitstellung nur, wenn Sie eine Neuinstallation oder ein Upgrade durchführen. Überspringen Sie andernfalls diesen Abschnitt.

1. Nessus aus dem Root-Administratorcluster deinstallieren:

   helm list -n tenable-nessus-system -q --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}
   

2. Für die Organisationsarchitektur V1:

   1. Nessus aus dem Administratorcluster der Organisation deinstallieren:

      helm list -n tenable-nessus-system -q --kubeconfig ${ORG_ADMIN_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}
      

   2. Deinstallieren Sie Nessus aus dem Organisationssystem-Cluster:

      helm list -n tenable-nessus-system -q --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}
      

3. Für die Organisationsarchitektur V2:

   1. Deinstallieren Sie Nessus aus dem Organisationsverwaltungscluster:

      helm list -n tenable-nessus-system -q --kubeconfig ${ORG_MGMT_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
      

   2. Deinstallieren Sie Nessus aus dem Infrastrukturcluster der Organisation:

      helm list -n tenable-nessus-system -q --kubeconfig ${ORG_INFRA_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_INFRA_KUBECONFIG:?}
      

33.7.2. Nessus im Root-Administratorcluster überprüfen

1. Prüfen Sie, ob Schlüssel und Zertifikate veröffentlicht wurden:

   echo "Child linking key published: $(kra get pnm -A -o yaml | yq e '.items[0].status.conditions[] | select(.type == "ChildLinkingKeyPublished") | .status')"
   
   echo "Agent linking key published: $(kra get pnm -A -o yaml | yq e '.items[0].status.conditions[] | select(.type == "AgentLinkingKeyPublished") | .status')"
   
   echo "Nessus TLS Crt published: $(kra get pnm -A -o yaml | yq e '.items[0].status.conditions[] | select(.type == "NessusTlsCrtPublished") | .status')"
   

2. Prüfen Sie, ob sich der übergeordnete Nessus Manager in einem fehlerfreien Zustand befindet:

   POD_NAME=$(kra get pod -n tenable-nessus-system | grep vuln-parent-nessus-backend-app | awk '{print $1}')
   
   if kra exec -n tenable-nessus-system -c manager ${POD_NAME:?} -- /bin/bash -c "/opt/nessus/sbin/nessuscli node status" | grep -Fq "Agents linked"; then
       echo "Manager node is healthy"
   else
       echo "Manager node is unhealthy"
   fi
   

3. Wenn der übergeordnete Nessus Manager als fehlerhaft gemeldet wird, z. B. wenn die Ausgabe eines der vorherigen Befehle „false“ ist, starten Sie den übergeordneten Nessus Manager mit den folgenden Befehlen neu:

   kra rollout restart deployment vuln-parent-nessus-backend-app -n tenable-nessus-system
   

4. Warten Sie etwa 1,5 Stunden und prüfen Sie den Status dann noch einmal.

5. Wenn der übergeordnete Nessus Manager nach 1,5 Stunden immer noch als fehlerhaft gemeldet wird, eskalieren Sie das Problem an den Bereitschaftsdienst.

   1. Geben Sie nach dem Ausführen der angegebenen Abfrage über die Grafana-Benutzeroberfläche die folgenden Informationen an:

      {pod="<pod_name>"}
      

   2. Fügen Sie die übergeordnete Nessus Manager-Konfiguration ein:

      kra get pnm -A -o yaml
      

6. Prüfen Sie, ob der untergeordnete Nessus Manager fehlerfrei ist:

   POD_NAME=$(kra get pod -n tenable-nessus-system | grep vuln-managed-nessus-backend-app | awk '{print $1}')
   
   if kra exec -n tenable-nessus-system -c manager ${POD_NAME:?} -- /bin/bash -c "/opt/nessus/sbin/nessuscli node status" | grep -Fq "Agents linked"; then
       echo "Manager node is healthy"
   else
       echo "Manager node is unhealthy"
   fi
   

7. Wenn der untergeordnete Nessus Manager als fehlerhaft gemeldet wird, starten Sie ihn mit den folgenden Befehlen neu, warten Sie 20 Minuten und prüfen Sie den Status dann noch einmal:

   kra rollout restart deployment vuln-managed-nessus-backend-app -n tenable-nessus-system
   

8. Wenn der untergeordnete Nessus-Manager nach 20 Minuten immer noch als fehlerhaft gemeldet wird, eskalieren Sie das Problem und fügen Sie die folgenden Informationen hinzu, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

   1. Geben Sie nach dem Ausführen der angegebenen Abfrage über die Grafana-Benutzeroberfläche die folgenden Informationen an:

      {pod="<pod_name>"}
      

   2. Fügen Sie die Konfiguration des untergeordneten Nessus Manager ein:

      kra get cnm -A -o yaml
      

9. Prüfen Sie, ob es fehlerhafte Agents gibt:

   echo "Nodes with unhealthy agents:"\
   $(kra get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')
   

10. Legen Sie für alle in der Liste „Nicht fehlerfrei“ aufgeführten Agents die Variable NESSUS_AGENT_NAME fest und führen Sie den folgenden Befehl für alle aus:

    NESSUS_AGENT_NAME=
    kra delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system
    

11. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, gehen Sie für jeden Agent so vor:

    • Prüfen Sie die Logs des Pods install-<node_name> in Grafana. Wenn es ein Fehlerlog ansible-playbook error: one or more host failed gibt, stellen Sie mit PLATAUTH-G0001 eine SSH-Verbindung zum Bare-Metal-Knoten her.

    • Nachdem Sie eine SSH-Verbindung zum Bare-Metal-Knoten hergestellt haben, verschieben Sie /etc/yum.repos.d nach /etc/ yum.repos.d.back, um die yum-Repos-Konfiguration effektiv zu löschen.

12. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, eskalieren Sie das Problem und fügen Sie die folgenden Informationen hinzu, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

    1. Geben Sie die folgenden Informationen an, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

       {pod="<pod_name>"}
       

    2. Nessus-Agent-Status einbeziehen:

       kra get nessusagent/${NESSUS_AGENT_NAME} -n tenable-nessus-system -o yaml
       

    3. Nessus-Agent-Konfiguration einfügen:

       kra get nessusagentconfig/nessus-agent-config -n tenable-nessus-system -o yaml
       

33.8. Nessus Manager – Überprüfung der Organisation

In diesem Abschnitt werden die Schritte beschrieben, die zum Überprüfen von Nessus in einer Distributed Cloud-Organisation erforderlich sind.

Damit die Nessus-Überprüfung erfolgreich und vollständig durchgeführt werden kann, müssen Sie diesen Vorgang für jeden Organisationscluster von Distributed Cloud ausführen, einschließlich des IT-Organisationsclusters des Operations Center.

Verfügbare Organisationen auflisten:

kra get -n gpc-system organization

Führen Sie die folgenden Schritte für jede Organisation aus, mit Ausnahme der Organisation root, die bereits behandelt wurde.

33.8.1. Vorbereitung

• Für V1-Organisationen erforderlicher Zugriff

  • Folgen Sie IAM-R0005:
    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-root im Stammadministratorcluster ab.

  • Folgen Sie IAM-R0004:

    • Generieren Sie die KUBECONFIG für den Root-Administratorcluster.

  • Folgen Sie IAM-R0005:

    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-org-legacy im Admincluster der Zielorganisation ab.

  • Folgen Sie IAM-R0004:

    • Generieren Sie die KUBECONFIG für den Administratorcluster der Zielorganisation.

  • Folgen Sie IAM-R0005:

    • Weisen Sie sich die clusterrole/tenable-nessus-admin-system-legacy-Clusterrolle im Zielsystemcluster zu.

  • Folgen Sie IAM-R0004:

    • Generieren Sie die KUBECONFIG für den Zielsystemcluster.

• Für V2-Organisationen erforderlicher Zugriff

  • Folgen Sie IAM-R0005:
    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-root im Stammadministratorcluster ab.
  • Folgen Sie IAM-R0004:
    • Generieren Sie die KUBECONFIG für den Root-Administratorcluster.
  • Folgen Sie IAM-R0005:
    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-infra-mp im Zielcluster ab.
  • Folgen Sie IAM-R0004:
    • Generieren Sie die mp KUBECONFIG für den Zielinfrastrukturcluster.
  • Folgen Sie IAM-R0005:
    • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-infra-cp im Kube API-Server der Zielinfrastruktur-Steuerungsebene ab.
  • Folgen Sie IAM-R0004:
    • Generieren Sie die cp KUBECONFIG für den Infrastrukturcluster.

Folgen Sie der Anleitung unter Umgebungsvariablen festlegen, um den Zugriff auf die Organisationscluster einzurichten und die Befehlszeilenaliase kna und knu zu definieren.

33.8.2. Nessus im Administratorcluster der Organisation in V1-Organisationen und kube-API-Server der Infrastrukturverwaltungsebene in V2-Organisationen prüfen

1. Prüfen Sie, ob es fehlerhafte Agents gibt:

   echo "Nodes with unhealthy agents:"\
   $(kna get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')
   

2. Legen Sie für alle in der Liste „Nicht fehlerfrei“ aufgeführten Agents die Variable NESSUS_AGENT_NAME fest und führen Sie den folgenden Befehl für alle aus:

   NESSUS_AGENT_NAME=
   kna delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system
   

3. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, gehen Sie für jeden Agent so vor:

   • Prüfen Sie die Logs des Pods install-<node_name> in Grafana. Wenn es ein Fehlerlog ansible-playbook error: one or more host failed gibt, stellen Sie mit PLATAUTH-G0001 eine SSH-Verbindung zum Bare-Metal-Knoten her.

   • Nachdem Sie eine SSH-Verbindung zum Bare-Metal-Knoten hergestellt haben, verschieben Sie /etc/yum.repos.d nach /etc/ yum.repos.d.back, um die yum-Repos-Konfiguration effektiv zu löschen.

4. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, eskalieren Sie das Problem und fügen Sie die folgenden Informationen hinzu, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

   {pod="<pod_name>"}
   

33.8.3. Nessus im Systemcluster in Organisationen der Version 1 und den Kube-API-Server der Infrastruktursteuerungsebene in Organisationen der Version 2 prüfen

1. Prüfen Sie, ob der untergeordnete Nessus Manager fehlerfrei ist:

   POD_NAME=$(knu get pod -n tenable-nessus-system | grep vuln-managed-nessus-backend-app | awk '{print $1}')
   
   if knu exec -n tenable-nessus-system -c manager ${POD_NAME:?} -- /bin/bash -c "/opt/nessus/sbin/nessuscli node status" | grep -Fq "Agents linked"; then
       echo "Manager node is healthy"
   else
       echo "Manager node is unhealthy"
   fi
   

2. Wenn der untergeordnete Nessus Manager als fehlerhaft gemeldet wird, starten Sie ihn mit den folgenden Befehlen neu, warten Sie 20 Minuten und prüfen Sie den Status dann noch einmal:

   knu rollout restart deployment vuln-managed-nessus-backend-app -n tenable-nessus-system
   

3. Wenn der untergeordnete Nessus-Manager nach 20 Minuten immer noch als fehlerhaft gemeldet wird, eskalieren Sie das Problem und fügen Sie die folgenden Informationen hinzu, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

   1. Geben Sie die folgenden Informationen an, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

      {pod="<pod_name>"}
      

   2. Fügen Sie die untergeordnete Nessus Manager-Konfiguration ein.

      knu get cnm -A -o yaml
      

4. Prüfen Sie, ob es fehlerhafte Agents gibt:

   echo "Nodes with unhealthy agents:"\
   $(knu get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')
   

5. Legen Sie für alle in der Liste „Nicht fehlerfrei“ aufgeführten Agents die Variable NESSUS_AGENT_NAME fest und führen Sie den folgenden Befehl für alle aus:

   NESSUS_AGENT_NAME=
   knu delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system
   

6. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, gehen Sie für jeden Agent so vor:

   • Prüfen Sie die Logs des Pods install-<node_name> in Grafana. Wenn es ein Fehlerlog ansible-playbook error: one or more host failed gibt, stellen Sie mit PLATAUTH-G0001 eine SSH-Verbindung zum Bare-Metal-Knoten her.

   • Nachdem Sie eine SSH-Verbindung zum Bare-Metal-Knoten hergestellt haben, verschieben Sie /etc/yum.repos.d nach /etc/ yum.repos.d.back, um die yum-Repos-Konfiguration effektiv zu löschen.

7. Wenn die fehlerhaften Agents nach 20 Minuten immer noch in der Liste aufgeführt sind, eskalieren Sie das Problem und fügen Sie die folgenden Informationen hinzu, nachdem Sie die angegebene Abfrage über die Grafana-Benutzeroberfläche ausgeführt haben.

   1. Geben Sie nach dem Ausführen der angegebenen Abfrage über die Grafana-Benutzeroberfläche die folgenden Informationen an:

      {pod="<pod_name>"}
      

   2. Nessus-Agent-Status einbeziehen:

      knu get nessusagent/${NESSUS_AGENT_NAME} -n tenable-nessus-system -o yaml
      

   3. Nessus-Agent-Konfiguration einfügen:

      knu get nessusagentconfig/nessus-agent-config -n tenable-nessus-system -o yaml
      

33.9. Tenable.sc installieren

Dieser Abschnitt enthält Schritte zum Installieren oder Aktualisieren einer vorhandenen VM von Tenable.sc in der IT-Organisation des Operations Center.

33.9.1. Vorbereitung

• Zugriff erforderlich

  • Für die Organisationsarchitektur V1:
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-root im Stammadministratorcluster ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Root-Administratorcluster.
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-org-legacy im Admincluster „gdchservices“ ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Administratorcluster „gdchservices“.
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-system-legacy im Systemcluster „gdchservices“ ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Systemcluster „gdchservices“.
  • Für die Organisationsarchitektur V2:
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-root im Stammadministratorcluster ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Root-Administratorcluster.
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-infra-mp im Cluster „gdchservices-management“ ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Cluster „gdchservices-management“.
    • Folgen Sie IAM-R0005:
      • Rufen Sie die Clusterrolle clusterrole/tenable-nessus-admin-infra-cp im Cluster „gdchservices-infra“ ab.
    • Folgen Sie IAM-R0004:
      • Generieren Sie die KUBECONFIG für den Cluster „gdchservices-infra“.

33.9.2. Umgebungsvariablen festlegen

Führen Sie die folgenden Schritte aus, um die erforderlichen Umgebungsvariablen festzulegen:

1. Definieren Sie die Umgebungsvariable ROOT_ADMIN_CLUSTER_KUBECONFIG für die spätere Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Administratorclusters sein, die als Voraussetzung generiert wurde:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Definieren Sie einen Alias für den kubectl-Befehl des Root-Administratorclusters im aktuellen Terminal:

   alias kra='kubectl --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}'
   

3. Definieren Sie die Umgebungsvariable für die kubeconfig der Verwaltungsebene der gdchservices-Organisation:

   • Für Organisationsarchitektur V1:Definieren Sie die Umgebungsvariable ORG_ADMIN_KUBECONFIG zur späteren Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Administratorclusters für gdchservices sein, die als Voraussetzung generiert wurde:

     ORG_ADMIN_KUBECONFIG=
     

   • Für Organisationsarchitektur V2:Definieren Sie die Umgebungsvariable ORG_MGMT_KUBECONFIG zur späteren Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Managementclusters für gdchservices sein, die als Voraussetzung generiert wurde:

     ORG_MGMT_KUBECONFIG=
     

4. Erstellen Sie einen Alias für den kubectl-Befehl mit der oben genannten kubeconfig:

   • Für Organisationsarchitektur v1:Definieren Sie einen Alias für den kubectl-Befehl des gdchservices-Administratorclusters im aktuellen Terminal:

     alias kna='kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}'
     

   • Für Organisationsarchitektur V2:Definieren Sie einen Alias für den kubectl-Befehl des gdchservices-Administratorclusters im aktuellen Terminal:

     alias kna='kubectl --kubeconfig ${ORG_MGMT_KUBECONFIG:?}'
     

5. Definieren Sie die Umgebungsvariable für die kubeconfig-Datei der Steuerungsebene der gdchservices-Organisation:

   • Für Organisationsarchitektur V1:Definieren Sie die Umgebungsvariable ORG_SYSTEM_KUBECONFIG zur späteren Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des Systemclusters „gdchservices“ sein, die als Voraussetzung generiert wurde:

     ORG_SYSTEM_KUBECONFIG=
     

   • Für Organisationsarchitektur V2:Definieren Sie die Umgebungsvariable ORG_INFRA_KUBECONFIG zur späteren Verwendung im aktuellen Terminal. Dies muss ein absoluter Pfad zur kubeconfig des GDCHServices-Infrastrukturclusters sein, die als Voraussetzung generiert wurde:

     ORG_INFRA_KUBECONFIG=
     

6. Erstellen Sie einen Alias für den kubectl-Befehl mit der oben genannten kubeconfig:

   • Für Organisationsarchitektur V1:Definieren Sie einen Alias für den kubectl-Befehl des Systemclusters „gdchservices“ im aktuellen Terminal:

     alias knu='kubectl --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}'
     

   • Für Organisationsarchitektur V2:Definieren Sie im aktuellen Terminal einen Alias für den kubectl-Befehl des gdchservices-Infrastrukturclusters:

     alias knu='kubectl --kubeconfig ${ORG_INFRA_KUBECONFIG:?}'
     

7. Legen Sie die Variable USERPROFILE fest.

   export USERPROFILE=$(wslpath $(cmd.exe /c "<nul set /p=%UserProfile%" 2>/dev/null))
   

   $USERPROFILE verweist jetzt auf denselben Ort wie $env:USERPROFILE.

8. Definieren Sie den Namen der Organisation, in der Tenablesc bereitgestellt wird:

   ORG=gdchservices
   

33.9.3. Installation vorbereiten

Führen Sie die folgenden Schritte aus, um die Organisation vorzubereiten.

1. Erstellen Sie das tenablesc-system-Projekt.

   cat <<EOF | kna apply -n gpc-system -f -
   apiVersion: resourcemanager.gdc.goog/v1
   kind: Project
   metadata:
     name: tenablesc-system
     labels:
       istio.io/rev: default
       networking.gdc.goog/enable-default-egress-allow-to-outside-the-org: "true"
       resourcemanager.gdc.goog/attach-all-user-clusters: "true"
   EOF
   

2. Prüfen Sie nach zwei Minuten, ob Namespaces sowohl im Organisationsadministrator- als auch im Systemcluster vorhanden sind.

   kna get namespace tenablesc-system -o yaml
   
   knu get namespace tenablesc-system -o yaml
   

   Das Projektlabel resourcemanager.gdc.goog/attach-all-user-clusters: "true" bewirkt, dass der Namespace auch in allen Nutzerclustern der Organisation erstellt wird.

3. Generieren Sie die Anmeldedaten für den Tenablesc-Administrator und den Manager und speichern Sie sie als Kubernetes-Secret.

   cat <<EOF | knu apply -n tenablesc-system  -f -
   apiVersion: v1
   kind: Secret
   type: Opaque
   metadata:
       name: users
   data:
       adminpw: $(</dev/urandom tr -dc 'A-Za-z0-9~!@#$%^*+?' | head -c 25 | base64)
       managerpw: $(</dev/urandom tr -dc 'A-Za-z0-9~!@#$%^*+?' | head -c 25 | base64)
   EOF
   

33.9.4. Admin-Diagramm installieren

1. Legen Sie die folgenden Umgebungsvariablen fest, um die Installation vorzubereiten:

   URL_SUFFIX=$(kna get configmap dnssuffix -n gpc-system -o jsonpath='{.data.dnsSuffix}')
   
   ROOT_URL_SUFFIX=$(kra get configmap dnssuffix -n gpc-system -o jsonpath='{.data.dnsSuffix}')
   
   DEPLOY_NAME=tenablesc
   

2. Wenden Sie das Admin-Helm-Diagramm an.

   • Für die Organisationsarchitektur V1:

     helm upgrade --install \
       tenablesc-admin ${USERPROFILE:?}/tenable-nessus/tenablesc-admin.tgz \
       --namespace tenablesc-system \
       --set urlSuffix=${URL_SUFFIX:?} \
       --set deployName=${DEPLOY_NAME:?} \
       --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}
     

   • Für die Organisationsarchitektur V2:

     Legen Sie OCIT_NESSUS_MANAGER_PREFIXES als durch Kommas getrennte Liste fest, z. B. "{dc1-nessus1,dc1-nessus2}", um das OCIT-VM-Präfix anzugeben.

     Legen Sie OCIT_NESSUS_URL_SUFFIX fest, um das OCIT-VM-Suffix anzugeben.

     Helm-Updates für die Verwaltungsebene anwenden:

     helm upgrade --install \
       tenablesc-admin ${USERPROFILE:?}/tenable-nessus/tenablesc-infra-mp.tgz \
       --namespace tenablesc-system \
       --set urlSuffix=${URL_SUFFIX:?} \
       --set ocitNessusManagerPrefixes=${OCIT_NESSUS_MANAGER_PREFIXES:?} \
       --set deployName=${DEPLOY_NAME:?} \
       --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
     

     Helm-Updates für die Infrastrukturebene anwenden:

     helm upgrade --install \
       tenablesc-admin ${USERPROFILE:?}/tenable-nessus/tenablesc-infra-cp.tgz \
       --namespace tenablesc-system \
       --set urlSuffix=${URL_SUFFIX:?} \
       --set rootUrlSuffix=${ROOT_URL_SUFFIX:?} \
       --set ocitUrlSuffix=${OCIT_NESSUS_URL_SUFFIX:?} \
       --set ocitNessusManagerPrefixes=${OCIT_NESSUS_MANAGER_PREFIXES:?} \
       --set deployName=${DEPLOY_NAME:?} \
       --kubeconfig ${ORG_INFRA_KUBECONFIG:?}
     

     Wenden Sie die Istio-Autorisierungsrichtlinie an:

     cat <<EOF | knu apply -f -
     apiVersion: security.istio.io/v1
     kind: AuthorizationPolicy
     metadata:
       name: allow-nessus-terminated-traffic
       namespace: istio-system
     spec:
       rules:
       - from:
         - source:
             ipBlocks:
             - 0.0.0.0/0
         to:
         - operation:
             hosts:
             - nessus-terminated.${URL_SUFFIX:?}
       selector:
         matchLabels:
           istio: management-ingress-gateway
     EOF
     

     Diensteintrag erstellen:

     cat <<EOF | knu apply -f -
     apiVersion: networking.istio.io/v1beta1
     kind: ServiceEntry
     metadata:
       name: nessus-svc-entry
       namespace: istio-system
     spec:
       hosts:
       - nessus.${ROOT_URL_SUFFIX:?}
       location: MESH_EXTERNAL
       ports:
       - name: https-port
         number: 443
         protocol: TLS
       resolution: DNS
     EOF
     

     DNS-Registrierung erstellen:

     cat <<EOF | kna apply -n tenablesc-system -f -
     apiVersion: network.private.gdc.goog/v1alpha1
     kind: DNSRegistration
     metadata:
       name: tenablesc-internal
       namespace: tenablesc-system
     spec:
       resolutionConfig:
         exposeToNetwork: VPC
         resolveTo:
           useDefaultIstioGateway:
             owningCluster: InfraCluster
             ingressLabel: infra
         vpcIdentifier: infra
     EOF
     

     Speichern Sie den FQDN nach fünf Minuten Wartezeit in einer Umgebungsvariablen:

     TENABLE_SC_INTERNAL_FQDN=$(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc-internal -o jsonpath='{.status.fqdn}')
     

     Patchen Sie den virtuellen Dienst und das Gateway, um den internen FQDN von Tenable SC hinzuzufügen:

     knu patch gateway tenablesc-gateway -n istio-system --type='json' \
     -p='[{"op": "add", "path": "/spec/servers/0/hosts/0", "value": "'"${TENABLE_SC_INTERNAL_FQDN:?}"'"}]'
     

     knu patch virtualservice tenablesc-https-ingress-virtualsvc -n tenablesc-system --type='json' \
     -p='[{"op": "add", "path": "/spec/hosts/0", "value": "'"${TENABLE_SC_INTERNAL_FQDN:?}"'"}]'
     

     Patchen Sie die Prober-Ressource, um den richtigen Endpunkt zu testen:

     kna patch probe tenablesc-probe -n tenablesc-system --type='json' \
     -p='[{"op": "replace", "path": "/spec/probeJobs/0/targets/0", "value": "https://'"${TENABLE_SC_INTERNAL_FQDN:?}"'"}]'
     

3. Bereitstellung prüfen

   Prüfen Sie die Ausgabe des folgenden Befehls, um zu bestätigen, dass die tenablesc-admin-Bereitstellung erfolgreich war:

   • Für die Organisationsarchitektur V1:

     helm ls --namespace tenablesc-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}
     

   • Für die Organisationsarchitektur V2:

     helm ls --namespace tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
     

4. Prüfen Sie, ob der virtuelle Dienst vorhanden ist.

   • Für die Organisationsarchitektur V1:

     kna get virtualservice -n tenablesc-system
     

   • Für die Organisationsarchitektur V2:

     knu get virtualservice -n tenablesc-system
     

5. Prüfen Sie, ob der DNS-Eintrag vorhanden ist.

   echo $(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc -o jsonpath='{.status.fqdn}')
   

6. Prüfen Sie, ob AuditLoggingTarget bereit ist. Das kann einige Minuten dauern.

   kna get auditloggingtarget/tenablesc-audit-logging-target -n tenablesc-system -o jsonpath='{ .status }' |  jq
   

   • Möglicherweise tritt der folgende Fehler auf:

     Error: failed to copy secret to project: namespace "tenablesc-system" not found in cluster <user_cluster>

     Wenn ja, muss der Namespace tenablesc-system im angegebenen Cluster erstellt werden. Erstellen Sie den Namespace, um fortzufahren, und öffnen Sie dann einen Meta-Fehler, um eine Untersuchung der Ursache dieses Fehlers zu veranlassen. Fügen Sie die Ausgabe von tenablesc-system Project describe in das Ticket ein.

     kna describe project tenablesc-system
     

   • Möglicherweise tritt der folgende Fehler auf:

     Error from server (NotFound): auditloggingtargets.logging.private.gdc.goog "tenablesc-audit-logging-target" not found

     Erstellen Sie in diesem Fall die fehlende AuditLoggingTarget manuell:

     cat <<EOF | kna apply -n tenablesc-system -f -
     apiVersion: logging.private.gdc.goog/v1alpha1
     kind: AuditLoggingTarget
     metadata:
         name: "${DEPLOY_NAME:?}-audit-logging-target"
     spec:
         appNameLabel: "${DEPLOY_NAME:?}"
         hostNameLabel: host
         ingressGatewayPort: 0
         logAccessLevel: io
         serviceName: "${DEPLOY_NAME:?}"
         timestampKey: time
         timestampkeyFormat: '%Y-%m-%dT%H:%M:%S'
     EOF
     

     Nach fünf Minuten sollte die Ausgabe in etwa so aussehen:

     {
         "certSecretName": "tenablesc-alog-client-tls",
         "conditions": [
             {
                 "lastTransitionTime": "2023-07-11T15:13:50Z",
                 "message": "",
                 "observedGeneration": 1,
                 "reason": "ReconciliationCompleted",
                 "status": "True",
                 "type": "Ready"
             }
         ],
         "serverCertSecretName": "tenablesc-alog-server-tls",
         "syslogServerName": "tenablesc-alog-system.gdchservices.bert.sesame.street",
         "syslogServerPortNumber": 5140
     }
     

     Wenn die Statusausgabe nach 10 Minuten immer noch falsch aussieht, ist die Observability-Plattform möglicherweise fehlerhaft. Öffnen Sie einen Meta-Fehler mit den verfügbaren Statusinformationen, um die Fehlerbehebung zu unterstützen.

33.9.5. Diagramm „Installierte VMs“

1. Legen Sie die folgenden Umgebungsvariablen fest, um die Installation vorzubereiten:

   TENABLESC_IMAGE_URL=$(kna get virtualmachineimages.virtualmachine.gdc.goog -n vm-system -o custom-columns=NAME:.metadata.name | grep nessus-tenable-sc | sort -r -k 1 | head -1)
   TENABLESC_BOOT_SIZE=50G
   

   • Für die Organisationsarchitektur V1:

     ALT_NAME=tenablesc-audit-logging-target
     
     ALT_NS=tenablesc-system
     
     ALT_HOSTNAME=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.syslogServerName }')
     
     ALT_PORT=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.syslogServerPortNumber }')
     
     ALT_CERT_SECRET=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.certSecretName }')
     
     ALT_CACERT=$(kna get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.ca\.crt }')
     
     ALT_CERTFILE=$(kna get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.tls\.crt }')
     
     ALT_KEYFILE=$(kna get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.tls\.key }')
     

   • Für die Organisationsarchitektur V2:

     ALT_NAME=tenablesc-audit-logging-target
     
     ALT_NS=tenablesc-system
     
     ALT_HOSTNAME=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.syslogServerName }')
     
     ALT_PORT=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.syslogServerPortNumber }')
     
     ALT_CERT_SECRET=$(kna get auditloggingtarget/${ALT_NAME:?} -n ${ALT_NS:?} -o jsonpath='{ .status.certSecretName }')
     
     ALT_CACERT=$(knu get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.ca\.crt }')
     
     ALT_CERTFILE=$(knu get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.tls\.crt }')
     
     ALT_KEYFILE=$(knu get secret/${ALT_CERT_SECRET:?} -n ${ALT_NS:?} -o jsonpath='{ .data.tls\.key }')
     

2. Legen Sie den Typ der virtuellen Maschine fest:

   1. Namen aller VM-Typen abrufen:

      kna get virtualmachinetypes.virtualmachine.gdc.goog -n vm-system
      

   2. Wählen Sie den Typ der virtuellen Maschinen mit dem Feld Supported als true aus und speichern Sie ihn in einer Umgebungsvariable. Bevorzugt: n2-standard-4-gdc und n3-standard-4-gdc.

      VIRTUAL_MACHINE_TYPE=
      

3. Ein ProjectNetworkPolicy ist erforderlich, damit Tenable.sc-Logs an die infra-obs-Loki-Instanz gesendet werden.

   cat <<EOF | kna apply -f -
   apiVersion: networking.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     name: allow-tenablesc-system-ingress-traffic
     namespace: obs-system
   spec:
     ingress:
     - from:
       - projects:
           matchNames:
           - tenablesc-system
     policyType: Ingress
     subject:
       subjectType: UserWorkload
   EOF
   

4. Wenden Sie das Helm-Diagramm für VMs an.

   • Für die Organisationsarchitektur V1:

     helm upgrade --install \
       tenablesc-vms ${USERPROFILE:?}/tenable-nessus/tenablesc-vms.tgz \
       --namespace tenablesc-system  \
       --set urlSuffix=${URL_SUFFIX:?} \
       --set applicationServer.image=${TENABLESC_IMAGE_URL:?} \
       --set applicationServer.bootSize=${TENABLESC_BOOT_SIZE:?} \
       --set applicationServer.virtualMachineType=${VIRTUAL_MACHINE_TYPE:?} \
       --set syslogaudit.host=${ALT_HOSTNAME:?} \
       --set syslogaudit.port=${ALT_PORT:?} \
       --set syslogaudit.caCert=${ALT_CACERT} \
       --set syslogaudit.certFile=${ALT_CERTFILE} \
       --set syslogaudit.keyFile=${ALT_KEYFILE} \
       --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}
     

   • Für die Organisationsarchitektur V2:

     helm upgrade --install \
       tenablesc-vms ${USERPROFILE:?}/tenable-nessus/tenablesc-vms.tgz \
       --namespace tenablesc-system  \
       --set urlSuffix=${URL_SUFFIX:?} \
       --set applicationServer.image=${TENABLESC_IMAGE_URL:?} \
       --set applicationServer.bootSize=${TENABLESC_BOOT_SIZE:?} \
       --set applicationServer.virtualMachineType=${VIRTUAL_MACHINE_TYPE:?} \
       --set syslogaudit.host=${ALT_HOSTNAME:?} \
       --set syslogaudit.port=${ALT_PORT:?} \
       --set syslogaudit.caCert=${ALT_CACERT} \
       --set syslogaudit.certFile=${ALT_CERTFILE} \
       --set syslogaudit.keyFile=${ALT_KEYFILE} \
       --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
     

   Beim Anwenden des Helm-Diagramms können die folgenden Probleme auftreten:

   • Webhook fehlgeschlagen: connect: connection refused

     Error: Internal error occurred: failed calling webhook "mvirtualmachines.vm.cluster.gke.io": failed to call webhook: Post "https://vm-manager-webhook.gpc-system.svc:443/mutate-vm-cluster-gke-io-v1alpha1-virtualmachine?timeout=10s": dial tcp 10.1.118.145:443: connect: connection refused
     

     Abhilfe: Führen Sie den Befehl „helm upgrade“ noch einmal aus.

5. Bereitstellung prüfen Prüfen Sie die Ausgabe des folgenden Befehls, um zu bestätigen, dass die tenablesc-vm-Bereitstellung erfolgreich war:

   helm ls --namespace tenablesc-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}
   

6. Warten Sie, bis Tenablesc ausgeführt wird.

   Prüfen Sie den Status der virtuellen Maschine:

   kna get virtualmachines.virtualmachine.gdc.goog -n tenablesc-system
   

   Beispielausgabe, die angibt, dass die VM noch bereitgestellt wird:

   NAME            STATUS    AGE
   tenablesc-as1   Pending   55s
   

   Beispielausgabe, die angibt, dass die VM ausgeführt wird:

   NAME            STATUS    AGE
   tenablesc-as1   Running   8m25s
   

   Wenn die VM nach 60 Minuten nicht ausgeführt wird, prüfen Sie die Namespace-Ereignisse auf auffällige Fehler.

   knu get -n tenablesc-system events -o wide
   

   Sammeln Sie alle wichtigen Warnungen und Fehler und melden Sie sie mit einem Metabug.

7. Für den Zugriff auf die Tenable.sc-Benutzeroberfläche sind ein VirtualService und ein DestinationRule erforderlich.

   • Für Organisationsarchitektur V1:Keine Änderung erforderlich.

   • Für die Organisationsarchitektur V2:

     • Legen Sie den Dienstnamen als Umgebungsvariable für die spätere Verwendung fest:

       TENABLE_SC_SERVICE=$(knu get service -n tenablesc-system | awk '($1 ~ /^g-svc-/) && ($0 ~ /443/) {print $1}'s)
       

     • Bearbeiten Sie die benutzerdefinierten Ressourcen VirtualService und DestinationRule:

       knu patch virtualservice tenablesc-https-ingress-virtualsvc -n tenablesc-system --type merge --patch '{"spec": {"http": [{"route": [{"destination": {"host":"'"${TENABLE_SC_SERVICE:?}"'.tenablesc-system.svc.cluster.local"}}]}]}}'
       knu patch destinationrule tls-encrypt-tenablesc-https-ingress -n tenablesc-system --type merge --patch '{"spec":{"host":"'"${TENABLE_SC_SERVICE:?}"'.tenablesc-system.svc.cluster.local"}}'
       

8. Prüfen Sie, ob DNS in eine IP-Adresse aufgelöst wird.

   TENABLE_SC_HOST=$(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc -o jsonpath='{.status.fqdn}')
   
   dig +noall +answer ${TENABLE_SC_HOST:?}
   

9. Prüfen Sie, ob der Dienst über DNS aufgelöst wird.

   Hinweis :Wenn Sie selbst bereitgestellte Installationsprogramme verwenden, überspringen Sie diesen Schritt.

   Das erwartete Ergebnis ist ein 200-Antwortcode und eine HTML-Ausgabe.

   curl -kv https://${TENABLE_SC_HOST:?}
   

33.9.6. SSH-Anmeldedaten für Tenable.sc-VM vorbereiten

Führen Sie die folgenden Schritte aus, um SSH für den Zugriff auf die Tenable-VM vorzubereiten.

1. Generieren Sie einen SSH-Schlüssel.

   Dieser SSH-Schlüssel wird nur vorübergehend für den Zugriff auf die VM verwendet.

   rm /tmp/tenablesc
   ssh-keygen -t rsa -b 4096 -f /tmp/tenablesc -N ""
   

2. Legen Sie die folgenden Umgebungsvariablen fest:

   export VM_PUBLIC_KEY=$(cat /tmp/tenablesc.pub)
   
   export VM_NAME=tenablesc-as1
   

3. Erstellen Sie ein temporäres VirtualMachineRequest (24 Stunden).

   Mit VirtualMachineRequest wird das generierte SSH-Zertifikat auf der VM installiert.

   kna delete VirtualMachineAccessRequest ${VM_NAME:?}-ar -n tenablesc-system --ignore-not-found=true
   cat <<EOF | kna apply -n tenablesc-system -f -
   apiVersion: virtualmachine.gdc.goog/v1
   kind: VirtualMachineAccessRequest
   metadata:
     name: ${VM_NAME:?}-ar
   spec:
     ssh:
       key: |
         ${VM_PUBLIC_KEY:?}
       ttl: 24h
     user: alice
     vm: ${VM_NAME:?}
   EOF
   

4. Exportieren Sie die SSH-IP-Adresse der VM als lokale Umgebungsvariable.

   INGRESS_IP=$(kna get vmexternalaccess tenablesc-as1 -n tenablesc-system -o jsonpath='{.status.ingressIP}')
   
   echo "VM SSH IP: ${INGRESS_IP:?}"
   

5. Testen Sie, ob die SSH-Verbindung funktioniert:

   ssh -i /tmp/tenablesc -o "StrictHostKeyChecking no" alice@${INGRESS_IP:?} whoami
   

   Die erwartete Ausgabe ist alice, der SSH-Nutzername.

   Wenn die SSH-Verbindung Zeit überschreitet, fehlt die Ingress-Richtlinie. Erstellen Sie die Ingress-Richtlinie mit dem folgenden Befehl und versuchen Sie es noch einmal.

6. Erstellen Sie die Richtlinie für eingehenden Traffic:

   kna create -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
       name: allow-external-traffic-vm
       namespace: tenablesc-system
   spec:
       ingress:
       - from:
           - ipBlock:
               cidr: 0.0.0.0/0
       policyType: Ingress
       subject:
           subjectType: UserWorkload
   EOF
   

7. Stellen Sie einen iotools-Pod im Namespace tenablesc-system bereit:

   cat << EOF | knu apply -n tenablesc-system -f -
   apiVersion: v1
   kind: Pod
   metadata:
     name: iotools
     namespace: tenablesc-system
   spec:
     containers:
     - name: iotools
       image: gcr.io/private-cloud-staging/operation-tools:latest
       command: ["sleep","infinity"]
       volumeMounts:
       - name: log-volume
         mountPath: /var/log
     volumes:
     - name: log-volume
       emptyDir: {}
   EOF
   

8. Übertragen Sie den privaten Schlüssel in den iotools-Pod:

9. Übertragen Sie den privaten Schlüssel in den iotools-Pod:

   knu -n tenablesc-system cp /tmp/tenablesc iotools:/tmp/tenablesc
   

33.9.7. Webdienstzertifikate installieren

Führen Sie die folgenden Schritte aus, um die Tenablesc-Webdienstzertifikate zu installieren.

1. Exportieren Sie die SSH-IP-Adresse der VM als lokale Umgebungsvariable:

   INGRESS_IP=$(knu get virtualmachine tenablesc-as1 -n tenablesc-system -o json | jq -r '.status.network.interfaces[0].ipAddresses[0] | split("/")[0]')
   
   echo "VM SSH IP: ${INGRESS_IP:?}"
   

2. Webserverzertifikate und ‑schlüssel vorbereiten

   Mit den folgenden Befehlen werden TLS-Zertifikate und -Schlüssel installiert, die zum Bereitstellen der Tenable-Benutzeroberfläche verwendet werden.

   1. TLS-Zertifikatsnamen festlegen

      TLS_SECRET_NAME=nessus-tls
      

   2. Speichern Sie das nessus-tls-Zertifikat lokal:

      knu get secret ${TLS_SECRET_NAME:?} -n tenable-nessus-system -o yaml > nessus-tls.yaml
      

   3. Kopieren Sie das Zertifikat nessus-tls in den Pod iotools:

      knu -n tenablesc-system cp nessus-tls.yaml iotools:/tmp/nessus-tls.yaml
      

   4. Stellen Sie das TLS-Zertifikat bereit.

      knu get -n tenable-nessus-system secret ${TLS_SECRET_NAME:?} -o jsonpath='{ .data.tls\.crt }' | base64 -d | knu -n tenablesc-system exec -i iotools -- /bin/bash -c "ssh -i /tmp/tenablesc -o \"StrictHostKeyChecking no\" \"alice@${INGRESS_IP}\" \"cat - > ~/SecurityCenter.crt\""
      

   5. Stellen Sie den privaten TLS-Schlüssel bereit.

      knu get -n tenable-nessus-system secret ${TLS_SECRET_NAME:?} -o jsonpath='{ .data.tls\.key }' | base64 -d | knu -n tenablesc-system exec -i iotools -- /bin/bash -c "ssh -i /tmp/tenablesc -o \"StrictHostKeyChecking no\" \"alice@${INGRESS_IP}\" \"cat - > ~/SecurityCenter.key\""
      

   6. Stellen Sie das TLS-Zertifizierungsstellenzertifikat bereit.

      knu get -n tenable-nessus-system secret ${TLS_SECRET_NAME:?} -o jsonpath='{ .data.ca\.crt }' | base64 -d | knu -n tenablesc-system exec -i iotools -- /bin/bash -c "ssh -i /tmp/tenablesc -o \"StrictHostKeyChecking no\" \"alice@${INGRESS_IP}\" \"cat - > ~/SecurityCenterCA.crt\""
      

3. Bereiten Sie das Skript für die Zertifikatsinstallation vor.

   Speichern Sie den folgenden Code in /tmp/tenable-sc-install-web-tls.sh.

   cat >> /tmp/tenable-sc-install-web-tls.sh << EOF
   #!/bin/bash
   # Install server cert
   sudo mv ~/SecurityCenter.crt /opt/sc/support/conf/SecurityCenter.crt
   sudo mv ~/SecurityCenter.key /opt/sc/support/conf/SecurityCenter.key
   sudo chown tns:tns /opt/sc/support/conf/SecurityCenter.crt
   sudo chown tns:tns /opt/sc/support/conf/SecurityCenter.key
   sudo chmod 640 /opt/sc/support/conf/SecurityCenter.crt
   sudo chmod 640 /opt/sc/support/conf/SecurityCenter.key
   
   # Install custom CA cert
   sudo /opt/sc/support/bin/php /opt/sc/src/tools/installCA.php ~/SecurityCenterCA.crt
   
   # append root ext ca to sys log ca
   cat ~/SecurityCenterCA.crt | sudo tee -a /etc/fluent-bit/syslog-ca.crt
   
   # Restart Tenable.sc
   sudo systemctl restart SecurityCenter
   # Restart fluent-bit
   sudo systemctl restart fluent-bit
   EOF
   

4. Kopieren Sie das Skript in den iotools-Pod:

   knu -n tenablesc-system cp /tmp/tenable-sc-install-web-tls.sh iotools:/tmp/tenable-sc-install-web-tls.sh
   

5. Installieren Sie die Webserverzertifikate und ‑schlüssel.

   Führen Sie install-web-tls.sh auf der Tenable.sc-VM aus.

   knu -n tenablesc-system exec -i iotools -- /bin/bash -c "ssh -i /tmp/tenablesc alice@${INGRESS_IP:?} 'bash -s' < /tmp/tenable-sc-install-web-tls.sh"
   

   Der Tenablesc-Dienst verwendet jetzt die entsprechenden TLS-Zertifikate und ‑Schlüssel.

33.9.8. Logweiterleitung in Tenable.sc aktivieren

1. Folgen Sie der Anleitung unter NES-R0002, um sich in der Tenablesc-Benutzeroberfläche anzumelden.

2. Klicken Sie in der Navigationsleiste auf System > Konfigurationen.

3. Klicken Sie auf der Seite Konfigurationen auf Sonstiges.

4. Rufen Sie den Abschnitt Syslog auf:

   1. Aktivieren Sie die Option Weiterleitung aktivieren.
   2. Legen Sie die Einrichtung auf user fest.
   3. Wählen Sie unter Schweregrad die Option Alle auswählen aus.

5. Klicken Sie auf Senden, um die Konfiguration zu speichern.

   33.9.9. OIC-zu-GDC-Netzwerkverbindung aktivieren

Führen Sie die folgenden Schritte für die VMs nessus1 und nessus2 aus:

1. Richten Sie die folgenden Umgebungsvariablen ein:

   SITE_ID=
   OIC_DNS_SUFFIX=
   NESSUS_SUFFIX=
   GDC_SERVICES_ORG_URL_SUFFIX=$(kna get configmap dnssuffix -n gpc-system -o jsonpath='{.data.dnsSuffix}')
   

2. Konfigurationen auf der Verwaltungsebene der GDC-Dienste veröffentlichen:

   cat <<EOF | kubectl --kubeconfig ${ORG_INFRA_KUBECONFIG:?} apply -f -
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: root-infra-ingress-gateway-https-dr-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     host: ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
     trafficPolicy:
       portLevelSettings:
       - port:
           number: 8834
         tls:
           mode: SIMPLE
           sni: ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: DestinationRule
   metadata:
     name: infra-egress-gateway-nessus-dr-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     host: infra-egress-gateway.istio-system.svc.cluster.local
     subsets:
     - name: nessus-egress-${SITE_ID:?}-${NESSUS_SUFFIX:?}
       trafficPolicy:
         loadBalancer:
           simple: ROUND_ROBIN
         portLevelSettings:
         - port:
             number: 443
           tls:
             credentialName: nessus-tls
             mode: SIMPLE
             sni: ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: nessus-egress-gateway-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     selector:
       istio: infra-egress-gateway
     servers:
     - hosts:
       - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
       port:
         name: https-port
         number: 443
         protocol: HTTPS
       tls:
         cipherSuites:
         - ECDHE-ECDSA-AES256-GCM-SHA384
         - ECDHE-RSA-AES256-GCM-SHA384
         credentialName: nessus-tls
         mode: SIMPLE
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: nessus-terminated-gateway-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     selector:
       istio: management-ingress-gateway
     servers:
     - hosts:
       - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${GDC_SERVICES_ORG_URL_SUFFIX:?}
       port:
         name: https-port
         number: 443
         protocol: HTTPS
       tls:
         cipherSuites:
         - ECDHE-ECDSA-AES256-GCM-SHA384
         - ECDHE-RSA-AES256-GCM-SHA384
         credentialName: nessus-tls
         mode: SIMPLE
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: ServiceEntry
   metadata:
     name: nessus-svc-entry-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     hosts:
     - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
     location: MESH_EXTERNAL
     ports:
     - name: https-port
       number: 8834
       protocol: TLS
     resolution: DNS
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: nessus-admin-virtual-service-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     gateways:
     - istio-system/nessus-terminated-gateway-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     hosts:
     - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${GDC_SERVICES_ORG_URL_SUFFIX:?}
     http:
     - rewrite:
         authority: ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
       route:
       - destination:
           host: infra-egress-gateway.istio-system.svc.cluster.local
           port:
             number: 443
           subset: nessus-egress-${SITE_ID:?}-${NESSUS_SUFFIX:?}
   ---
   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: nessus-egress-virtual-service-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     gateways:
     - istio-system/nessus-egress-gateway-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     hosts:
     - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
     http:
     - match:
       - uri:
           prefix: /
       route:
       - destination:
           host: ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${OIC_DNS_SUFFIX:?}
           port:
             number: 8834
   ---
   apiVersion: security.istio.io/v1
   kind: AuthorizationPolicy
   metadata:
     name: mgmt-infra-egress-access-${SITE_ID:?}-${NESSUS_SUFFIX:?}
     namespace: istio-system
   spec:
     rules:
     - from:
       - source:
           ipBlocks:
           - 0.0.0.0/0
       to:
       - operation:
           hosts:
           - ${SITE_ID:?}-${NESSUS_SUFFIX:?}.${GDC_SERVICES_ORG_URL_SUFFIX:?}
     selector:
       matchLabels:
         istio: management-ingress-gateway
   EOF
   

3. Konfigurationen in der GDC-Steuerungsebene veröffentlichen:

   cat <<EOF | kubectl --kubeconfig ${ORG_MGMT_KUBECONFIG:?} apply -f -
   apiVersion: network.private.gdc.goog/v1alpha1
   kind: DNSRegistration
   metadata:
     name: ${SITE_ID:?}-${NESSUS_SUFFIX:?}-customer-internal
     namespace: tenablesc-system
   spec:
     fqdnPrefix: ${SITE_ID:?}-${NESSUS_SUFFIX:?}
     resolutionConfig:
       exposeToNetwork: VPC
       resolveTo:
         useDefaultIstioGateway:
           ingressLabel: admin
           owningCluster: InfraCluster
       vpcIdentifier: default
   EOF
   

33.9.10. Bereinigen

Löschen Sie das temporäre Nessus-Verzeichnis.

rm -rf /tmp/nessus

33.9.11. Lizenzaktivierung

In diesem Abschnitt finden Sie Informationen zum Anwenden der TenableSC-Lizenz.

1. Öffnen Sie die Tenablesc-Web-UI über die folgende URL:

   TENABLE_SC_HOST=$(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc -o jsonpath='{.status.fqdn}')
   
   echo "Navigate to https://${TENABLE_SC_HOST:?}"
   

2. Bevor die Lizenz angewendet wird, wird in der Benutzeroberfläche der Einrichtungsassistent angezeigt.

   Wenn auf der Benutzeroberfläche eine Anmeldeaufforderung angezeigt wird, wurde die Lizenz bereits angewendet und die restlichen Schritte in diesem Abschnitt sollten übersprungen werden.

3. Klicken Sie auf Weiter.

4. Laden Sie die Tenablesc-Lizenzdatei SecurityCenter-<version>-<number>IPs-<uid>.key hoch.

   Mögliche Probleme:

   • Error Activating License File. License Is Invalid. No Valid License Found.:

     Dieser Fehler bedeutet, dass die bereitgestellte Lizenzdatei ungültig ist. Gehen Sie die folgenden möglichen Ursachen durch:

     1. Falscher Hostname

        Auf der Tenabe.com-Produktseite für diese Lizenz ist der falsche Hostname festgelegt. Prüfen Sie, ob der Lizenz-Hostname auf der Tenable.com-Produktseite tenablesc-as1 lautet. Wenn der Hostname nicht übereinstimmt, legen Sie ihn auf tenablesc-as1 fest, laden Sie die neue Lizenz herunter und verwenden Sie stattdessen die neue Lizenzdatei.

     2. Fehlerhafte Datei

        Die Lizenzdatei wurde möglicherweise während der Übertragung geändert: Ähnlich wie bei der Nessus-Voraktivierungsdatei kann diese Lizenzdatei während der Übertragung nicht geändert werden. Die genaue Datei, die von der Tenable.com-Produktseite heruntergeladen wurde, muss in die Tenable-Benutzeroberfläche hochgeladen werden. Sie können prüfen, ob die Datei geändert wurde, indem Sie den SHA-Wert der Datei vor und nach der Übertragung vergleichen.

     3. Falsche Lizenzdatei

        Achten Sie darauf, dass Sie eine Tenable.sc-Lizenzdatei verwenden, die Sie auf der Produktseite von Tenable.com erhalten haben. Der Inhalt der Datei sollte einem PEM-Schlüssel ähneln.

     Wenn die Lizenz immer noch nicht funktioniert, erstellen Sie einen Metabug für das VULN-Team und geben Sie alle bisherigen Schritte zur Fehlerbehebung an.

5. Aktualisieren Sie die Seite. Wenn ein Anmeldebildschirm angezeigt wird, wurde die Lizenz erfolgreich angewendet.

Tenable.sc ist jetzt vollständig eingerichtet. Weitere Schritte zum Konfigurieren und Verwenden von Tenable.sc finden Sie im Bedienerhandbuch. Diese Schritte werden voraussichtlich später nach dem Bootstrap ausgeführt.

33.9.12. Optional: Deinstallieren

Dieser Abschnitt enthält die Befehle zum Entfernen der Tenable.sc-Bereitstellung.

Warnung:Durch die Deinstallation der Tenable.sc-Helm-Charts werden alle nichtflüchtigen Volumes entfernt und die Anwendungsdaten gelöscht.

Führen Sie die folgenden Schritte aus, um die Helm-Diagramme aus den Clustern zu deinstallieren:

1. Deinstallieren Sie das Helm-Diagramm aus dem Infrastrukturcluster der Organisation:

   helm uninstall --namespace tenablesc-system tenablesc-system --kubeconfig ${ORG_INFRA_KUBECONFIG:?}
   

2. Deinstallieren Sie das Helm-Diagramm vom Management-API-Server:

   helm uninstall --namespace tenablesc-system tenablesc-admin --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
   

3. Deinstallieren Sie das Helm-Diagramm für die Tenable SC-VM vom Management-API-Server:

   VIRTUAL_MACHINE_NAME=$(knu get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1)
   kna patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}'
   helm uninstall tenablesc-vms -n tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
   

33.9.13. Tenable.SC einrichten

Folgen Sie der Anleitung unter NES-G0001 – Tenable.SC einrichten, um Tenable.sc einzurichten.

33.10. Nessus-Bereitstellung validieren

In diesem Abschnitt werden Schritte beschrieben, mit denen Sie prüfen können, ob Nessus-Manager und ‑Agents wie erwartet ausgeführt und miteinander verknüpft sind. Außerdem finden Sie hier Schritte zur Behebung bekannter potenzieller Probleme.

Dieser Abschnitt sollte am Ende der Installation ausgeführt werden. Es wird jedoch auch empfohlen, diese Validierungsschritte vor dem Ausführen von Scans durchzuführen. Die Schritte zum Ausführen von Scans sind in der Bedienungsanleitung beschrieben.

Folgen Sie zuerst der Anleitung unter Umgebungsvariablen festlegen, um den Zugriff auf den Root-Administratorcluster einzurichten und den Befehlszeilenalias kra zu definieren.

33.10.1. Clustering validieren

Die primäre Methode zum Überprüfen, ob die Nessus-Manager und ‑Agents miteinander verknüpft sind, ist die primäre Nessus-Manager-Benutzeroberfläche. In der Benutzeroberfläche müssen die Nessus-Untergeordneten in der Standard-Clustergruppe für das Agent-Clustering und alle Nessus-Agents in der Standard-Agent-Gruppe aufgeführt sein.

Hinweis :Die Verknüpfung zwischen dem primären Nessus Manager und allen untergeordneten Elementen wird unterbrochen, wenn der primäre Nessus Manager nach der Erstinstallation neu gestartet wird. Dies kann eine natürliche Folge der Bereitstellung in Kubernetes sein.

1. Rufen Sie den DNS für die primäre Nessus Manager-Benutzeroberfläche ab:

   echo Nessus Manager UI: https://$(kra get dnsregistration \
       -n tenable-nessus-system nessus -o jsonpath='{.status.fqdn}')
   

2. Öffnen Sie einen Webbrowser und rufen Sie den Link aus den vorherigen Schritten auf. Sie werden zur primären Nessus Manager-Benutzeroberfläche weitergeleitet.

3. Melden Sie sich mit dem Nutzernamen admin und dem Standardpasswort admin in der Nessus Manager-Benutzeroberfläche an.

   Wenn bei der Anmeldung Authentifizierungsprobleme auftreten, folge NES-T0004, um die Nessus-Anmeldedaten zu rotieren und die Anmeldung noch einmal zu versuchen.

4. Klicken Sie oben auf der Seite auf Einstellungen.

   Prüfen Sie auf der Seite Einstellungen die Informationen unter Plug-ins. Wenn der Wert für Plugin Set nicht definiert ist, folgen Sie der Anleitung unter NES-T0001, um das neueste Plugin-Set auf den primären Nessus Manager anzuwenden.

5. Klicken Sie oben auf der Seite auf Sensors (Sensoren) und dann auf Agent Clustering (Agent-Clustering).

6. Klicken Sie auf Standard-Agentengruppe, um alle registrierten Knoten aufzurufen.

   Wenn die Gruppe leer ist oder der Knoten (untergeordnete Nessus-Instanz) für eine Organisation fehlt, muss die untergeordnete Nessus-Instanz neu registriert werden.

Hinweis :Es kann vorkommen, dass Nessus-Agents in einer Organisation mit einem untergeordneten Nessus Manager einer anderen Organisation verknüpft werden, weil sie von einem übergeordneten Knoten an die von den Agents erreichbaren untergeordneten Knoten verteilt werden.