33. Déployer les composants Nessus

Durée estimée : 1 jour

Propriétaire du composant exploitable : VULN

Profil de compétences : ingénieur en déploiement

Dernière mise à jour : 18 août 2025

Nessus est un scanner de sécurité pour les systèmes d'assistance et d'exploitation de Google Distributed Cloud (GDC) sous air gap. Il aide l'équipe du centre des opérations à surveiller les failles de sécurité matérielles et logicielles, et à y répondre.

Ce document présente les étapes de déploiement de Nessus et suppose que l'opérateur qui le suit effectue les étapes à partir d'un poste de travail OC avec PowerShell et WSL disponibles.

33.1. Avant de commencer

• Accès obligatoire

  • Suivez IAM-R0005 :
    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-root dans le cluster d'administrateur racine.
    • Obtenez le rôle role/system-artifact-management-admin dans l'espace de noms gpc-system du cluster d'administrateur racine.

• Outils requis

  • kubectl
  • gdcloud
  • helm
  • yq
  • docker

• Licences

  • Une licence Nessus
    • Suivez NES-G0004 : comment préactiver la licence Nessus pour préparer le bundle de préactivation "GDCH 1".

Remarque : gdcloud ne se résout pas par défaut. Si ce n'est pas le cas, modifiez votre chemin d'accès avec PATH=/root/release:${PATH:?} et réessayez.

33.1.1. Bonnes pratiques

33.1.1.1. Mises à niveau

Pour les mises à niveau à partir de versions antérieures à la version 1.14, suivez la section "Facultatif : Désinstaller" de chaque section principale de ce guide avant d'effectuer toute installation.

En cas de réinstallation, suivez la partie "Facultatif : Désinstaller" de chaque section principale de ce guide.

33.1.1.2. Gérer les différences de version entre les organisations et les zones

Il ne devrait pas y avoir de problèmes dus à la dérive de version entre les organisations et les zones. Veuillez suivre les étapes spécifiques à l'organisation en tenant compte de la version de l'organisation. Chaque déploiement sera alors indépendant par zone.

33.1.2. Licence Tenablesc

Tenable sc est un logiciel tiers sous licence qui nécessite un fichier de licence pour fonctionner. Vous devez obtenir une licence Tenable en fonction de la SBOM avant de continuer. Dans certains cas particuliers, nous pouvons vous fournir une licence.

Le fichier de licence doit être nommé, par exemple, SecurityCenter-<version>-1000IPs-<uid>.key. Localisez ce fichier et notez-le pour plus tard, car il devra être importé directement dans l'interface utilisateur Tenablesc.

Conditions requises :

• Un fichier de licence Tenablesc avec une limite d'au moins 1 000 adresses IP et le nom d'hôte tenablesc-as1

33.2. Localiser les fichiers de déploiement Nessus

Avant de déployer Nessus, suivez les étapes ci-dessous à l'aide de Windows PowerShell pour localiser les fichiers d'installation de Nessus :

1. Accédez aux charts Helm et à l'image de machine virtuelle (VM) Nessus :

   Dans l'OC, ils sont accessibles dans \\<dc-prefix>-hyperv1\OpsCenter\tenable-nessus.

   ./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. Déplacez les fichiers suivants vers votre poste de travail local pour les utiliser ultérieurement :

   # 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. Localiser le bundle de préactivation Nessus

Important : Cette étape n'est pas nécessaire pour les mises à niveau.

Le pack de préactivation Nessus est spécifique à chaque installation de Nessus et ne peut donc pas être inclus dans le pack du centre d'opérations. Suivez le guide Nessus NES-G0004 : comment effectuer la préactivation de la licence Nessus pour préparer le bundle de préactivation "GDCH 1" avant de continuer.

1. Sur une machine connectée à Internet, obtenez nessus-preact-gdch1.tar.gz vous-même ou par l'intermédiaire d'un point de contact de l'équipe d'ingénierie Google.

2. Transférez ce fichier vers votre poste de travail et placez-le sous $env:USERPROFILE\tenable-nessus.

3. Le répertoire $env:USERPROFILE\tenable-nessus doit contenir le bundle de préactivation :

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

33.4. Ouvrir WSL

Les étapes restantes de la page nécessitent WSL pour toutes les commandes, sauf indication contraire.

1. Facultatif : Sudo est obligatoire. Si vous ne connaissez pas le mot de passe de l'utilisateur sudo, exécutez la commande suivante pour définir le mot de passe de l'utilisateur sudo WSL oc-it :

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

