33. Desplegar componentes de Nessus

Tiempo estimado para completarlo: 1 día

Propietario del componente operable: VULN

Perfil de habilidades: ingeniero de implementaciones

Última actualización: 18 de agosto del 2025

Nessus es un escáner de seguridad para los sistemas de asistencia y operativos de Google Distributed Cloud (GDC) aislado. Ayuda al equipo del centro de operaciones a monitorizar y responder a las vulnerabilidades de seguridad del hardware y el software.

En este documento se describen los pasos para desplegar Nessus y se presupone que el operador que lo siga está realizando los pasos desde una estación de trabajo de OC con PowerShell y WSL disponibles.

33.1. Antes de empezar

• Se requiere acceso

  • Sigue la IAM-R0005:
    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-root en el clúster de administrador raíz.
    • Obtén el rol role/system-artifact-management-admin en el espacio de nombres gpc-system del clúster de administrador raíz.

• Herramientas necesarias

  • kubectl
  • gdcloud
  • Helm
  • yq
  • docker

• Licencias

  • Una licencia de Nessus
    • Sigue las instrucciones del artículo NES-G0004 - How to perform Nessus license preactivation (NES-G0004 - Cómo preactivar una licencia de Nessus) para preparar el paquete de preactivación "GDCH 1".

Nota: Es posible que gdcloud no se resuelva de forma predeterminada. Si no es así, modifica la ruta con PATH=/root/release:${PATH:?} y vuelve a intentarlo.

33.1.1. Prácticas recomendadas

33.1.1.1. Actualizaciones

Si vas a actualizar desde versiones anteriores a la 1.14, sigue las instrucciones de la sección "Opcional: desinstalar" de cada sección principal de esta guía antes de realizar cualquier instalación.

En caso de que tengas que volver a instalarla, sigue la parte "Opcional: desinstalar" de cada sección principal de esta guía.

33.1.1.2. Gestionar las diferencias de versión entre organizaciones y zonas

No debería haber ningún problema debido a la diferencia de versiones entre organizaciones y zonas. Sigue los pasos específicos de la organización teniendo en cuenta la versión de la organización. Cada implementación será independiente por zona.

33.1.2. Licencia de Tenable.sc

Tenable.sc es un software de terceros con licencia que requiere un archivo de licencia para funcionar. Antes de continuar, debe obtener una licencia de Tenable de acuerdo con la lista de materiales de software. En casos especiales, es posible que podamos proporcionarte una licencia.

El archivo de licencia debe tener un nombre como SecurityCenter-<version>-1000IPs-<uid>.key. Busca este archivo y anótalo para más adelante, ya que tendrás que subirlo directamente a la interfaz de usuario de Tenable.sc.

Requisitos:

• Un archivo de licencia de Tenable.sc con un límite de al menos 1000 IPs y el nombre de host tenablesc-as1

33.2. Buscar archivos de implementación de Nessus

Antes de implementar Nessus, sigue estos pasos con Windows PowerShell para localizar los archivos de instalación de Nessus:

1. Accede a los gráficos de Helm de Nessus y a la imagen de máquina virtual (VM):

   En el OC, se puede acceder a ellos en \\<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. Mueve estos archivos a tu estación de trabajo local para usarlos más adelante:

   # 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. Localizar el paquete de preactivación de Nessus

Importante: Este paso no es necesario para las actualizaciones.

El paquete de preactivación de Nessus es específico de cada instalación de Nessus y, por lo tanto, no se puede incluir en el paquete del centro de operaciones. Sigue la guía de Nessus NES-G0004 - How to perform Nessus license preactivation (NES-G0004 - Cómo preactivar la licencia de Nessus) para preparar el paquete de preactivación "GDCH 1" antes de continuar.

1. En una máquina conectada a Internet, obtén nessus-preact-gdch1.tar.gz por tu cuenta o a través de un contacto de ingeniería de Google.

2. Transfiere este archivo a tu estación de trabajo y colócalo en $env:USERPROFILE\tenable-nessus.

3. El directorio $env:USERPROFILE\tenable-nessus debe contener el paquete de preactivación:

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

33.4. Abrir WSL

En los pasos restantes de la página se requiere WSL para todos los comandos, a menos que se indique lo contrario.

