33. Implantar componentes do Nessus

Tempo estimado para a conclusão: 1 dia

Proprietário do componente operacional: VULN

Perfil de habilidade: engenheiro de implantação

Última atualização: 18 de agosto de 2025

O Nessus é um scanner de segurança para os sistemas de suporte e operação do Google Distributed Cloud (GDC) com isolamento físico. Ela ajuda a equipe do centro de operações a monitorar e responder a vulnerabilidades de segurança em hardware e software.

Este documento apresenta as etapas para implantar o Nessus e pressupõe que o operador que o segue está executando etapas de uma estação de trabalho do OC com o PowerShell e o WSL disponíveis.

33.1. Antes de começar

• É necessário ter acesso

  • Siga IAM-R0005:
    • Receba a função de cluster clusterrole/tenable-nessus-admin-root no cluster de administrador raiz.
    • Receba a função role/system-artifact-management-admin no namespace gpc-system do cluster de administrador raiz.

• Ferramentas necessárias

  • kubectl
  • gdcloud
  • helm
  • yq
  • docker

• Licenciamento

  • Uma licença do Nessus
    • Siga NES-G0004: Como fazer a pré-ativação da licença do Nessus para preparar o pacote de pré-ativação "GDCH 1".

Observação: gdcloud pode não ser resolvido por padrão. Caso contrário, adicione PATH=/root/release:${PATH:?} ao caminho e tente de novo.

33.1.1. Práticas recomendadas

33.1.1.1. Upgrades

Para upgrades de versões anteriores à 1.14, siga a seção "Opcional: desinstalar" de cada seção principal deste guia antes de realizar qualquer instalação.

Em caso de reinstalações, siga a parte "Opcional: desinstalar" de cada seção principal deste guia.

33.1.1.2. Como lidar com a deriva de versão entre organizações e zonas

Não deve haver problemas devido à variação de versão entre organizações e zonas. Siga as etapas específicas da organização considerando a versão dela. Cada implantação será independente por zona.

33.1.2. Licença do Tenablesc

O Tenablesc é um software licenciado de terceiros que exige um arquivo de licença para operar. É necessário adquirir uma licença da Tenable de acordo com a lista de materiais de software antes de continuar. Em casos especiais, talvez seja possível fornecer uma licença.

O arquivo de licença precisa ter um nome como SecurityCenter-<version>-1000IPs-<uid>.key. Localize esse arquivo e anote-o para mais tarde, já que ele precisará ser enviado diretamente para a UI do Tenable.sc.

Requisitos:

• Um arquivo de licença do Tenable.sc com limite de pelo menos 1.000 IPs e nome do host tenablesc-as1

33.2. Localizar arquivos de implantação do Nessus

Antes de implantar o Nessus, siga estas etapas usando o Windows PowerShell para localizar os arquivos de instalação do Nessus:

1. Acesse os gráficos do Helm e a imagem da máquina virtual (VM) do Nessus:

   No OC, eles podem ser acessados em \\<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. Mova estes arquivos para sua estação de trabalho local para uso posterior:

   # 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 o pacote de pré-ativação do Nessus

Importante: esta etapa não é necessária para upgrades.

O pacote de pré-ativação do Nessus é específico para cada instalação do Nessus e, portanto, não pode ser incluído no pacote da central de operações. Siga o guia do Nessus NES-G0004: como realizar a pré-ativação da licença do Nessus (em inglês) para preparar o pacote de pré-ativação "GDCH 1" antes de continuar.

1. Em uma máquina conectada à Internet, obtenha nessus-preact-gdch1.tar.gz por conta própria ou com um POC de engenharia do Google.

2. Transfira esse arquivo para sua estação de trabalho e coloque-o em $env:USERPROFILE\tenable-nessus.

3. O diretório $env:USERPROFILE\tenable-nessus precisa conter o pacote de pré-ativação:

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

33.4. Abrir o WSL

As etapas restantes na página exigem o WSL para todos os comandos, a menos que indicado de outra forma.

1. Opcional: o sudo é obrigatório. Se você não souber a senha do usuário sudo, execute o comando a seguir para definir a senha do usuário sudo oc-it do WSL:

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