33.5. Définir des variables d'environnement

Suivez les étapes ci-dessous pour définir les variables d'environnement requises :

1. Définissez la variable d'environnement ROOT_ADMIN_CLUSTER_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster d'administrateur généré en tant que prérequis :

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Définissez un alias pour la commande kubectl du cluster d'administrateur sélectionné dans le terminal actuel :

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

3. Définissez la variable USERPROFILE :

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

   $USERPROFILE pointe désormais vers le même emplacement que $env:USERPROFILE.

33.5.1. Définir des variables d'environnement pour l'organisation v1

1. Définissez la variable d'environnement ORG_ADMIN_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster d'administrateur de l'organisation sélectionné, généré en tant que prérequis :

   ORG_ADMIN_KUBECONFIG=
   

2. Définissez un alias pour la commande kubectl du cluster d'administrateur de l'organisation sélectionnée dans le terminal actuel :

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

3. Définissez la variable d'environnement ORG_SYSTEM_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster système sélectionné, généré en tant que prérequis :

   ORG_SYSTEM_KUBECONFIG=
   

4. Définissez un alias pour la commande kubectl du cluster système sélectionné dans le terminal actuel :

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

33.5.2. Définir des variables d'environnement pour l'organisation v2

1. Définissez la variable d'environnement ORG_MGMT_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du serveur d'API du plan de gestion de l'organisation v2 sélectionnée, généré en tant que prérequis :

   ORG_MGMT_KUBECONFIG=
   

2. Définissez un alias pour la commande kubectl du cluster d'administrateur de l'organisation sélectionnée dans le terminal actuel :

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

3. Définissez la variable d'environnement ORG_INFRA_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin d'accès absolu au fichier kubeconfig du serveur d'API du plan de contrôle de l'organisation v2 sélectionnée, généré en tant que prérequis :

   ORG_INFRA_KUBECONFIG=
   

4. Définissez un alias pour la commande kubectl du cluster système sélectionné dans le terminal actuel :

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

33.6. Importer un bundle de préactivation

Important : Cette étape n'est pas nécessaire pour les mises à niveau.

Suivez les étapes ci-dessous pour importer le registre Harbor d'artefacts.

1. Convertissez le bundle au format OCI avec les métadonnées appropriées :

   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. Installez le certificat CA Harbor :

   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"
   

   Trouvez le système d'exploitation :

   sudo sh -c "hostnamectl"
   

   Pour Rocky Linux comme système d'exploitation, exécutez la commande suivante :

   sudo update-ca-trust extract
   

   Pour Ubuntu comme système d'exploitation, exécutez :

   sudo update-ca-certificates
   

3. Importez le bundle de préactivation dans Harbor :

   • Méthode idéale : authentifiez-vous à l'aide de 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
     

   • Méthode de sauvegarde : 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. Installer Nessus

Avertissement : Pour les mises à niveau à partir de versions antérieures à la version 1.14, suivez la section "Facultatif : Désinstaller" avant de procéder à l'installation.

1. Déclenchez l'installation de Nessus :

   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. Attendez environ 1 h 30 que l'installation se termine.

33.7.1. Facultatif : Désinstaller Nessus

Cette section contient les commandes permettant de supprimer le déploiement Nessus de tous les clusters requis.

Avertissement : Ne désinstallez votre déploiement Nessus existant que si vous effectuez une réinstallation ou une mise à niveau. Sinon, ignorez cette section.

1. Désinstallez Nessus du cluster d'administrateur racine :

   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. Pour l'architecture d'organisation v1 :

   1. Désinstallez Nessus du cluster d'administrateur de l'organisation :

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

   2. Désinstallez Nessus du cluster système de l'organisation :

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

3. Pour l'architecture d'organisation v2 :

   1. Désinstallez Nessus du cluster de gestion de l'organisation :

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

   2. Désinstallez Nessus du cluster d'infrastructure de l'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. Vérifier Nessus dans le cluster d'administrateur racine