1. Opcional: es necesario usar sudo. Si no sabes la contraseña del usuario sudo, ejecuta el siguiente comando para definir la contraseña del usuario sudo de WSL oc-it:

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

33.5. Establece variables de entorno:

Sigue estos pasos para definir las variables de entorno obligatorias:

1. Define la variable de entorno ROOT_ADMIN_CLUSTER_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de administrador generado como requisito previo:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Define un alias para el comando kubectl del clúster de administrador seleccionado en el terminal actual:

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

3. Define la variable USERPROFILE:

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

   $USERPROFILE ahora apunta a la misma ubicación que $env:USERPROFILE.

33.5.1. Definir variables de entorno para la organización de la versión 1

1. Define la variable de entorno ORG_ADMIN_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de administrador de la organización seleccionado, que se ha generado como requisito previo:

   ORG_ADMIN_KUBECONFIG=
   

2. Define un alias para el comando kubectl del clúster del administrador de la organización seleccionado en la terminal actual:

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

3. Define la variable de entorno ORG_SYSTEM_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster del sistema seleccionado que se haya generado como requisito previo:

   ORG_SYSTEM_KUBECONFIG=
   

4. Define un alias para el comando kubectl del clúster del sistema seleccionado en la terminal actual:

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

33.5.2. Definir variables de entorno para la organización de la versión 2

1. Define la variable de entorno ORG_MGMT_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del servidor de la API del plano de gestión de la organización de la versión 2 seleccionada, que se genera como requisito previo:

   ORG_MGMT_KUBECONFIG=
   

2. Define un alias para el comando kubectl del clúster del administrador de la organización seleccionado en la terminal actual:

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

3. Define la variable de entorno ORG_INFRA_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del servidor de la API del plano de control de la organización de la versión 2 seleccionada, que se ha generado como requisito previo:

   ORG_INFRA_KUBECONFIG=
   

4. Define un alias para el comando kubectl del clúster del sistema seleccionado en la terminal actual:

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

33.6. Subir paquete de preactivación

Importante: Este paso no es necesario para las actualizaciones.

Sigue estos pasos para subir el registro de artefactos de Harbor.

1. Convierte el paquete al formato OCI con los metadatos adecuados:

   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. Instala el certificado de CA de 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"
   

   Busca el sistema operativo:

   sudo sh -c "hostnamectl"
   

   Si el sistema operativo es Rocky Linux, ejecuta el siguiente comando:

   sudo update-ca-trust extract
   

   Si usas Ubuntu como sistema operativo, ejecuta el siguiente comando:

   sudo update-ca-certificates
   

3. Sube el paquete de preactivación a Harbor:

   • Método ideal: autenticar con 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étodo de copia de seguridad: con 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. Instalar Nessus

Advertencia: Si vas a actualizar desde una versión anterior a la 1.14, sigue las instrucciones de la sección "Opcional: desinstalar" antes de continuar con la instalación.

1. Activa la instalación 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. Espera aproximadamente 1,5 horas a que termine la instalación.

33.7.1. Opcional: Desinstalar Nessus

En esta sección se incluyen los comandos para eliminar la implementación de Nessus de todos los clústeres necesarios.

Advertencia: Desinstala tu implementación de Nessus solo si vas a volver a instalarla o actualizarla. De lo contrario, sáltate esta sección.

1. Desinstala Nessus del clúster de administrador raíz:

   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. En el caso de la arquitectura de organización v1:

   1. Desinstala Nessus del clúster de administrador de la organización:

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

   2. Desinstala Nessus del clúster del sistema de la organización:

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

3. En la versión 2 de la arquitectura de organización:

   1. Desinstala Nessus del clúster de gestión de organizaciones:

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

   2. Desinstala Nessus del clúster de infraestructura de la organización:

      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. Verificar Nessus en el clúster de administradores raíz

1. Verifica que las claves y los certificados se hayan publicado:

   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. Verifica que el Nessus Manager principal esté en buen estado:

   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 se informa de que el Nessus Manager principal no está en buen estado (por ejemplo, si el resultado de alguno de los comandos anteriores es falso), reinicia el Nessus Manager principal con los siguientes comandos:

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

4. Espera aproximadamente 1,5 horas y vuelve a comprobar el estado.