33.5. Defina as variáveis de ambiente

Siga as etapas abaixo para definir as variáveis de ambiente necessárias:

1. Defina a variável de ambiente ROOT_ADMIN_CLUSTER_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de administrador gerado como pré-requisito:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Defina um alias para o comando kubectl do cluster de administrador selecionado no terminal atual:

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

3. Defina a variável USERPROFILE.

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

   Agora, $USERPROFILE aponta para o mesmo local que $env:USERPROFILE.

33.5.1. Definir variáveis de ambiente para a organização v1

1. Defina a variável de ambiente ORG_ADMIN_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de administrador da organização selecionado, gerado como pré-requisito:

   ORG_ADMIN_KUBECONFIG=
   

2. Defina um alias para o comando kubectl do cluster de administrador da organização selecionado no terminal atual:

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

3. Defina a variável de ambiente ORG_SYSTEM_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster do sistema selecionado, gerado como pré-requisito:

   ORG_SYSTEM_KUBECONFIG=
   

4. Defina um alias para o comando kubectl do cluster do sistema selecionado no terminal atual:

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

33.5.2. Definir variáveis de ambiente para a organização v2

1. Defina a variável de ambiente ORG_MGMT_KUBECONFIG para uso posterior no terminal atual. Esse precisa ser um caminho absoluto para o kubeconfig do servidor da API do plano de gerenciamento da organização v2 selecionada, gerado como pré-requisito:

   ORG_MGMT_KUBECONFIG=
   

2. Defina um alias para o comando kubectl do cluster de administrador da organização selecionado no terminal atual:

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

3. Defina a variável de ambiente ORG_INFRA_KUBECONFIG para uso posterior no terminal atual. Esse precisa ser um caminho absoluto para o kubeconfig do servidor da API do plano de controle da organização v2 selecionada, gerado como pré-requisito:

   ORG_INFRA_KUBECONFIG=
   

4. Defina um alias para o comando kubectl do cluster do sistema selecionado no terminal atual:

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

33.6. Fazer upload do pacote de pré-ativação

Importante: esta etapa não é necessária para upgrades.

Siga as etapas abaixo para fazer upload do registro de artefatos do Harbor.

1. Converta o pacote para o formato OCI com os metadados adequados:

   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. Instale o certificado da CA do 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"
   

   Encontre o sistema operacional:

   sudo sh -c "hostnamectl"
   

   Para o Rocky Linux como sistema operacional, execute:

   sudo update-ca-trust extract
   

   Para o Ubuntu como sistema operacional, execute:

   sudo update-ca-certificates
   

3. Faça upload do pacote de pré-ativação para o Harbor:

   • Método ideal: autentique usando 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 backup: usando 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 o Nessus

Aviso: para upgrades de versões anteriores à 1.14, siga a seção "Opcional: desinstalar" antes de prosseguir com a instalação.

1. Acione a instalação do 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. Aguarde cerca de 1 hora e meia para que a instalação seja concluída.

33.7.1. Opcional: desinstalar o Nessus

Esta seção contém os comandos para remover a implantação do Nessus de todos os clusters necessários.

Aviso: desinstale a implantação do Nessus atual apenas se você estiver fazendo uma reinstalação ou um upgrade. Caso contrário, pule esta seção.

1. Desinstale o Nessus do cluster de administrador raiz:

   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. Para a arquitetura da organização v1:

   1. Desinstale o Nessus do cluster de administrador da organização:

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

   2. Desinstale o Nessus do cluster do sistema da organização:

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

3. Para a arquitetura da organização v2:

   1. Desinstale o Nessus do cluster de gerenciamento da organização:

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

   2. Desinstale o Nessus do cluster de infraestrutura da organização:

      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 o Nessus no cluster de administrador raiz

1. Verifique se as chaves e os certificados foram publicados:

   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. Verifique se o Nessus Manager principal está em um estado íntegro:

   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. Se o Nessus Manager principal for considerado não íntegro, como a saída de qualquer um dos comandos anteriores for "false", reinicie o Nessus Manager principal com os seguintes comandos:

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

4. Aguarde cerca de 1 hora e meia e verifique o status novamente.