1. Vérifiez que les clés et les certificats sont publiés :

   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. Vérifiez que le parent Nessus Manager est en bon état :

   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. Si le Nessus Manager parent est signalé comme étant en mauvais état (par exemple, si le résultat de l'une des commandes précédentes est "false"), redémarrez-le à l'aide des commandes suivantes :

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

4. Patientez environ 1h30, puis vérifiez à nouveau l'état.

5. Si le Nessus Manager parent est toujours signalé comme non opérationnel après 1,5 heure, transférez le problème à l'équipe d'astreinte.

   1. Incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana :

      {pod="<pod_name>"}
      

   2. Incluez la configuration Nessus Manager parent :

      kra get pnm -A -o yaml
      

6. Vérifiez que le gestionnaire Nessus enfant est en bon état :

   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. Si l'état du gestionnaire Nessus enfant est signalé comme non sain, redémarrez-le à l'aide des commandes suivantes, patientez 20 minutes, puis vérifiez à nouveau l'état :

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

8. Si, après 20 minutes, le gestionnaire Child Nessus est toujours signalé comme non opérationnel, escaladez le problème et incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

   1. Incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana :

      {pod="<pod_name>"}
      

   2. Incluez la configuration Nessus Manager enfant :

      kra get cnm -A -o yaml
      

9. Vérifiez qu'aucun agent n'est défectueux :

   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. Pour tous les agents listés dans la liste des agents non opérationnels, définissez la variable NESSUS_AGENT_NAME et exécutez la commande suivante pour tous :

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

11. Si, au bout de 20 minutes, les agents non opérationnels sont toujours indiqués dans la liste, procédez comme suit pour chacun d'eux :

    • Vérifiez les journaux du pod install-<node_name> dans Grafana. Si un journal d'erreur ansible-playbook error: one or more host failed est présent, établissez une connexion SSH au nœud Bare Metal à l'aide de PLATAUTH-G0001.

    • Une fois la connexion SSH établie avec le nœud Bare Metal, déplacez /etc/yum.repos.d vers /etc/ yum.repos.d.back (pour supprimer efficacement la configuration des dépôts yum).

12. Si, au bout de 20 minutes, les agents non opérationnels sont toujours signalés dans la liste, escaladez le problème et incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

    1. Incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

       {pod="<pod_name>"}
       

    2. Incluez l'état de l'agent Nessus :

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

    3. Incluez la configuration de l'agent Nessus :

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

33.8. Nessus Manager : validation de l'organisation

Cette section décrit la procédure à suivre pour valider Nessus dans une organisation Distributed Cloud.

Pour que la validation Nessus soit réussie et complète, exécutez cette procédure pour chaque cluster d'organisation Distributed Cloud, y compris le cluster d'organisation informatique du centre d'opérations.

Répertoriez les organisations disponibles :

kra get -n gpc-system organization

Suivez les étapes ci-dessous pour chaque organisation, à l'exception de l'organisation root qui a déjà été traitée.

33.8.1. Prérequis

• Accès requis pour les organisations v1

  • Suivez IAM-R0005 :
    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-root dans le cluster d'administrateur racine.

  • Suivez IAM-R0004 :

    • Générez le fichier KUBECONFIG pour le cluster d'administrateur racine.

  • Suivez IAM-R0005 :

    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-org-legacy dans le cluster d'administrateur de l'organisation cible.

  • Suivez IAM-R0004 :

    • Générez le fichier KUBECONFIG pour le cluster d'administrateur de l'organisation cible.

  • Suivez IAM-R0005 :

    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-system-legacy dans le cluster du système cible.

  • Suivez IAM-R0004 :

    • Générez le fichier KUBECONFIG pour le cluster du système cible.

• Accès requis pour les organisations v2

  • Suivez IAM-R0005 :
    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-root dans le cluster d'administrateur racine.
  • Suivez IAM-R0004 :
    • Générez le fichier KUBECONFIG pour le cluster d'administrateur racine.
  • Suivez IAM-R0005 :
    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-infra-mp dans le cluster cible.
  • Suivez IAM-R0004 :
    • Générez le fichier KUBECONFIG mp pour le cluster d'infrastructure cible.
  • Suivez IAM-R0005 :
    • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-infra-cp dans le serveur d'API Kube du plan de contrôle de l'infrastructure cible.
  • Suivez IAM-R0004 :
    • Générez le fichier KUBECONFIG cp pour le cluster d'infrastructure.

Suivez Définir des variables d'environnement pour configurer l'accès aux clusters de l'organisation et définir les alias de ligne de commande kna et knu.

33.8.2. Vérifier Nessus dans le cluster d'administrateur de l'organisation dans les organisations v1 et le serveur d'API kube du plan de gestion de l'infrastructure dans les organisations v2

1. Vérifiez qu'aucun agent n'est défectueux :

   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. Pour tous les agents listés dans la liste des agents non opérationnels, définissez la variable NESSUS_AGENT_NAME et exécutez la commande suivante pour tous :

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

3. Si, au bout de 20 minutes, les agents non opérationnels sont toujours indiqués dans la liste, procédez comme suit pour chacun d'eux :

   • Vérifiez les journaux du pod install-<node_name> dans Grafana. Si un journal d'erreur ansible-playbook error: one or more host failed est présent, établissez une connexion SSH au nœud Bare Metal à l'aide de PLATAUTH-G0001.

   • Une fois la connexion SSH établie avec le nœud Bare Metal, déplacez /etc/yum.repos.d vers /etc/ yum.repos.d.back (pour supprimer efficacement la configuration des dépôts yum).

4. Si, au bout de 20 minutes, les agents non opérationnels sont toujours signalés dans la liste, escaladez le problème et incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

   {pod="<pod_name>"}
   

33.8.3. Vérifier Nessus dans le cluster système des organisations V1 et le serveur d'API kube du plan de contrôle de l'infrastructure dans les organisations V2

1. Vérifiez que le gestionnaire Nessus enfant est en bon état :

   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. Si l'état du gestionnaire Nessus enfant est signalé comme non sain, redémarrez-le à l'aide des commandes suivantes, patientez 20 minutes, puis vérifiez à nouveau l'état :

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

3. Si, au bout de 20 minutes, le gestionnaire Child Nessus est toujours signalé comme non opérationnel, escaladez le problème et incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

   1. Incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

      {pod="<pod_name>"}
      

   2. Incluez la configuration Nessus Manager enfant.

      knu get cnm -A -o yaml
      

4. Vérifiez qu'aucun agent n'est défectueux :

   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. Pour tous les agents listés dans la liste des agents non opérationnels, définissez la variable NESSUS_AGENT_NAME et exécutez la commande suivante pour tous :

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

6. Si, au bout de 20 minutes, les agents non opérationnels sont toujours indiqués dans la liste, procédez comme suit pour chacun d'eux :

   • Vérifiez les journaux du pod install-<node_name> dans Grafana. Si un journal d'erreur ansible-playbook error: one or more host failed est présent, établissez une connexion SSH au nœud Bare Metal à l'aide de PLATAUTH-G0001.

   • Une fois la connexion SSH établie avec le nœud Bare Metal, déplacez /etc/yum.repos.d vers /etc/ yum.repos.d.back (pour supprimer efficacement la configuration des dépôts yum).

7. Si, au bout de 20 minutes, les agents non opérationnels sont toujours signalés dans la liste, escaladez le problème et incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana.

   1. Incluez les informations suivantes après avoir exécuté la requête donnée depuis l'interface utilisateur Grafana :

      {pod="<pod_name>"}
      

   2. Incluez l'état de l'agent Nessus :

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

   3. Incluez la configuration de l'agent Nessus :

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

33.9. Installer Tenable.sc

Cette section décrit la procédure d'installation ou de mise à niveau d'une VM Tenable.sc existante au sein de l'organisation informatique du centre d'opérations.

33.9.1. Prérequis

• Accès obligatoire

  • Pour l'architecture d'organisation v1 :
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-root dans le cluster d'administrateur racine.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster d'administrateur racine.
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-org-legacy dans le cluster d'administrateur gdchservices.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster d'administrateur gdchservices.
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-system-legacy dans le cluster système gdchservices.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster système gdchservices.
  • Pour l'architecture d'organisation v2 :
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-root dans le cluster d'administrateur racine.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster d'administrateur racine.
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-infra-mp dans le cluster gdchservices-management.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster gdchservices-management.
    • Suivez IAM-R0005 :
      • Obtenez le rôle de cluster clusterrole/tenable-nessus-admin-infra-cp dans le cluster gdchservices-infra.
    • Suivez IAM-R0004 :
      • Générez le fichier KUBECONFIG pour le cluster gdchservices-infra.

33.9.2. Définir des variables d'environnement

Suivez les étapes ci-dessous pour définir les variables d'environnement requises :

1. Définissez la variable d'environnement ROOT_ADMIN_CLUSTER_KUBECONFIG pour une utilisation ultérieure dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster d'administrateur généré en tant que prérequis :

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Définissez un alias pour la commande kubectl du cluster d'administrateur racine dans le terminal actuel :

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

3. Définissez la variable d'environnement pour le fichier kubeconfig du plan de gestion de l'organisation gdchservices :

   • Pour l'architecture d'organisation v1 : Définissez la variable d'environnement ORG_ADMIN_KUBECONFIG pour l'utiliser ultérieurement dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster d'administrateur gdchservices généré en tant que prérequis :

     ORG_ADMIN_KUBECONFIG=
     

   • Pour l'architecture d'organisation v2 : définissez la variable d'environnement ORG_MGMT_KUBECONFIG pour l'utiliser ultérieurement dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster de gestion gdchservices généré en tant que prérequis :

     ORG_MGMT_KUBECONFIG=
     

4. Créez un alias pour la commande kubectl à l'aide du fichier kubeconfig ci-dessus :

   • Pour l'architecture d'organisation v1 : Définissez un alias pour la commande kubectl du cluster d'administrateur gdchservices dans le terminal actuel :

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

   • Pour l'architecture d'organisation v2 : définissez un alias pour la commande kubectl du cluster d'administrateur gdchservices dans le terminal actuel :

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

5. Définissez la variable d'environnement pour le fichier kubeconfig du plan de contrôle de l'organisation gdchservices :

   • Pour l'architecture d'organisation v1 : Définissez la variable d'environnement ORG_SYSTEM_KUBECONFIG pour l'utiliser ultérieurement dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster système gdchservices généré en tant que prérequis :

     ORG_SYSTEM_KUBECONFIG=
     

   • Pour l'architecture d'organisation v2 : définissez la variable d'environnement ORG_INFRA_KUBECONFIG pour l'utiliser ultérieurement dans le terminal actuel. Il doit s'agir d'un chemin absolu vers le fichier kubeconfig du cluster d'infrastructure gdchservices généré en tant que prérequis :

     ORG_INFRA_KUBECONFIG=
     

6. Créez un alias pour la commande kubectl à l'aide du fichier kubeconfig ci-dessus :

   • Pour l'architecture d'organisation v1 : définissez un alias pour la commande kubectl du cluster système gdchservices dans le terminal actuel :

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

   • Pour l'architecture d'organisation v2 : Définissez un alias pour la commande kubectl du cluster d'infrastructure gdchservices dans le terminal actuel :

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

7. Définissez la variable USERPROFILE :

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

   $USERPROFILE pointe désormais vers le même emplacement que $env:USERPROFILE.

8. Définissez le nom de l'organisation dans laquelle Tenable.sc est déployé :

   ORG=gdchservices
   

33.9.3. Préparer l'installation

Suivez les étapes ci-dessous pour préparer l'organisation.

1. Créez le projet tenablesc-system.

   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. Après deux minutes, vérifiez que les espaces de noms existent à la fois sur le cluster de l'administrateur de l'organisation et sur le cluster système.

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

   Notez que le libellé de projet resourcemanager.gdc.goog/attach-all-user-clusters: "true" entraîne également la création de l'espace de noms dans tous les clusters d'utilisateur de l'organisation.

3. Générez et enregistrez les identifiants de l'administrateur et du gestionnaire Tenablesc en tant que secret Kubernetes.

   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. Installer un graphique d'administrateur

1. Définissez les variables d'environnement suivantes pour préparer l'installation :

   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. Appliquez le chart Helm de l'administrateur.

   • Pour l'architecture d'organisation 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:?}
     

   • Pour l'architecture d'organisation v2 :

     Définissez OCIT_NESSUS_MANAGER_PREFIXES sous la forme d'une liste séparée par des virgules, telle que "{dc1-nessus1,dc1-nessus2}", indiquant le préfixe de la VM OCIT.

     Définissez OCIT_NESSUS_URL_SUFFIX pour indiquer le suffixe de la VM OCIT.

     Appliquez les mises à jour Helm pour le plan de gestion :

     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:?}
     

     Appliquez les mises à jour Helm pour le plan d'infrastructure :

     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:?}
     

     Appliquez la règle d'autorisation Istio :

     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
     

     Créez une entrée de service :

     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
     

     Créez un enregistrement DNS :

     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
     

     Stockez le nom de domaine complet dans une variable d'environnement après avoir attendu cinq minutes :

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

     Corrigez le service virtuel et la passerelle pour ajouter le FQDN interne Tenable SC :

     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:?}"'"}]'
     

     Corrigez la ressource du vérificateur pour vérifier le point de terminaison approprié :

     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. Vérifiez le déploiement.

   Examinez le résultat de la commande suivante pour vérifier que le déploiement tenablesc-admin a réussi :

   • Pour l'architecture d'organisation v1 :

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

   • Pour l'architecture d'organisation v2 :

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