5. Si el Nessus Manager principal sigue mostrando un estado incorrecto después de 1,5 horas, deriva el problema al equipo de guardia.

   1. Incluye la siguiente información después de ejecutar la consulta proporcionada en la interfaz de usuario de Grafana:

      {pod="<pod_name>"}
      

   2. Incluye la configuración de Nessus Manager principal:

      kra get pnm -A -o yaml
      

6. Verifica que el Nessus Manager secundario esté en buen estado:

   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 se informa de que el Nessus Manager secundario no está en buen estado, reinícialo con los siguientes comandos, espera 20 minutos y vuelve a comprobar el estado:

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

8. Si, transcurridos 20 minutos, el gestor secundario de Nessus sigue mostrando un estado incorrecto, deriva el problema e incluye la siguiente información después de ejecutar la consulta proporcionada desde la interfaz de usuario de Grafana.

   1. Incluye la siguiente información después de ejecutar la consulta proporcionada en la interfaz de usuario de Grafana:

      {pod="<pod_name>"}
      

   2. Incluye la configuración de Nessus Manager secundario:

      kra get cnm -A -o yaml
      

9. Verifica que no haya agentes en mal estado:

   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. En todos los agentes que aparecen en la lista de agentes no operativos, define la variable NESSUS_AGENT_NAME y ejecuta el siguiente comando para todos ellos:

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

11. Si, transcurridos 20 minutos, los agentes no operativos siguen apareciendo en la lista, haz lo siguiente con cada agente:

    • Consulta los registros del pod install-<node_name> en Grafana y, si hay un registro de errores ansible-playbook error: one or more host failed, establece una conexión SSH con el nodo de hardware desnudo mediante PLATAUTH-G0001.

    • Después de establecer una conexión SSH con el nodo Bare Metal, mueve /etc/yum.repos.d a /etc/ yum.repos.d.back (para eliminar de forma efectiva la configuración de los repositorios de yum).

12. Si, transcurridos 20 minutos, los agentes no aptos siguen apareciendo en la lista, deriva el problema e incluye la siguiente información después de ejecutar la consulta dada desde la interfaz de usuario de Grafana.

    1. Incluye la siguiente información después de ejecutar la consulta dada desde la interfaz de usuario de Grafana.

       {pod="<pod_name>"}
       

    2. Incluye el estado del agente de Nessus:

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

    3. Incluye la configuración del agente de Nessus:

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

33.8. Nessus Manager: verificación de la organización

En esta sección se describen los pasos necesarios para verificar Nessus en una organización de Distributed Cloud.

Para que la verificación de Nessus se realice correctamente, sigue este procedimiento para cada clúster de organización de Distributed Cloud, incluido el clúster de organización de TI del centro de operaciones.

Lista de organizaciones disponibles:

kra get -n gpc-system organization

Sigue los pasos que se indican a continuación para cada organización, excepto para la organización root, que ya se ha tratado.

33.8.1. Requisitos previos

• Acceso necesario para organizaciones de la versión 1

  • Sigue la IAM-R0005:
    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-root en el clúster de administrador raíz.

  • Sigue la recomendación IAM-R0004:

    • Genera el archivo KUBECONFIG del clúster de administrador raíz.

  • Sigue las instrucciones de IAM-R0005:

    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-org-legacy en el clúster de administrador de la organización de destino.

  • Sigue la recomendación IAM-R0004:

    • Genera el archivo KUBECONFIG del clúster de administrador de la organización de destino.

  • Sigue las instrucciones de IAM-R0005:

    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-system-legacy en el clúster del sistema de destino.

  • Sigue la recomendación IAM-R0004:

    • Genera el archivo KUBECONFIG del clúster del sistema de destino.

• Acceso necesario para las organizaciones de la versión 2

  • Sigue la IAM-R0005:
    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-root en el clúster de administrador raíz.
  • Sigue IAM-R0004:
    • Genera el archivo KUBECONFIG del clúster de administrador raíz.
  • Sigue la IAM-R0005:
    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-infra-mp en el clúster de destino.
  • Sigue IAM-R0004:
    • Genera el archivo KUBECONFIG de mp para el clúster de infraestructura de destino.
  • Sigue la IAM-R0005:
    • Obtén el rol de clúster clusterrole/tenable-nessus-admin-infra-cp en el servidor de la API de kube del plano de control de la infraestructura de destino.
  • Sigue IAM-R0004:
    • Genera el archivo KUBECONFIG de cp para el clúster de infraestructura.