5. Se o Nessus Manager principal ainda estiver sendo relatado como não íntegro após 1 hora e meia, encaminhe o problema para o plantão.

   1. Inclua as seguintes informações depois de executar a consulta na interface do Grafana:

      {pod="<pod_name>"}
      

   2. Inclua a configuração principal do Nessus Manager:

      kra get pnm -A -o yaml
      

6. Verifique se o Nessus Manager secundário está em um estado íntegro:

   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. Se o Nessus Manager filho for considerado não íntegro, reinicie-o com os seguintes comandos, aguarde 20 minutos e verifique o status novamente:

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

8. Se após 20 minutos o gerenciador do Nessus infantil ainda estiver com status "Não íntegro", encaminhe o problema e inclua as seguintes informações depois de executar a consulta fornecida na interface do Grafana.

   1. Inclua as seguintes informações depois de executar a consulta na interface do Grafana:

      {pod="<pod_name>"}
      

   2. Inclua a configuração do Nessus Manager secundário:

      kra get cnm -A -o yaml
      

9. Verifique se não há agentes não íntegros:

   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. Para todos os agentes listados na lista de não íntegros, defina a variável NESSUS_AGENT_NAME e execute o seguinte comando para todos:

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

11. Se após 20 minutos os agentes não íntegros ainda estiverem listados, faça o seguinte para cada um deles:

    • Verifique os registros do pod install-<node_name> no Grafana. Se houver um registro de erro ansible-playbook error: one or more host failed, estabeleça uma conexão SSH com o nó bare metal usando PLATAUTH-G0001.

    • Depois de estabelecer uma conexão SSH com o nó bare metal, mova /etc/yum.repos.d para /etc/ yum.repos.d.back (para excluir efetivamente o yum repos conf).

12. Se, após 20 minutos, os agentes não íntegros ainda forem mostrados na lista, encaminhe o problema e inclua as seguintes informações depois de executar a consulta na interface do Grafana.

    1. Inclua as seguintes informações depois de executar a consulta na interface do Grafana.

       {pod="<pod_name>"}
       

    2. Inclua o status do agente do Nessus:

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

    3. Inclua a configuração do agente do Nessus:

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

33.8. Nessus Manager: verificação da organização

Esta seção aborda as etapas necessárias para verificar o Nessus em uma organização do Distributed Cloud.

Para garantir uma verificação do Nessus bem-sucedida e completa, execute esse procedimento para cada cluster de organização da Distributed Cloud, incluindo o cluster de organização de TI do Operations Center.

Liste as organizações disponíveis:

kra get -n gpc-system organization

Siga as etapas abaixo para cada organização, exceto a root, que já foi abordada.

33.8.1. Pré-requisitos

• Acesso necessário para organizações da v1

  • Siga IAM-R0005:
    • Receba a função de cluster clusterrole/tenable-nessus-admin-root no cluster de administrador raiz.

  • Siga IAM-R0004:

    • Gere o KUBECONFIG para o cluster de administrador raiz.

  • Siga IAM-R0005:

    • Receba a função de cluster clusterrole/tenable-nessus-admin-org-legacy no cluster de administrador da organização de destino.

  • Siga IAM-R0004:

    • Gere o KUBECONFIG para o cluster de administrador da organização de destino.

  • Siga IAM-R0005:

    • Consiga a função de cluster clusterrole/tenable-nessus-admin-system-legacy no cluster do sistema de destino.

  • Siga IAM-R0004:

    • Gere o KUBECONFIG para o cluster do sistema de destino.

• Acesso necessário para organizações da v2

  • Siga IAM-R0005:
    • Receba a função de cluster clusterrole/tenable-nessus-admin-root no cluster de administrador raiz.
  • Siga IAM-R0004:
    • Gere o KUBECONFIG para o cluster de administrador raiz.
  • Siga IAM-R0005:
    • Consiga a função de cluster clusterrole/tenable-nessus-admin-infra-mp no cluster de destino.
  • Siga IAM-R0004:
    • Gere o KUBECONFIG do mp para o cluster de infraestrutura de destino.
  • Siga IAM-R0005:
    • Receba a função de cluster clusterrole/tenable-nessus-admin-infra-cp no servidor da API kube do plano de controle de infraestrutura de destino.
  • Siga IAM-R0004:
    • Gere o KUBECONFIG cp para o cluster de infraestrutura.