4. Vérifiez que le service virtuel existe.

   • Pour l'architecture d'organisation v1 :

     kna get virtualservice -n tenablesc-system
     

   • Pour l'architecture d'organisation v2 :

     knu get virtualservice -n tenablesc-system
     

5. Vérifiez que l'entrée DNS existe.

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

6. Vérifiez que le AuditLoggingTarget est prêt. Cette opération devrait prendre plusieurs minutes.

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

   • L'erreur suivante peut se produire :

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

     Si c'est le cas, l'espace de noms tenablesc-system doit être créé dans le cluster spécifié. Pour continuer, créez l'espace de noms, puis ouvrez un méta-bug pour déclencher une enquête sur l'origine de cette erreur. Incluez la sortie de la description du projet tenablesc-system dans la demande.

     kna describe project tenablesc-system
     

   • L'erreur suivante peut se produire :

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

     Si c'est le cas, créez manuellement le AuditLoggingTarget manquant :

     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
     

     Après cinq minutes, le résultat devrait ressembler à ce qui suit :

     {
         "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
     }
     

     Si, au bout de 10 minutes, l'état affiché semble toujours incorrect, il est possible que la plate-forme Observability ne soit pas opérationnelle. Ouvrez un méta-bug avec les informations d'état disponibles pour faciliter le débogage.