Sigue los pasos que se indican en Definir variables de entorno para configurar el acceso a los clústeres de la organización y definir los alias de línea de comandos kna y knu.

33.8.2. Verificar Nessus en el clúster de administrador de la organización en organizaciones de la versión 1 y el servidor de la API de kube del plano de gestión de la infraestructura en organizaciones de la versión 2

1. Verifica que no haya agentes en mal estado:

   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. Para todos los agentes que aparecen en la lista de agentes con mal estado, define la variable NESSUS_AGENT_NAME y ejecuta el siguiente comando para todos:

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

3. Si, transcurridos 20 minutos, los agentes no operativos siguen apareciendo en la lista, haz lo siguiente con cada agente:

   • Consulta los registros del pod install-<node_name> en Grafana y, si hay un registro de errores ansible-playbook error: one or more host failed, establece una conexión SSH con el nodo de hardware desnudo mediante PLATAUTH-G0001.

   • Después de establecer una conexión SSH con el nodo Bare Metal, mueve /etc/yum.repos.d a /etc/ yum.repos.d.back (para eliminar de forma efectiva la configuración de los repositorios de yum).

4. Si, transcurridos 20 minutos, los agentes no aptos siguen apareciendo en la lista, deriva el problema e incluye la siguiente información después de ejecutar la consulta indicada en la interfaz de usuario de Grafana.

   {pod="<pod_name>"}
   

33.8.3. Verificar Nessus en el clúster del sistema en organizaciones de la versión 1 y el servidor de la API de kube del plano de control de la infraestructura en organizaciones de la versión 2

1. Verifica que el Nessus Manager secundario esté en buen estado:

   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 se informa de que el Nessus Manager secundario no está en buen estado, reinícialo con los siguientes comandos, espera 20 minutos y vuelve a comprobar el estado:

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

3. Si, transcurridos 20 minutos, el gestor secundario de Nessus sigue mostrando un estado incorrecto, deriva el problema e incluye la siguiente información después de ejecutar la consulta proporcionada desde la interfaz de usuario de Grafana.

   1. Incluye la siguiente información después de ejecutar la consulta dada desde la interfaz de usuario de Grafana.

      {pod="<pod_name>"}
      

   2. Incluye la configuración de Nessus Manager secundaria.

      knu get cnm -A -o yaml
      

4. Verifica que no haya agentes en mal estado:

   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. En todos los agentes que aparecen en la lista de agentes no operativos, define la variable NESSUS_AGENT_NAME y ejecuta el siguiente comando para todos ellos:

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

6. Si, transcurridos 20 minutos, los agentes no operativos siguen apareciendo en la lista, haz lo siguiente con cada agente:

   • Consulta los registros del pod install-<node_name> en Grafana y, si hay un registro de errores ansible-playbook error: one or more host failed, establece una conexión SSH con el nodo de hardware desnudo mediante PLATAUTH-G0001.

   • Después de establecer una conexión SSH con el nodo Bare Metal, mueve /etc/yum.repos.d a /etc/ yum.repos.d.back (para eliminar de forma efectiva la configuración de los repositorios de yum).

7. Si, transcurridos 20 minutos, los agentes no aptos siguen apareciendo en la lista, deriva el problema e incluye la siguiente información después de ejecutar la consulta dada desde la interfaz de usuario de Grafana.

   1. Incluye la siguiente información después de ejecutar la consulta proporcionada en la interfaz de usuario de Grafana:

      {pod="<pod_name>"}
      

   2. Incluye el estado del agente de Nessus:

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

   3. Incluye la configuración del agente de Nessus:

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

33.9. Instalar Tenable.sc

En esta sección se describen los pasos para instalar o actualizar una máquina virtual de Tenable.sc en la organización de TI de Operations Center.

33.9.1. Requisitos previos

• Se requiere acceso

  • En la versión 1 de la arquitectura de la organización:
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-root en el clúster de administrador raíz.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster de administrador raíz.
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-org-legacy en el clúster de administrador de gdchservices.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster de administrador gdchservices.
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-system-legacy en el clúster del sistema gdchservices.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster del sistema gdchservices.
  • Para la versión 2 de la arquitectura de organización:
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-root en el clúster de administrador raíz.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster de administrador raíz.
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-infra-mp en el clúster gdchservices-management.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster gdchservices-management.
    • Sigue la IAM-R0005:
      • Obtén el rol de clúster clusterrole/tenable-nessus-admin-infra-cp en el clúster gdchservices-infra.
    • Sigue IAM-R0004:
      • Genera el archivo KUBECONFIG del clúster gdchservices-infra.