Siga as instruções em Definir variáveis de ambiente para configurar o acesso aos clusters da organização e definir os aliases de linha de comando kna e knu.

33.8.2. Verificar o Nessus no cluster de administrador da organização em organizações v1 e o servidor da API kube do plano de gerenciamento de infraestrutura em organizações v2

1. Verifique se não há agentes não íntegros:

   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 os agentes listados na lista de não íntegros, defina a variável NESSUS_AGENT_NAME e execute o seguinte comando para todos:

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

3. Se após 20 minutos os agentes não íntegros ainda estiverem listados, faça o seguinte para cada um deles:

   • Verifique os registros do pod install-<node_name> no Grafana. Se houver um registro de erro ansible-playbook error: one or more host failed, estabeleça uma conexão SSH com o nó bare metal usando PLATAUTH-G0001.

   • Depois de estabelecer uma conexão SSH com o nó bare metal, mova /etc/yum.repos.d para /etc/ yum.repos.d.back (para excluir efetivamente o yum repos conf).

4. Se após 20 minutos os agentes não íntegros ainda forem informados na lista, encaminhe o problema e inclua as seguintes informações depois de executar a consulta fornecida na interface do Grafana.

   {pod="<pod_name>"}
   

33.8.3. Verificar o Nessus no cluster do sistema em organizações v1 e o servidor da API kube do plano de controle de infraestrutura em organizações v2

1. Verifique se o Nessus Manager secundário está em um estado íntegro:

   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. Se o Nessus Manager filho for considerado não íntegro, reinicie-o com os seguintes comandos, aguarde 20 minutos e verifique o status novamente:

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

3. Se após 20 minutos o gerenciador do Nessus infantil ainda estiver com status "Não íntegro", encaminhe o problema e inclua as seguintes informações depois de executar a consulta fornecida na interface do Grafana.

   1. Inclua as seguintes informações depois de executar a consulta na interface do Grafana.

      {pod="<pod_name>"}
      

   2. Inclua a configuração do Nessus Manager secundário.

      knu get cnm -A -o yaml
      

4. Verifique se não há agentes não íntegros:

   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. Para todos os agentes listados na lista de não íntegros, defina a variável NESSUS_AGENT_NAME e execute o seguinte comando para todos:

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

6. Se após 20 minutos os agentes não íntegros ainda estiverem listados, faça o seguinte para cada um deles:

   • Verifique os registros do pod install-<node_name> no Grafana. Se houver um registro de erro ansible-playbook error: one or more host failed, estabeleça uma conexão SSH com o nó bare metal usando PLATAUTH-G0001.

   • Depois de estabelecer uma conexão SSH com o nó bare metal, mova /etc/yum.repos.d para /etc/ yum.repos.d.back (para excluir efetivamente o yum repos conf).

7. Se, após 20 minutos, os agentes não íntegros ainda forem mostrados na lista, encaminhe o problema e inclua as seguintes informações depois de executar a consulta na interface do Grafana.

   1. Inclua as seguintes informações depois de executar a consulta na interface do Grafana:

      {pod="<pod_name>"}
      

   2. Inclua o status do agente do Nessus:

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

   3. Inclua a configuração do agente do Nessus:

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

33.9. Instalar o Tenable.sc

Esta seção contém etapas para instalar ou fazer upgrade de uma VM do Tenable.sc na organização de TI do Operations Center.

33.9.1. Pré-requisitos