33.9.5. Graphique "Installer des VM"

1. Définissez les variables d'environnement suivantes pour préparer l'installation :

   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
   

   • Pour l'architecture d'organisation 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 }')
     

   • Pour l'architecture d'organisation 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. Définissez le type de machine virtuelle :

   1. Obtenez les noms de tous les types de machines virtuelles :

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

   2. Sélectionnez le type de machines virtuelles avec le champ Supported défini sur true et stockez-le dans variable d'environnement. Préférence : n2-standard-4-gdc et n3-standard-4-gdc.

      VIRTUAL_MACHINE_TYPE=
      

3. Un ProjectNetworkPolicy est nécessaire pour que les journaux Tenable.sc soient transmis à l'instance Loki infra-obs.

   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. Appliquez le chart Helm des VM.

   • Pour l'architecture d'organisation 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:?}
     

   • Pour l'architecture d'organisation 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:?}
     

   Lorsque vous appliquez le chart Helm, vous pouvez rencontrer les problèmes suivants :

   • Échec du webhook : 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
     

     Solution : Exécutez à nouveau la commande de mise à niveau Helm.

5. Vérifiez le déploiement. Examinez le résultat de la commande suivante pour vérifier que le déploiement tenablesc-vm a réussi :

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

6. Attendez que Tenablesc commence à s'exécuter.

   Vérifiez l'état de la machine virtuelle :

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

   Exemple de résultat indiquant que la VM est toujours en cours de provisionnement :

   NAME            STATUS    AGE
   tenablesc-as1   Pending   55s
   

   Exemple de résultat indiquant que la VM est en cours d'exécution :

   NAME            STATUS    AGE
   tenablesc-as1   Running   8m25s
   

   Si la VM n'est pas en cours d'exécution au bout de 60 minutes, examinez les événements de l'espace de noms pour détecter d'éventuelles erreurs.

   knu get -n tenablesc-system events -o wide
   

   Rassemblez les avertissements et les erreurs notables, puis signalez-les avec un métabug.