33.9.2. Establece variables de entorno:

Sigue estos pasos para definir las variables de entorno obligatorias:

1. Define la variable de entorno ROOT_ADMIN_CLUSTER_KUBECONFIG para usarla más adelante en el terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de administrador generado como requisito previo:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Define un alias para el comando kubectl del clúster de administrador raíz en el terminal actual:

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

3. Define la variable de entorno para el archivo kubeconfig del plano de gestión de la organización gdchservices:

   • Para la arquitectura de organización v1: Define la variable de entorno ORG_ADMIN_KUBECONFIG para usarla más adelante en la terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de administración de gdchservices generado como requisito previo:

     ORG_ADMIN_KUBECONFIG=
     

   • Para la arquitectura de organización v2: Define la variable de entorno ORG_MGMT_KUBECONFIG para usarla más adelante en la terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de gestión de gdchservices generado como requisito previo:

     ORG_MGMT_KUBECONFIG=
     

4. Crea un alias para el comando kubectl con el archivo kubeconfig anterior:

   • Para la arquitectura de organización v1: Define un alias para el comando kubectl del clúster de administrador de gdchservices en la terminal actual:

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

   • Para la arquitectura de organización v2: Define un alias para el comando kubectl del clúster de administrador de gdchservices en la terminal actual:

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

5. Define la variable de entorno para el archivo kubeconfig del plano de control de la organización gdchservices:

   • Para la arquitectura de organización v1: Define la variable de entorno ORG_SYSTEM_KUBECONFIG para usarla más adelante en la terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster del sistema gdchservices generado como requisito previo:

     ORG_SYSTEM_KUBECONFIG=
     

   • Para la arquitectura de organización v2: Define la variable de entorno ORG_INFRA_KUBECONFIG para usarla más adelante en la terminal actual. Debe ser una ruta absoluta al archivo kubeconfig del clúster de infraestructura de gdchservices generado como requisito previo:

     ORG_INFRA_KUBECONFIG=
     

6. Crea un alias para el comando kubectl con el archivo kubeconfig anterior:

   • Para la arquitectura de organización v1: Define un alias para el comando kubectl del clúster del sistema gdchservices en la terminal actual:

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

   • Para la arquitectura de organización v2: Define un alias para el comando kubectl del clúster de infraestructura gdchservices en la terminal actual:

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

7. Define la variable USERPROFILE:

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

   $USERPROFILE ahora apunta a la misma ubicación que $env:USERPROFILE.

8. Define el nombre de la organización en la que se ha implementado Tenable.sc:

   ORG=gdchservices
   

33.9.3. Prepararse para la instalación

Sigue los pasos que se indican a continuación para preparar la organización.

1. Crea el proyecto 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. Después de dos minutos, comprueba que los espacios de nombres existen tanto en el clúster del administrador de la organización como en el del sistema.

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

   Ten en cuenta que la etiqueta de proyecto resourcemanager.gdc.goog/attach-all-user-clusters: "true" hace que el espacio de nombres también se cree en todos los clústeres de usuarios de la organización.

3. Genera y guarda las credenciales de usuario de administrador y de gestor de Tenable.sc como un secreto de 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. Gráfico de base instalada

1. Define las siguientes variables de entorno para preparar la instalación:

   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. Aplica el gráfico de Helm de administrador.

   • En el caso de la arquitectura de organización 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:?}
     

   • En la versión 2 de la arquitectura de organización:

     Define OCIT_NESSUS_MANAGER_PREFIXES como una lista separada por comas, como "{dc1-nessus1,dc1-nessus2}", que indica el prefijo de la VM de OCIT.

     Define OCIT_NESSUS_URL_SUFFIX para indicar el sufijo de la VM de OCIT.

     Aplica las actualizaciones de Helm para el plano de gestión:

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

     Aplica las actualizaciones de Helm para el plano de infraestructura:

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

     Aplica la política de autorización de 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
     

     Crea una entrada de servicio:

     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
     

     Crea un registro 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
     

     Almacena el FQDN en una variable de entorno después de esperar cinco minutos:

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

     Aplica un parche al servicio virtual y a la pasarela para añadir el FQDN interno de 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:?}"'"}]'
     

     Aplica un parche al recurso de comprobación para comprobar el endpoint correcto:

     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. Verifica la implementación.

   Revisa el resultado del siguiente comando para confirmar que la implementación de tenablesc-admin se ha realizado correctamente:

   • En el caso de la arquitectura de organización v1:

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

   • En la versión 2 de la arquitectura de organización:

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