• É necessário ter acesso

  • Para a arquitetura da organização v1:
    • Siga IAM-R0005:
      • Receba a função de cluster clusterrole/tenable-nessus-admin-root no cluster de administrador raiz.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster de administrador raiz.
    • Siga IAM-R0005:
      • Receba a função de cluster clusterrole/tenable-nessus-admin-org-legacy no cluster de administrador do gdchservices.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster de administrador do gdchservices.
    • Siga IAM-R0005:
      • Acesse a função de cluster clusterrole/tenable-nessus-admin-system-legacy no cluster do sistema gdchservices.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster do sistema gdchservices.
  • Para a arquitetura da organização v2:
    • Siga IAM-R0005:
      • Receba a função de cluster clusterrole/tenable-nessus-admin-root no cluster de administrador raiz.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster de administrador raiz.
    • Siga IAM-R0005:
      • Receba a função de cluster clusterrole/tenable-nessus-admin-infra-mp no cluster gdchservices-management.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster gdchservices-management.
    • Siga IAM-R0005:
      • Receba o papel de cluster clusterrole/tenable-nessus-admin-infra-cp no cluster gdchservices-infra.
    • Siga IAM-R0004:
      • Gere o KUBECONFIG para o cluster gdchservices-infra.

33.9.2. Defina as variáveis de ambiente

Siga as etapas abaixo para definir as variáveis de ambiente necessárias:

1. Defina a variável de ambiente ROOT_ADMIN_CLUSTER_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de administrador gerado como pré-requisito:

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. Defina um alias para o comando kubectl do cluster de administrador raiz no terminal atual:

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

3. Defina a variável de ambiente para o kubeconfig do plano de gerenciamento da organização gdchservices:

   • Para a arquitetura da organização v1:defina a variável de ambiente ORG_ADMIN_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de administrador do gdchservices gerado como pré-requisito:

     ORG_ADMIN_KUBECONFIG=
     

   • Para a arquitetura da organização v2:defina a variável de ambiente ORG_MGMT_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de gerenciamento do gdchservices gerado como pré-requisito:

     ORG_MGMT_KUBECONFIG=
     

4. Crie um alias para o comando kubectl usando o kubeconfig acima:

   • Para a arquitetura da organização v1:defina um alias para o comando kubectl do cluster de administrador gdchservices no terminal atual:

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

   • Para a arquitetura da organização v2:Defina um alias para o comando kubectl do cluster de administrador do gdchservices no terminal atual:

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

5. Defina a variável de ambiente para o kubeconfig do plano de controle da organização gdchservices:

   • Para a arquitetura da organização v1:defina a variável de ambiente ORG_SYSTEM_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster do sistema gdchservices gerado como pré-requisito:

     ORG_SYSTEM_KUBECONFIG=
     

   • Para a arquitetura da organização v2:defina a variável de ambiente ORG_INFRA_KUBECONFIG para uso posterior no terminal atual. Precisa ser um caminho absoluto para o kubeconfig do cluster de infraestrutura gdchservices gerado como pré-requisito:

     ORG_INFRA_KUBECONFIG=
     

6. Crie um alias para o comando kubectl usando o kubeconfig acima:

   • Para a arquitetura da organização v1:defina um alias para o comando kubectl do cluster do sistema gdchservices no terminal atual:

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

   • Para a arquitetura da organização v2:Defina um alias para o comando kubectl do cluster de infraestrutura gdchservices no terminal atual:

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

7. Defina a variável USERPROFILE.

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

   Agora, $USERPROFILE aponta para o mesmo local que $env:USERPROFILE.

8. Defina o nome da organização em que o Tenable.sc está implantado:

   ORG=gdchservices
   

33.9.3. Preparar para a instalação

Siga as etapas abaixo para preparar a organização.

1. Crie o projeto 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. Após dois minutos, verifique se os namespaces existem nos clusters de administrador da organização e do sistema.

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

   A label do projeto resourcemanager.gdc.goog/attach-all-user-clusters: "true" faz com que o namespace também seja criado em todos os clusters de usuário da organização.

3. Gere e salve a credencial de usuário administrador e gerente do Tenable.sc como um secret do 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. Instalar gráfico de administrador