7. Un VirtualService et un DestinationRule sont requis pour accéder à l'interface utilisateur Tenable.sc.

   • Pour l'architecture d'organisation v1 : aucune modification n'est requise.

   • Pour l'architecture d'organisation v2 :

     • Définissez le nom du service en tant que variable d'environnement pour une utilisation ultérieure :

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

     • Modifiez les CR VirtualService et 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. Vérifiez que le DNS est résolu en adresse IP.

   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. Vérifiez que le service est résolu via le DNS.

   Remarque : Si vous utilisez des programmes d'installation fournis par vos soins, ignorez cette étape.

   Le résultat attendu est un code de réponse 200 et un résultat HTML.

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

33.9.6. Préparer les identifiants SSH de la VM Tenablesc

Suivez les étapes ci-dessous pour préparer SSH à accéder à la VM Tenable.

1. Générez une clé SSH.

   Cette clé SSH ne sera utilisée que temporairement pour accéder à la VM.

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

2. Définissez les variables d'environnement suivantes.

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

3. Créez un VirtualMachineRequest temporaire (24 heures).

   VirtualMachineRequest permet d'installer le certificat SSH généré sur la VM.

   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. Exportez l'adresse IP SSH de la VM en tant que variable d'environnement local.

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

5. Testez le fonctionnement de la connexion SSH :

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

   Le résultat attendu est alice, qui correspond au nom d'utilisateur SSH.

   Si la connexion SSH expire, cela signifie que la règle d'entrée est manquante. Créez la règle d'entrée avec la commande suivante, puis réessayez.