4. Verifica que el servicio virtual exista.

   • En el caso de la arquitectura de organización v1:

     kna get virtualservice -n tenablesc-system
     

   • En la versión 2 de la arquitectura de organización:

     knu get virtualservice -n tenablesc-system
     

5. Comprueba que la entrada de DNS exista.

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

6. Verifica que AuditLoggingTarget esté listo, lo que debería tardar varios minutos.

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

   • Puede producirse el siguiente error:

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

     En ese caso, el espacio de nombres tenablesc-system debe crearse en el clúster especificado. Para continuar, crea el espacio de nombres y, a continuación, abre un error meta para investigar por qué se produce este error. Incluye el resultado de tenablesc-system Project describe en la incidencia.

     kna describe project tenablesc-system
     

   • Puede producirse el siguiente error:

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

     Si es así, crea el AuditLoggingTarget que falta manualmente:

     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
     

     Después de cinco minutos, el resultado debería ser similar al siguiente:

     {
         "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, transcurridos 10 minutos, el estado sigue siendo incorrecto, es posible que la plataforma Observabilidad no funcione correctamente. Abre un metabug con la información de estado disponible para ayudar con la depuración.

33.9.5. Gráfico de VMs instaladas

1. Define las siguientes variables de entorno para preparar la instalación:

   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
   

   • En el caso de la arquitectura de organización 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 }')
     

   • En la versión 2 de la arquitectura de organización:

     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. Define el tipo de máquina virtual:

   1. Obtén los nombres de todos los tipos de máquinas virtuales:

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

   2. Selecciona el tipo de máquinas virtuales con el campo Supported como true y guárdalo en una variable de entorno. Preferido: n2-standard-4-gdc y n3-standard-4-gdc.

      VIRTUAL_MACHINE_TYPE=
      

3. Se necesita un ProjectNetworkPolicy para que los registros de Tenable.sc se envíen a la instancia de infra-obs Loki.

   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. Aplica el gráfico de Helm de las VMs.

   • En el caso de la arquitectura de organización 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:?}
     

   • En la versión 2 de la arquitectura de organización:

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

   Al aplicar el gráfico de Helm, pueden producirse los siguientes problemas:

   • Error de 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
     

     Solución: vuelve a ejecutar el comando helm upgrade.

5. Verifica la implementación. Revisa el resultado del siguiente comando para confirmar que la implementación de tenablesc-vm se ha realizado correctamente:

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

6. Espera a que Tenablesc empiece a ejecutarse.

   Comprueba el estado de la máquina virtual:

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

   Ejemplo de resultado que indica que la VM aún se está aprovisionando:

   NAME            STATUS    AGE
   tenablesc-as1   Pending   55s
   

   Ejemplo de resultado que indica que la VM se está ejecutando:

   NAME            STATUS    AGE
   tenablesc-as1   Running   8m25s
   

   Si la VM no se ejecuta después de 60 minutos, revisa los eventos del espacio de nombres para ver si hay errores destacados.

   knu get -n tenablesc-system events -o wide
   

   Recoge las advertencias y los errores más importantes e infórmalos con un metabug.

7. Para acceder a la interfaz de usuario de Tenable.sc, se necesitan un VirtualService y una DestinationRule.

   • Para la versión 1 de la arquitectura de organización: no es necesario hacer ningún cambio.

   • En la versión 2 de la arquitectura de organización:

     • Define el nombre del servicio como una variable de entorno para usarlo más adelante:

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

     • Edita las CR de VirtualService y 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. Verifica que el DNS se resuelva en una 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. Verifica que el servicio se resuelva a través del DNS.

   Nota: Si utilizas instaladores proporcionados por ti mismo, sáltate este paso.

   El resultado esperado es un código de respuesta 200 y un resultado HTML.

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

33.9.6. Preparar las credenciales SSH de la máquina virtual de Tenable.sc