1. Defina as seguintes variáveis de ambiente para se preparar para a instalação:

   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. Aplique o gráfico do Helm de administrador.

   • Para a arquitetura da organização 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:?}
     

   • Para a arquitetura da organização v2:

     Defina OCIT_NESSUS_MANAGER_PREFIXES como uma lista separada por vírgulas, como "{dc1-nessus1,dc1-nessus2}", indicando o prefixo da VM do OCIT.

     Defina OCIT_NESSUS_URL_SUFFIX indicando o sufixo da VM do OCIT.

     Aplique atualizações do Helm para o plano de gerenciamento:

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

     Aplique atualizações do Helm para o plano de infraestrutura:

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

     Aplique a política de autorização do 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
     

     Crie a entrada de serviço:

     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
     

     Crie um registro de 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
     

     Armazene o FQDN em uma variável de ambiente após aguardar cinco minutos:

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

     Corrija o serviço virtual e o gateway para adicionar o FQDN interno do 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:?}"'"}]'
     

     Adicione um patch ao recurso de sondagem para sondar o endpoint correto:

     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. Verifique a implantação.

   Analise a saída do seguinte comando para confirmar se a implantação do tenablesc-admin foi bem-sucedida:

   • Para a arquitetura da organização v1:

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

   • Para a arquitetura da organização v2:

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

4. Verifique se o serviço virtual existe.

   • Para a arquitetura da organização v1:

     kna get virtualservice -n tenablesc-system
     

   • Para a arquitetura da organização v2:

     knu get virtualservice -n tenablesc-system
     

5. Verifique se a entrada DNS existe.

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

6. Verifique se o AuditLoggingTarget está pronto. Isso deve levar alguns minutos.

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

   • O seguinte erro pode ocorrer:

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

     Se for o caso, o namespace tenablesc-system precisa ser criado no cluster especificado. Para continuar, crie o namespace e abra um metabug para iniciar uma investigação sobre o motivo desse erro. Inclua a saída de descrição do projeto tenablesc-system no tíquete.

     kna describe project tenablesc-system
     

   • O seguinte erro pode ocorrer:

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

     Se for o caso, crie o AuditLoggingTarget ausente 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
     

     Após cinco minutos, a saída será semelhante a esta:

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

     Se, após 10 minutos, a saída de status ainda parecer incorreta, a plataforma de observabilidade poderá estar com problemas. Abra um metabug com as informações de status disponíveis para ajudar na depuração.

33.9.5. Gráfico de VMs instaladas

1. Defina as seguintes variáveis de ambiente para se preparar para a instalação:

   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
   

   • Para a arquitetura da organização 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 }')
     

   • Para a arquitetura da organização 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. Defina o tipo de máquina virtual:

   1. Receba os nomes de todos os tipos de máquinas virtuais:

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

   2. Selecione o tipo de máquinas virtuais com o campo Supported como true e armazene-o em uma variável de ambiente. Preferencial: n2-standard-4-gdc e n3-standard-4-gdc.

      VIRTUAL_MACHINE_TYPE=
      

3. Um ProjectNetworkPolicy é necessário para que os registros do Tenable.sc sejam entregues à instância do 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. Aplique o gráfico do Helm das VMs.

   • Para a arquitetura da organização 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:?}
     

   • Para a arquitetura da organização 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:?}
     

   Ao aplicar o gráfico do Helm, você pode encontrar os seguintes problemas:

   • Falha no 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
     

     Correção: execute o comando "helm upgrade" novamente.

5. Verifique a implantação. Analise a saída do seguinte comando para confirmar se a implantação do tenablesc-vm foi bem-sucedida:

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

6. Aguarde o início da execução do Tenable.sc.

   Verifique o status da máquina virtual:

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

   Exemplo de saída indicando que a VM ainda está sendo provisionada:

   NAME            STATUS    AGE
   tenablesc-as1   Pending   55s
   

   Exemplo de saída indicando que a VM está em execução:

   NAME            STATUS    AGE
   tenablesc-as1   Running   8m25s
   

   Se a VM não estiver em execução após 60 minutos, analise os eventos do namespace para identificar erros.

   knu get -n tenablesc-system events -o wide
   

   Reúna todos os avisos e erros importantes e relate-os com um metabug.

7. Um VirtualService e um DestinationRule são necessários para acessar a UI do Tenable.sc.

   • Para a arquitetura da organização v1:Nenhuma mudança é necessária.

   • Para a arquitetura da organização v2:

     • Defina o nome do serviço como uma variável de ambiente para uso posterior:

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

     • Edite os CRs VirtualService e 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. Verifique se o DNS resolve para um 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. Verifique se o serviço é resolvido pelo DNS.

   Observação: se você estiver usando instaladores fornecidos por você mesmo, pule esta etapa.

   O resultado esperado é um código de resposta 200 e alguma saída HTML.

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