6. Créez la règle d'entrée :

   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. Provisionnez un pod iotools dans l'espace de noms tenablesc-system :

   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. Transférez la clé privée vers le pod iotools :

9. Transférez la clé privée vers le pod iotools :

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

33.9.7. Installer les certificats de service Web

Suivez les étapes ci-dessous pour installer les certificats du service Web Tenablesc.

1. Exportez l'adresse IP SSH de la VM en tant que variable d'environnement local :

   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. Préparez les certificats et les clés du serveur Web.

   Les commandes suivantes installent les certificats et les clés TLS qui seront utilisés pour diffuser l'interface utilisateur Tenable.

   1. Définir le nom du certificat TLS

      TLS_SECRET_NAME=nessus-tls
      

   2. Enregistrez le certificat nessus-tls en local :

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

   3. Copiez le certificat nessus-tls dans le pod iotools :

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

   4. Mettez en scène le certificat TLS.

      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. Placez la clé privée TLS.

      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. Placez le certificat TLS de l'autorité de certification.

      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. Préparez le script d'installation du certificat.

   Enregistrez le code suivant dans /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. Copiez le script sur le pod iotools :

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

5. Installez les certificats et les clés du serveur Web.

   Exécutez install-web-tls.sh sur la VM Tenable.sc.

   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"
   

   Le service Tenablesc utilise désormais les certificats et clés TLS appropriés.

33.9.8. Activer le transfert de journaux dans Tenable.sc

1. Suivez NES-R0002 pour vous connecter à l'interface utilisateur Tenablesc.

2. Dans la barre de navigation, accédez à Système > Configurations.

3. Sur la page Configurations, cliquez sur Divers.

4. Accédez à la section Syslog :

   1. Activez l'option Activer le transfert.
   2. Définissez Établissement sur user.
   3. Dans Gravité, sélectionnez Tout sélectionner.

5. Cliquez sur Envoyer pour enregistrer la configuration.

   33.9.9. Activer la connectivité réseau entre OIC et GDC

Procédez comme suit pour les VM nessus1 et nessus2 :

1. Configurez les variables d'environnement suivantes :

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

2. Publiez les configurations sur le plan de gestion des services GDC :

   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. Publiez les configurations sur le plan de contrôle GDC :

   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. Effectuer un nettoyage

Supprimez le répertoire Nessus temporaire.

rm -rf /tmp/nessus

33.9.11. Activation de la licence

Cette section explique comment appliquer la licence Tenablesc.

1. Ouvrez l'interface utilisateur Web Tenablesc à l'aide de l'URL suivante :

   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. Avant l'application de la licence, l'UI affiche l'assistant de configuration.

   Si l'interface utilisateur affiche une invite de connexion, cela signifie que la licence a déjà été appliquée et que vous devez ignorer les étapes restantes de cette section.

3. Cliquez sur Suivant.