Sigue estos pasos para preparar SSH y acceder a la VM de Tenable.

1. Genera una clave SSH.

   Esta clave SSH solo se usará de forma temporal para acceder a la VM.

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

2. Define las siguientes variables de entorno.

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

3. Crea un VirtualMachineRequest temporal (24 horas).

   VirtualMachineRequest se usa para instalar el certificado SSH generado en 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. Exporta la IP SSH de la VM como una variable de entorno local.

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

5. Prueba que la conexión SSH funcione:

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

   El resultado esperado es alice, que es el nombre de usuario de SSH.

   Si se agota el tiempo de espera de la conexión SSH, significa que falta la política de entrada. Crea la política de entrada con el siguiente comando y vuelve a intentarlo.

6. Crea la política de entrada:

   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. Aprovisiona un pod iotools en el espacio de nombres 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. Transfiere la clave privada al pod iotools:

9. Transfiere la clave privada al pod iotools:

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

33.9.7. Instalar certificados de servicios web

Sigue los pasos que se indican a continuación para instalar los certificados del servicio web de Tenable.sc.

1. Exporta la dirección IP SSH de la VM como variable de entorno 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. Prepara los certificados y las claves del servidor web.

   Los siguientes comandos instalarán los certificados y las claves TLS que se usarán para servir la interfaz de usuario de Tenable.

   1. Definir el nombre del certificado TLS

      TLS_SECRET_NAME=nessus-tls
      

   2. Guarda el certificado nessus-tls de forma local:

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

   3. Copia el certificado nessus-tls en el pod iotools:

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

   4. Prepara el certificado 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. Poner en fase de prueba la clave privada 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. Prepara el certificado de CA TLS.

      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. Prepara la secuencia de comandos de instalación del certificado.

   Guarda el siguiente código en /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. Copia la secuencia de comandos en el pod iotools:

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

5. Instala los certificados y las claves del servidor web.

   Ejecuta install-web-tls.sh en la VM de 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"
   

   El servicio Tenablesc ahora usa los certificados y las claves TLS adecuados.

33.9.8. Habilitar el reenvío de registros en Tenable.sc

1. Sigue las instrucciones de NES-R0002 para iniciar sesión en la interfaz de usuario de Tenable.sc.

2. En la barra de navegación, vaya a Sistema > Configuraciones.

3. En la página Configuraciones, haga clic en Varios.

4. Ve a la sección Syslog:

   1. Activa la opción Habilitar reenvío.
   2. En Facility (Instalación), seleccione user (usuario).
   3. En Gravedad, selecciona Seleccionar todo.

5. Haz clic en Enviar para guardar la configuración.

   33.9.9. Habilitar la conectividad de red de OIC a GDC

Sigue estos pasos para las VMs nessus1 y nessus2:

1. Define las siguientes variables de entorno:

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

2. Publica las configuraciones en el plano de gestión de servicios de 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. Publica las configuraciones en el plano de control de 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. Limpieza

Elimina el directorio temporal de Nessus.

rm -rf /tmp/nessus

33.9.11. Activación de licencias

En esta sección se explica cómo aplicar la licencia de Tenable.sc.

1. Abre la interfaz web de Tenable.sc con la siguiente 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. Antes de que se aplique la licencia, la interfaz de usuario muestra el asistente de configuración.

   Si la interfaz de usuario muestra una petición de inicio de sesión, significa que la licencia ya se ha aplicado y que debes saltarte los pasos restantes de esta sección.

3. Haz clic en Siguiente.

4. Sube el archivo de licencia de Tenablesc SecurityCenter-<version>-<number>IPs-<uid>.key.

   Posibles problemas:

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

     Este error indica que el archivo de licencia proporcionado no es válido. Revisa las siguientes posibles causas:

     1. Nombre de host incorrecto

        El nombre de host incorrecto se ha definido en la página de producto de Tenable.com para esta licencia. Comprueba que el nombre de host de la licencia en la página del producto de Tenable.com sea tenablesc-as1. Si el nombre de host no coincide, defínelo como tenablesc-as1, descarga la nueva licencia y usa el nuevo archivo de licencia.

     2. Archivo con formato incorrecto

        Es posible que el archivo de licencia se haya modificado durante la transferencia: al igual que el archivo de preactivación de Nessus, este archivo de licencia no se puede modificar durante la transferencia. El archivo exacto descargado de la página de producto de Tenable.com se debe subir a la interfaz de usuario de Tenable. Puedes comprobar si el archivo se ha modificado comparando el SHA del archivo antes y después de la transferencia.

     3. Archivo de licencia incorrecto

        Asegúrese de que está utilizando un archivo de licencia Tenable.sc obtenido de la página de productos de Tenable.com. El contenido del archivo debe ser similar a una clave PEM.

     Si la licencia sigue sin funcionar, abre un metabug con el equipo de VULN e incluye todos los pasos para solucionar problemas que hayas probado hasta el momento.