33.9.6. Preparar as credenciais SSH da VM do Tenable.sc

Siga as etapas abaixo para preparar o SSH e acessar a VM do Tenable.

1. Gere uma chave SSH.

   Essa chave SSH será usada apenas temporariamente para acessar a VM.

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

2. Defina as seguintes variáveis de ambiente.

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

3. Crie um VirtualMachineRequest temporário (24 horas).

   VirtualMachineRequest é usado para instalar o certificado SSH gerado na 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. Exporte o IP SSH da VM como uma variável de ambiente local.

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

5. Teste se a conexão SSH está funcionando:

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

   A saída esperada é alice, que é o nome de usuário do SSH.

   Se a conexão SSH estiver atingindo o tempo limite, a política de entrada estará faltando. Crie a política de entrada com o comando a seguir e tente de novo.

6. Crie a 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. Provisione um pod iotools no namespace 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. Transfira a chave privada para o pod iotools:

9. Transfira a chave privada para o pod iotools:

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

33.9.7. Instalar certificados de serviço da Web

Siga as etapas abaixo para instalar os certificados do serviço da Web do TenableSC.

1. Exporte o endereço IP SSH da VM como uma variável de ambiente 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. Prepare os certificados e as chaves do servidor da Web.

   Os comandos a seguir vão instalar certificados e chaves TLS que serão usados para veicular a interface do Tenable.

   1. Definir o nome do certificado TLS

      TLS_SECRET_NAME=nessus-tls
      

   2. Salve o certificado nessus-tls localmente:

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

   3. Copie o certificado nessus-tls para o pod iotools:

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

   4. Faça o staging do 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. Prepare a chave 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. Prepare o certificado da 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. Prepare o script de instalação do certificado.

   Salve o código a seguir em /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. Copie o script para o pod iotools:

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

5. Instale os certificados e as chaves do servidor da Web.

   Execute install-web-tls.sh na VM do 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"
   

   O serviço Tenablesc agora usa os certificados e chaves TLS adequados.

33.9.8. Ativar o encaminhamento de registros no Tenable.sc

1. Siga NES-R0002 para fazer login na interface do Tenablesc.

2. Na barra de navegação, acesse Sistema > Configurações.

3. Na página Configurações, clique em Diversos.

4. Acesse a seção Syslog:

   1. Ative a opção Ativar encaminhamento.
   2. Defina a Facilidade como usuário.
   3. Em Gravidade, selecione Selecionar tudo.

5. Clique em Enviar para salvar a configuração.

   33.9.9. Ativar a conectividade de rede do OIC com o GDC

Conclua as etapas a seguir para as VMs nessus1 e nessus2:

1. Configure as seguintes variáveis de ambiente:

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

2. Publique as configurações no plano de gerenciamento de serviços do 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. Publique as configurações no plano de controle do 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. Limpar

Exclua o diretório temporário do Nessus.

rm -rf /tmp/nessus

33.9.11. Ativação de licença

Esta seção fornece detalhes sobre como aplicar a licença do Tenable.sc.

1. Abra a UI da Web do Tenablesc usando o seguinte 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 da aplicação da licença, a UI mostra o assistente de configuração.

   Se a UI estiver mostrando uma solicitação de login, a licença já foi aplicada e as etapas restantes nesta seção devem ser ignoradas.

3. Clique em Próxima.