4. Importez le fichier de licence Tenable.sc SecurityCenter-<version>-<number>IPs-<uid>.key.

   Problèmes potentiels :

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

     Cette erreur signifie que le fichier de licence fourni n'est pas valide. Examinez les causes potentielles suivantes :

     1. Nom d'hôte incorrect

        Le nom d'hôte incorrect est défini sur la page produit Tenable.com pour cette licence. Vérifiez que le nom d'hôte de la licence sur la page produit Tenable.com est tenablesc-as1. Si le nom d'hôte ne correspond pas, définissez-le sur tenablesc-as1, téléchargez la nouvelle licence et utilisez le nouveau fichier de licence.

     2. Fichier mal formé

        Le fichier de licence a peut-être été modifié lors du transfert : comme le fichier de préactivation Nessus, ce fichier de licence ne peut pas être modifié en transit. Le fichier exact téléchargé depuis la page produit Tenable.com doit être importé dans l'UI Tenable. Vous pouvez vérifier si le fichier a été modifié en comparant son SHA avant et après le transfert.

     3. Fichier de licence incorrect

        Assurez-vous d'utiliser un fichier de licence Tenable.sc obtenu sur la page produit Tenable.com. Le contenu du fichier doit être semblable à une clé PEM.

     Si la licence ne fonctionne toujours pas, ouvrez un metabug avec l'équipe VULN et incluez toutes les étapes de dépannage tentées jusqu'à présent.

5. Actualisez la page. Si un écran de connexion s'affiche, cela signifie que la licence a été appliquée.

Tenablesc est désormais entièrement amorcé. D'autres étapes de configuration et d'utilisation de Tenablesc sont disponibles dans le manuel de l'opérateur. Elles doivent être effectuées ultérieurement, après l'amorçage.

33.9.12. Facultatif : Désinstaller

Cette section contient les commandes permettant de supprimer le déploiement Tenable.sc.

Avertissement : La désinstallation des graphiques Helm Tenable.sc supprime tous les volumes persistants et les données de l'application.

Suivez les étapes ci-dessous pour désinstaller les charts Helm des clusters :

1. Désinstallez le chart Helm du cluster d'infrastructure de l'organisation :

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

2. Désinstallez le chart Helm du serveur d'API de gestion :

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

3. Désinstallez le chart Helm pour la VM Tenable SC à partir du serveur de l'API de gestion :

   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. Configuration de Tenable.SC

Suivez NES-G0001 : configurer Tenable.SC pour configurer Tenable.sc.

33.10. Valider le déploiement de Nessus

Cette section décrit les étapes à suivre pour vérifier que les gestionnaires et les agents Nessus fonctionnent et sont associés comme prévu, et fournit des étapes pour résoudre les problèmes potentiels connus.

Cette section est censée être exécutée à la fin de l'installation, mais il est également recommandé de suivre ces étapes de validation avant d'effectuer des analyses. La procédure d'analyse est décrite dans le manuel de l'opérateur.

Avant de commencer, suivez Définir des variables d'environnement pour configurer l'accès au cluster d'administrateur racine et définir l'alias de ligne de commande kra.

33.10.1. Valider le clustering

Le principal moyen de valider que les Nessus Managers et les agents sont associés consiste à utiliser l'interface utilisateur du Nessus Manager principal. Dans l'interface utilisateur, les enfants Nessus doivent être listés dans le groupe de clusters par défaut, et tous les agents Nessus doivent être listés dans le groupe d'agents par défaut.

Remarque : Le lien entre le Nessus Manager principal et tous les enfants est rompu si le Nessus Manager principal est redémarré après l'installation initiale. Cela peut se produire naturellement lorsque vous déployez sur Kubernetes.

1. Obtenez le DNS de l'interface utilisateur principale de Nessus Manager :

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

2. Ouvrez un navigateur Internet et accédez au lien des étapes précédentes. Vous êtes alors redirigé vers l'interface utilisateur principale de Nessus Manager.

3. Connectez-vous à l'interface utilisateur de Nessus Manager avec le nom d'utilisateur admin et le mot de passe par défaut admin.

   En cas de problème d'authentification lors de la connexion, suivez NES-T0004 pour faire tourner les identifiants Nessus et réessayez de vous connecter.

4. Cliquez sur Paramètres en haut de la page.

   Sur la page Paramètres, consultez les informations sur les plug-ins. Si la valeur de Plugin Set n'est pas définie, suivez NES-T0001 pour réappliquer le dernier ensemble de plug-ins au Nessus Manager principal.

5. Cliquez sur Capteurs en haut de la page, puis sur Regroupement des agents.

6. Cliquez sur Default Agent Group (Groupe d'agents par défaut) pour afficher tous les nœuds enregistrés.

   Si le groupe est vide ou si le nœud (instance Nessus enfant) d'une organisation est manquant, l'instance Nessus enfant doit être réenregistrée.

Remarque : Il peut arriver que des agents Nessus d'une organisation soient associés à un Nessus Manager enfant d'une autre organisation en raison de la distribution par un nœud parent aux nœuds enfants accessibles par les agents.