5. Actualiza la página. Si se muestra una pantalla de inicio de sesión, significa que la licencia se ha aplicado correctamente.

Tenablesc ya está totalmente inicializado. En el manual del operador se indican los pasos adicionales para configurar y usar Tenable.sc, que se deben completar más adelante, después del arranque.

33.9.12. Opcional: desinstalar

En esta sección se incluyen los comandos para eliminar la implementación de Tenable.sc.

Advertencia: Si desinstalas los gráficos de Helm de Tenable.sc, se eliminarán todos los volúmenes persistentes y los datos de la aplicación.

Sigue estos pasos para desinstalar los gráficos de Helm de los clústeres:

1. Desinstala el gráfico de Helm del clúster de infraestructura de la organización:

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

2. Desinstala el gráfico de Helm del servidor de la API de gestión:

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

3. Desinstala el gráfico de Helm de la máquina virtual de Tenable SC del servidor de la API de gestión:

   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. Configuración de Tenable.sc

Sigue las instrucciones de NES-G0001 - Configurar Tenable.SC para configurar Tenable.sc.

33.10. Validar la implementación de Nessus

En esta sección se detallan los pasos para validar que los gestores y agentes de Nessus se ejecutan y se vinculan entre sí según lo previsto, así como los pasos para solucionar posibles problemas conocidos.

Esta sección se debe ejecutar al final de la instalación, pero también se recomienda seguir estos pasos de validación antes de realizar análisis. Los pasos para realizar análisis se describen en el manual del operador.

Antes de empezar, sigue los pasos de Definir variables de entorno para configurar el acceso al clúster de administrador raíz y definir el alias de línea de comandos kra.

33.10.1. Validar la agrupación en clústeres

La forma principal de validar que los Nessus Managers y los agentes están vinculados es a través de la interfaz de usuario del Nessus Manager principal. En la interfaz de usuario, los elementos secundarios de Nessus deben aparecer en el grupo de clúster predeterminado de la agrupación en clúster de agentes, y todos los agentes de Nessus deben aparecer en el grupo de agentes predeterminado.

Nota: El vínculo entre el Nessus Manager principal y todos los secundarios se rompe si se reinicia el Nessus Manager principal después de la instalación inicial. Esto puede ocurrir como consecuencia natural del despliegue en Kubernetes.

1. Obtén el DNS de la interfaz de usuario principal de Nessus Manager:

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

2. Abre un navegador de Internet y ve al enlace de los pasos anteriores. Se te dirigirá a la interfaz de usuario principal de Nessus Manager.

3. Inicia sesión en la interfaz de usuario de Nessus Manager con el nombre de usuario admin y la contraseña predeterminada admin.

   Si tienes problemas de autenticación al iniciar sesión, sigue las instrucciones del artículo NES-T0004 para cambiar las credenciales de Nessus y vuelve a intentar iniciar sesión.

4. En la parte superior de la página, haz clic en Configuración.

   En la página Configuración, consulta la información de Plugins. Si no se define el valor de Plugin Set, siga las instrucciones de NES-T0001 para volver a aplicar el conjunto de plugins más reciente al Nessus Manager principal.

5. En la parte superior de la página, haz clic en Sensores y, a continuación, en Agrupación de agentes.

6. Haz clic en Grupo de agentes predeterminado para ver todos los nodos registrados.

   Si el grupo está vacío o falta el nodo (instancia secundaria de Nessus) de alguna organización, la instancia secundaria de Nessus debe volver a registrarse.

Nota: Puede haber casos en los que los agentes de Nessus de una organización se vinculen a un Nessus Manager secundario de otra organización debido a la distribución de un nodo principal a los nodos secundarios a los que pueden acceder los agentes.