4. Faça upload do arquivo de licença do Tenable.sc SecurityCenter-<version>-<number>IPs-<uid>.key.

   Possíveis problemas:

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

     Esse erro significa que o arquivo de licença fornecido é inválido. Confira as possíveis causas:

     1. Nome do host incorreto

        O nome de host incorreto está definido na página do produto Tenabe.com para essa licença. Verifique se o nome do host da licença na página do produto Tenable.com é tenablesc-as1. Se o nome do host não corresponder, defina como tenablesc-as1, faça o download da nova licença e use o novo arquivo de licença.

     2. Arquivo malformado

        O arquivo de licença pode ter sido modificado durante a transferência: assim como o arquivo de pré-ativação do Nessus, esse arquivo de licença não pode ser modificado em trânsito. O arquivo exato baixado da página do produto em Tenable.com precisa ser enviado por upload para a interface do Tenable. Para verificar se o arquivo foi modificado, compare o SHA antes e depois da transferência.

     3. Arquivo de licença incorreto

        Verifique se você está usando um arquivo de licença Tenable.sc obtido na página do produto em Tenable.com. O conteúdo do arquivo precisa ser semelhante a uma chave PEM.

     Se a licença ainda não estiver funcionando, abra um metabug com a equipe de VULN e inclua todas as etapas de solução de problemas tentadas até agora.

5. Atualize a página. Se uma tela de login aparecer, a licença foi aplicada.

O Tenablesc agora está totalmente inicializado. Outras etapas para configurar e usar o Tenable.sc estão disponíveis no manual do operador, que devem ser concluídas mais tarde, após a inicialização.

33.9.12. Opcional: desinstalar

Esta seção contém os comandos para remover a implantação do Tenable.sc.

Aviso:a desinstalação dos gráficos do Helm do Tenable.sc remove todos os volumes permanentes e exclui os dados do aplicativo.

Siga as etapas abaixo para desinstalar os gráficos do Helm dos clusters:

1. Desinstale o gráfico do Helm do cluster de infraestrutura da organização:

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

2. Desinstale o gráfico do Helm do servidor da API de gerenciamento:

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

3. Desinstale o gráfico do Helm para a VM do Tenable SC no servidor da API de gerenciamento:

   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. Configuração do Tenable.SC

Siga NES-G0001: configurar o Tenable.SC.

33.10. Validar a implantação do Nessus

Nesta seção, detalhamos as etapas para validar se os gerentes e agentes do Nessus estão em execução e vinculados conforme o esperado, além de fornecer etapas para corrigir possíveis problemas conhecidos.

Esta seção deve ser executada no final da instalação, mas também é recomendável seguir essas etapas de validação antes de realizar verificações. As etapas para realizar verificações estão descritas no manual do operador.

Antes de começar, siga as etapas em Definir variáveis de ambiente para configurar o acesso ao cluster de administrador raiz e definir o alias de linha de comando kra.

33.10.1. Validar o clustering

A principal maneira de validar se os Nessus Managers e agentes estão vinculados é pela UI do Nessus Manager principal. Na UI, os filhos do Nessus precisam estar listados no grupo de cluster padrão do agrupamento de agentes, e todos os agentes do Nessus precisam estar listados no grupo de agentes padrão.

Observação: o link entre o Nessus Manager principal e todos os filhos é interrompido se o Nessus Manager principal for reinicializado após a instalação inicial. Isso pode acontecer como uma consequência natural da implantação no Kubernetes.

1. Obtenha o DNS da interface principal do Nessus Manager:

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

2. Abra um navegador da Internet e acesse o link das etapas anteriores. Isso leva você à interface principal do Nessus Manager.

3. Faça login na interface do Nessus Manager com o nome de usuário admin e a senha padrão admin.

   Em caso de problemas de autenticação ao fazer login, siga NES-T0004 para girar as credenciais do Nessus e tente fazer login novamente.

4. Clique em Configurações na parte de cima da página.

   Na página Configurações, revise as informações de Plug-ins. Se o valor de Plugin Set não estiver definido, siga NES-T0001 para reaplicar o conjunto de plug-ins mais recente ao Nessus Manager principal.

5. Clique em Sensores na parte de cima da página e em Agrupamento de agentes.

6. Clique em Grupo de agentes padrão para ver todos os nós registrados.

   Se o grupo estiver vazio ou o nó (instância filha do Nessus) de qualquer organização estiver faltando, a instância filha do Nessus precisará ser registrada novamente.

Observação: pode haver casos em que agentes do Nessus em uma organização são vinculados a um Nessus Manager secundário de outra organização devido à distribuição de um nó principal para os nós secundários acessíveis pelos agentes.