预计完成时间：1 天
可操作组件的所有者：VULN
技能配置文件：部署工程师
上次更新时间：2025 年 8 月 18 日
Nessus 是一款安全扫描器，适用于 Google Distributed Cloud (GDC) 经过网闸隔离的支持和运营系统。它可帮助运营中心团队监控和应对硬件和软件中的安全漏洞。
本文档介绍了部署 Nessus 的步骤，并假定遵循这些步骤的操作员正在从同时提供 PowerShell 和 WSL 的 OC 工作站执行步骤。
33.1. 准备工作
需要访问权限
- 遵循 IAM-R0005：
- 在根管理员集群中获取
clusterrole/tenable-nessus-admin-root集群角色。 - 在根管理员集群的
gpc-system命名空间中获取role/system-artifact-management-admin角色。
- 在根管理员集群中获取
- 遵循 IAM-R0005：
所需工具
- kubectl
- gdcloud
- Helm
- yq
- docker
许可
- 一个 Nessus 许可
- 按照 NES-G0004 - 如何执行 Nessus 许可预激活准备“GDCH 1”预激活软件包
- 一个 Nessus 许可
33.1.1. 最佳做法
33.1.1.1. 升级
如果从 1.14 之前的版本升级，请在执行任何安装之前，按照本指南中每个主要部分的“可选：卸载”步骤操作。
如果需要重新安装，请按照本指南中每个主要部分的“可选：卸载”部分操作。
33.1.1.2. 处理组织和地区之间的版本漂移
组织和可用区之间的版本漂移不应导致任何问题。请根据组织的版本，按照组织特定的步骤操作。然后，每个部署将独立于每个可用区。
33.1.2. Tenable.sc 许可
Tenable.sc 是需要许可文件才能运行的许可第三方软件。必须先根据 SBOM 获取 Tenable 许可，然后才能继续。在特殊情况下，我们或许可以提供许可。
许可文件的名称应类似于 SecurityCenter-<version>-1000IPs-<uid>.key。找到此文件并记下它，因为您需要将其直接上传到 Tenablesc 界面。
要求：
- 一个 Tenablesc 许可文件，至少具有 1000 个 IP 地址限制和主机名
tenablesc-as1
33.2. 查找 Nessus 部署文件
在部署 Nessus 之前，请使用 Windows PowerShell 完成以下步骤，以找到 Nessus 安装文件：
访问 Nessus Helm 图表和虚拟机 (VM) 映像：
在 OC 中，这些内容可在
\\<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将这些文件移至本地工作站，以供日后使用：
# Eg "\\dc1-hyperv1\OpsCenter\tenable-nessus\*" $OPS_TENABLE_RESOURCES = "" mkdir $env:USERPROFILE\tenable-nessus Copy-Item ${OPS_TENABLE_RESOURCES} $env:USERPROFILE\tenable-nessus
33.3. 找到 Nessus 预激活软件包
Nessus 预激活软件包特定于 Nessus 的每次安装，因此无法包含在运营中心软件包中。请按照 Nessus 指南 NES-G0004 - How to perform Nessus license preactivation 中的说明准备“GDCH 1”预激活软件包，然后再继续。
在连接到互联网的机器上，自行获取
nessus-preact-gdch1.tar.gz或通过 Google 工程 POC 获取。将此文件转移到工作站，并将其放置在
$env:USERPROFILE\tenable-nessus下目录
$env:USERPROFILE\tenable-nessus必须包含预激活软件包：$env:USERPROFILE\tenable-nessus ├── nessus-preact-gdch1.tar.gz # GDCH Nessus Preactivation File
33.4. 打开 WSL
除非另有说明，否则本页中的其余步骤需要使用 WSL 来执行所有命令。
可选：需要使用 sudo。如果您不知道 sudo 用户密码，请运行以下命令来设置 WSL sudo 用户
oc-it密码：/mnt/c/Windows/System32/wsl.exe --distribution "${WSL_DISTRO_NAME}" --user root --exec passwd oc-it
33.5. 设置环境变量
请按以下步骤设置所需的环境变量：
定义环境变量
ROOT_ADMIN_CLUSTER_KUBECONFIG，以便稍后在当前终端中使用。这必须是作为前提条件生成的管理员集群 kubeconfig 的绝对路径：ROOT_ADMIN_CLUSTER_KUBECONFIG=在当前终端中为所选管理员集群 kubectl 命令定义别名：
alias kra='kubectl --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}'设置
USERPROFILE变量：export USERPROFILE=$(wslpath $(cmd.exe /c "<nul set /p=%UserProfile%" 2>/dev/null))$USERPROFILE现在指向与$env:USERPROFILE相同的位置。
33.5.1. 为 v1 组织设置环境变量
定义环境变量
ORG_ADMIN_KUBECONFIG，以便稍后在当前终端中使用。此路径必须是作为前提条件生成的所选组织管理员集群 kubeconfig 的绝对路径：ORG_ADMIN_KUBECONFIG=在当前终端中为所选组织管理员集群 kubectl 命令定义别名：
alias kna='kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}'定义环境变量
ORG_SYSTEM_KUBECONFIG，以便稍后在当前终端中使用。此路径必须是作为前提条件生成的所选系统集群 kubeconfig 的绝对路径：ORG_SYSTEM_KUBECONFIG=在当前终端中为所选系统集群 kubectl 命令定义别名：
alias knu='kubectl --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}'
33.5.2. 为第 2 版组织设置环境变量
定义环境变量
ORG_MGMT_KUBECONFIG，以便稍后在当前终端中使用。这必须是所选 v2 组织的管理平面 API 服务器 kubeconfig（作为前提条件生成）的绝对路径：ORG_MGMT_KUBECONFIG=在当前终端中为所选组织管理员集群 kubectl 命令定义别名：
alias kna='kubectl --kubeconfig ${ORG_MGMT_KUBECONFIG:?}'定义环境变量
ORG_INFRA_KUBECONFIG，以便稍后在当前终端中使用。这必须是所选 v2 组织控制平面 API 服务器 kubeconfig 的绝对路径，该 kubeconfig 是作为前提条件生成的：ORG_INFRA_KUBECONFIG=在当前终端中为所选系统集群 kubectl 命令定义别名：
alias knu='kubectl --kubeconfig ${ORG_INFRA_KUBECONFIG:?}'
33.6. 上传预激活软件包
运行以下步骤来上传制品 Harbor 注册表。
将软件包转换为具有相应元数据的 OCI 格式：
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"安装 Harbor CA 证书：
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"查找操作系统：
sudo sh -c "hostnamectl"如果操作系统为 Rocky Linux，请运行：
sudo update-ca-trust extract如果操作系统为 Ubuntu，请运行：
sudo update-ca-certificates将预激活软件包上传到 Harbor：
理想方法：使用
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备份方法：使用
kubeconfig。gdcloud system container-registry load-oci ${BUNDLE_OCI_PATH:?} --create-release-metadata=false --use-ip-port=true --skip-failover-registry --kubeconfig=${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}
33.7. 安装 Nessus
触发 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等待大约 1.5 小时，直到安装完成。
33.7.1. 可选：卸载 Nessus
本部分包含用于从所有必需的集群中移除 Nessus 部署的命令。
从根管理员集群中卸载 Nessus：
helm list -n tenable-nessus-system -q --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}对于组织架构 v1：
从组织管理员集群中卸载 Nessus：
helm list -n tenable-nessus-system -q --kubeconfig ${ORG_ADMIN_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}从组织系统集群中卸载 Nessus：
helm list -n tenable-nessus-system -q --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}
对于组织架构 v2：
从组织管理集群中卸载 Nessus：
helm list -n tenable-nessus-system -q --kubeconfig ${ORG_MGMT_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}从组织基础架构集群中卸载 Nessus：
helm list -n tenable-nessus-system -q --kubeconfig ${ORG_INFRA_KUBECONFIG:?} | xargs helm uninstall -n tenable-nessus-system --kubeconfig ${ORG_INFRA_KUBECONFIG:?}
33.7.2. 在根管理员集群中验证 Nessus
验证密钥和证书是否已发布：
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')"验证父 Nessus Manager 是否处于正常状态：
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如果父 Nessus Manager 被报告为不健康（例如，之前任何命令的输出为 false），请使用以下命令重启父 Nessus Manager：
kra rollout restart deployment vuln-parent-nessus-backend-app -n tenable-nessus-system等待大约 1.5 小时，然后再次检查状态。
如果父 Nessus Manager 在 1.5 小时后仍报告为不健康，请将问题上报给值班人员。
在 Grafana 界面中运行指定查询后，请提供以下信息：
{pod="<pod_name>"}包含父 Nessus Manager 配置：
kra get pnm -A -o yaml
验证子 Nessus Manager 是否处于正常状态：
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如果子 Nessus Manager 被报告为不健康，请使用以下命令重启子 Nessus Manager，等待 20 分钟，然后再次检查状态：
kra rollout restart deployment vuln-managed-nessus-backend-app -n tenable-nessus-system如果在 20 分钟后，子 Nessus 管理器仍报告为不健康，请上报问题，并在从 Grafana 界面运行给定查询后附上以下信息。
在 Grafana 界面中运行指定查询后，请提供以下信息：
{pod="<pod_name>"}包含子 Nessus Manager 配置：
kra get cnm -A -o yaml
验证没有运行不正常的代理：
echo "Nodes with unhealthy agents:"\ $(kra get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')对于不健康列表中列出的所有代理，请设置变量
NESSUS_AGENT_NAME，并针对所有代理执行以下命令：NESSUS_AGENT_NAME= kra delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system如果 20 分钟后，列表中仍显示健康状况不佳的代理，请针对每个代理执行以下操作：
检查 Grafana 中 pod
install-<node_name>的日志，如果存在错误日志ansible-playbook error: one or more host failed，请使用 PLATAUTH-G0001 与裸金属节点建立 SSH 连接。与裸金属节点建立 SSH 连接后，将
/etc/yum.repos.d移至/etc/ yum.repos.d.back（以有效删除 yum 仓库配置）。
如果 20 分钟后，列表中仍显示不健康的代理，请上报问题，并在 Grafana 界面中运行给定查询后添加以下信息。
在 Grafana 界面中运行指定查询后，请提供以下信息。
{pod="<pod_name>"}包含 Nessus 代理状态：
kra get nessusagent/${NESSUS_AGENT_NAME} -n tenable-nessus-system -o yaml添加 Nessus 代理配置：
kra get nessusagentconfig/nessus-agent-config -n tenable-nessus-system -o yaml
33.8. Nessus Manager - 组织验证
本部分介绍了在 Distributed Cloud 组织中验证 Nessus 所需的步骤。
为确保 Nessus 验证成功完成，请针对分布式云的每个组织集群（包括运营中心 IT 组织集群）运行此程序。
列出可用的组织：
kra get -n gpc-system organization
针对每个组织（root 组织除外，因为我们已介绍过该组织）执行以下步骤。
33.8.1. 前提条件
第 1 版组织所需的访问权限
- 遵循 IAM-R0005：
- 在根管理员集群中获取
clusterrole/tenable-nessus-admin-root集群角色。
- 在根管理员集群中获取
请遵循 IAM-R0004：
- 为根管理员集群生成 KUBECONFIG。
遵循 IAM-R0005：
- 在目标组织管理员集群中获取
clusterrole/tenable-nessus-admin-org-legacy集群角色。
- 在目标组织管理员集群中获取
请遵循 IAM-R0004：
- 为目标组织的管理员集群生成 KUBECONFIG。
遵循 IAM-R0005：
- 在目标系统集群中获取
clusterrole/tenable-nessus-admin-system-legacy集群角色。
- 在目标系统集群中获取
请遵循 IAM-R0004：
- 为目标系统集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
v2 组织所需的访问权限
- 遵循 IAM-R0005：
- 在根管理员集群中获取
clusterrole/tenable-nessus-admin-root集群角色。
- 在根管理员集群中获取
- 遵循 IAM-R0004：
- 为根管理员集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 在目标集群中获取
clusterrole/tenable-nessus-admin-infra-mp集群角色。
- 在目标集群中获取
- 遵循 IAM-R0004：
- 为目标基础架构集群生成 MP KUBECONFIG。
- 遵循 IAM-R0005：
- 在目标基础架构控制平面 kube API 服务器中获取
clusterrole/tenable-nessus-admin-infra-cp集群角色。
- 在目标基础架构控制平面 kube API 服务器中获取
- 遵循 IAM-R0004：
- 为基础架构集群生成 cp KUBECONFIG。
- 遵循 IAM-R0005：
按照设置环境变量中的说明设置对组织集群的访问权限，并定义 kna 和 knu 命令行别名。
33.8.2. 验证 v1 组织中的组织管理员集群中的 Nessus 和 v2 组织中的基础设施管理平面 kube API 服务器
验证没有运行不正常的代理：
echo "Nodes with unhealthy agents:"\ $(kna get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')对于不健康列表中列出的所有代理，请设置变量
NESSUS_AGENT_NAME并针对所有代理执行以下命令：NESSUS_AGENT_NAME= kna delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system如果 20 分钟后，列表中仍显示健康状况不佳的代理，请针对每个代理执行以下操作：
检查 Grafana 中 pod
install-<node_name>的日志，如果存在错误日志ansible-playbook error: one or more host failed，请使用 PLATAUTH-G0001 与裸金属节点建立 SSH 连接。与裸金属节点建立 SSH 连接后，将
/etc/yum.repos.d移至/etc/ yum.repos.d.back（以有效删除 yum 仓库配置）。
如果 20 分钟后，列表中仍报告代理运行状况不佳，请上报问题，并在 Grafana 界面中运行给定查询后添加以下信息。
{pod="<pod_name>"}
33.8.3. 验证 v1 组织中的系统集群和 v2 组织中的基础设施控制平面 kube API 服务器中的 Nessus
验证子 Nessus Manager 是否处于正常状态：
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如果子 Nessus Manager 被报告为不健康，请使用以下命令重启子 Nessus Manager，等待 20 分钟，然后再次检查状态：
knu rollout restart deployment vuln-managed-nessus-backend-app -n tenable-nessus-system如果 20 分钟后，子 Nessus 管理器仍报告为不健康，请上报问题，并在从 Grafana 界面运行给定查询后附上以下信息。
从 Grafana 界面运行指定查询后，请提供以下信息。
{pod="<pod_name>"}包含子 Nessus Manager 配置。
knu get cnm -A -o yaml
验证没有运行不正常的代理：
echo "Nodes with unhealthy agents:"\ $(knu get nessusagent -A -o yaml | yq '.items[] | select(.status.conditions[] | select(.type == "Heartbeat" and .status == "False")) | .spec.nodeRef')对于不健康列表中列出的所有代理，请设置变量
NESSUS_AGENT_NAME，并针对所有代理执行以下命令：NESSUS_AGENT_NAME= knu delete nessusagent ${NESSUS_AGENT_NAME} -n tenable-nessus-system如果 20 分钟后，列表中仍显示健康状况不佳的代理，请针对每个代理执行以下操作：
检查 Grafana 中 pod
install-<node_name>的日志，如果存在错误日志ansible-playbook error: one or more host failed，请使用 PLATAUTH-G0001 与裸金属节点建立 SSH 连接。与裸金属节点建立 SSH 连接后，将
/etc/yum.repos.d移至/etc/ yum.repos.d.back（以有效删除 yum 仓库配置）。
如果 20 分钟后，列表中仍显示不健康的代理，请上报问题，并在 Grafana 界面中运行给定查询后添加以下信息。
在 Grafana 界面中运行指定查询后，请提供以下信息：
{pod="<pod_name>"}包含 Nessus 代理状态：
knu get nessusagent/${NESSUS_AGENT_NAME} -n tenable-nessus-system -o yaml添加 Nessus 代理配置：
knu get nessusagentconfig/nessus-agent-config -n tenable-nessus-system -o yaml
33.9. 安装 Tenable.sc
本部分包含在 Operations Center IT 组织中安装或升级 Tenable.sc 现有虚拟机的步骤。
33.9.1. 前提条件
需要访问权限
- 对于组织架构 v1：
- 遵循 IAM-R0005：
- 在根管理员集群中获取
clusterrole/tenable-nessus-admin-root集群角色。
- 在根管理员集群中获取
- 遵循 IAM-R0004：
- 为根管理员集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 在 gdchservices 管理员集群中获取
clusterrole/tenable-nessus-admin-org-legacy集群角色。
- 在 gdchservices 管理员集群中获取
- 遵循 IAM-R0004：
- 为 gdchservices 管理员集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 在 gdchservices 系统集群中获取
clusterrole/tenable-nessus-admin-system-legacy集群角色。
- 在 gdchservices 系统集群中获取
- 遵循 IAM-R0004：
- 为 gdchservices 系统集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 对于组织架构 v2：
- 遵循 IAM-R0005：
- 在根管理员集群中获取
clusterrole/tenable-nessus-admin-root集群角色。
- 在根管理员集群中获取
- 遵循 IAM-R0004：
- 为根管理员集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 在 gdchservices-management 集群中获取
clusterrole/tenable-nessus-admin-infra-mp集群角色。
- 在 gdchservices-management 集群中获取
- 遵循 IAM-R0004：
- 为 gdchservices-management 集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 在 gdchservices-infra 集群中获取
clusterrole/tenable-nessus-admin-infra-cp集群角色。
- 在 gdchservices-infra 集群中获取
- 遵循 IAM-R0004：
- 为 gdchservices-infra 集群生成 KUBECONFIG。
- 遵循 IAM-R0005：
- 对于组织架构 v1：
33.9.2. 设置环境变量
请按以下步骤设置所需的环境变量：
定义环境变量
ROOT_ADMIN_CLUSTER_KUBECONFIG，以便稍后在当前终端中使用。这必须是作为前提条件生成的管理员集群 kubeconfig 的绝对路径：ROOT_ADMIN_CLUSTER_KUBECONFIG=在当前终端中为根管理员集群 kubectl 命令定义别名：
alias kra='kubectl --kubeconfig ${ROOT_ADMIN_CLUSTER_KUBECONFIG:?}'为 gdchservices 组织的管理平面 kubeconfig 定义环境变量：
对于组织架构 v1：定义环境变量
ORG_ADMIN_KUBECONFIG，以便稍后在当前终端中使用。这必须是作为前提条件生成的 gdchservices 管理员集群 kubeconfig 的绝对路径：ORG_ADMIN_KUBECONFIG=对于组织架构 v2：定义环境变量
ORG_MGMT_KUBECONFIG，以便在当前终端中稍后使用。此路径必须是作为前提条件生成的 gdchservices 管理集群 kubeconfig 的绝对路径：ORG_MGMT_KUBECONFIG=
使用上述 kubeconfig 为 kubectl 命令创建别名：
对于组织架构 v1：在当前终端中为 gdchservices 管理员集群 kubectl 命令定义别名：
alias kna='kubectl --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}'对于组织架构 v2：在当前终端中为 gdchservices 管理员集群 kubectl 命令定义别名：
alias kna='kubectl --kubeconfig ${ORG_MGMT_KUBECONFIG:?}'
为 gdchservices 组织的控制平面 kubeconfig 定义环境变量：
对于组织架构 v1：定义环境变量
ORG_SYSTEM_KUBECONFIG，以便稍后在当前终端中使用。此路径必须是作为前提条件生成的 gdchservices 系统集群 kubeconfig 的绝对路径：ORG_SYSTEM_KUBECONFIG=对于组织架构 v2：定义环境变量
ORG_INFRA_KUBECONFIG，以便在当前终端中稍后使用。此路径必须是作为前提条件生成的 gdchservices 基础架构集群 kubeconfig 的绝对路径：ORG_INFRA_KUBECONFIG=
使用上述 kubeconfig 为 kubectl 命令创建别名：
对于组织架构 v1：在当前终端中为 gdchservices 系统集群 kubectl 命令定义别名：
alias knu='kubectl --kubeconfig ${ORG_SYSTEM_KUBECONFIG:?}'对于组织架构 v2：在当前终端中为 gdchservices 基础架构集群 kubectl 命令定义别名：
alias knu='kubectl --kubeconfig ${ORG_INFRA_KUBECONFIG:?}'
设置
USERPROFILE变量：export USERPROFILE=$(wslpath $(cmd.exe /c "<nul set /p=%UserProfile%" 2>/dev/null))$USERPROFILE现在指向与$env:USERPROFILE相同的位置。定义部署 Tenablesc 的组织的名称：
ORG=gdchservices
33.9.3. 准备安装
请按以下步骤准备组织。
创建
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两分钟后，验证组织管理员集群和系统集群中是否存在命名空间。
kna get namespace tenablesc-system -o yaml knu get namespace tenablesc-system -o yaml请注意，
resourcemanager.gdc.goog/attach-all-user-clusters: "true"项目标签会导致在组织的所有用户集群中也创建命名空间。生成并保存 Tenablesc 管理员和经理用户凭据，作为 Kubernetes Secret。
cat <<EOF | knu apply -n tenablesc-system -f - apiVersion: v1 kind: Secret type: Opaque metadata: name: users data: adminpw: $(</dev/urandom tr -dc 'A-Za-z0-9~!@#$%^*+?' | head -c 25 | base64) managerpw: $(</dev/urandom tr -dc 'A-Za-z0-9~!@#$%^*+?' | head -c 25 | base64) EOF
33.9.4. 安装管理员图表
设置以下环境变量，为安装做好准备：
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应用管理员 Helm 图表。
对于组织架构 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:?}对于组织架构 v2：
将
OCIT_NESSUS_MANAGER_PREFIXES设置为以英文逗号分隔的列表，例如"{dc1-nessus1,dc1-nessus2}"，表示 OCIT 虚拟机前缀。设置
OCIT_NESSUS_URL_SUFFIX，表示 OCIT 虚拟机后缀。为管理平面应用 Helm 更新：
helm upgrade --install \ tenablesc-admin ${USERPROFILE:?}/tenable-nessus/tenablesc-infra-mp.tgz \ --namespace tenablesc-system \ --set urlSuffix=${URL_SUFFIX:?} \ --set ocitNessusManagerPrefixes=${OCIT_NESSUS_MANAGER_PREFIXES:?} \ --set deployName=${DEPLOY_NAME:?} \ --kubeconfig ${ORG_MGMT_KUBECONFIG:?}为基础设施平面应用 Helm 更新：
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:?}应用 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创建服务条目：
cat <<EOF | knu apply -f - apiVersion: networking.istio.io/v1beta1 kind: ServiceEntry metadata: name: nessus-svc-entry namespace: istio-system spec: hosts: - nessus.${ROOT_URL_SUFFIX:?} location: MESH_EXTERNAL ports: - name: https-port number: 443 protocol: TLS resolution: DNS EOF创建 DNS 注册：
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等待 5 分钟后，将 FQDN 存储在环境变量中：
TENABLE_SC_INTERNAL_FQDN=$(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc-internal -o jsonpath='{.status.fqdn}')修补虚拟服务和网关，以添加 Tenable SC 内部 FQDN：
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:?}"'"}]'修补探测器资源以探测正确的端点：
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:?}"'"}]'
验证部署。
查看以下命令的输出，确认
tenablesc-admin部署是否成功：对于组织架构 v1：
helm ls --namespace tenablesc-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}对于组织架构 v2：
helm ls --namespace tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
验证虚拟服务是否存在。
对于组织架构 v1：
kna get virtualservice -n tenablesc-system对于组织架构 v2：
knu get virtualservice -n tenablesc-system
验证 DNS 条目是否存在。
echo $(kna get dnsregistrations.network.private.gdc.goog -n tenablesc-system tenablesc -o jsonpath='{.status.fqdn}')验证
AuditLoggingTarget是否已准备就绪，这预计需要几分钟时间。kna get auditloggingtarget/tenablesc-audit-logging-target -n tenablesc-system -o jsonpath='{ .status }' | jq可能会出现以下错误：
Error: failed to copy secret to project: namespace "tenablesc-system" not found in cluster <user_cluster>如果需要，则必须在指定集群中创建
tenablesc-system命名空间。如需继续操作，请创建命名空间，然后打开一个元 bug，以触发对发生此 bug 的原因的调查。在支持请求中添加tenablesc-system项目描述输出。kna describe project tenablesc-system可能会出现以下错误：
Error from server (NotFound): auditloggingtargets.logging.private.gdc.goog "tenablesc-audit-logging-target" not found如果是，请手动创建缺少的
AuditLoggingTarget：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' EOF5 分钟后，输出应类似于以下内容：
{ "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 }10 分钟后，如果状态输出仍然不正确，则表明可观测性平台可能运行不正常。打开包含可用状态信息的元 bug，以协助进行调试。
33.9.5. 安装虚拟机图表
设置以下环境变量，为安装做好准备：
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对于组织架构 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 }')对于组织架构 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 }')
设置虚拟机类型：
获取所有虚拟机类型的名称：
kna get virtualmachinetypes.virtualmachine.gdc.goog -n vm-system选择
Supported字段为true的虚拟机类型，并将其存储在环境变量中。首选：n2-standard-4-gdc和n3-standard-4-gdc。VIRTUAL_MACHINE_TYPE=
需要
ProjectNetworkPolicy才能将 Tenable.sc 日志传送到infra-obsLoki 实例。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应用虚拟机的 Helm 图表。
对于组织架构 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:?}对于组织架构 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:?}
应用 Helm 图表时，您可能会遇到以下问题：
网络钩子失败：
connect: connection refusedError: 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补救措施：再次运行 helm upgrade 命令。
验证部署。 查看以下命令的输出，确认
tenablesc-vm部署是否成功：helm ls --namespace tenablesc-system --kubeconfig ${ORG_ADMIN_KUBECONFIG:?}等待 Tenablesc 开始运行。
检查虚拟机状态：
kna get virtualmachines.virtualmachine.gdc.goog -n tenablesc-system示例输出，指示虚拟机仍在预配：
NAME STATUS AGE tenablesc-as1 Pending 55s示例输出，指示虚拟机正在运行：
NAME STATUS AGE tenablesc-as1 Running 8m25s如果虚拟机在 60 分钟后仍未运行，请查看命名空间事件，了解是否有任何突出错误。
knu get -n tenablesc-system events -o wide收集所有值得注意的警告和错误，并通过元 bug 报告它们。
您需要有
VirtualService和DestinationRule才能访问 Tenable.sc 界面。对于组织架构 v1：无需进行任何更改。
对于组织架构 v2：
将服务名称设置为环境变量，以供日后使用：
TENABLE_SC_SERVICE=$(knu get service -n tenablesc-system | awk '($1 ~ /^g-svc-/) && ($0 ~ /443/) {print $1}'s)修改
VirtualService和DestinationRuleCR：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"}}'
验证 DNS 是否解析为 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:?}验证服务是否通过 DNS 解析。
预期结果是 200 响应代码和一些 HTML 输出。
curl -kv https://${TENABLE_SC_HOST:?}
33.9.6. 准备 Tenablesc 虚拟机的 SSH 凭据
请按照以下步骤操作，准备好 SSH 以访问 Tenable 虚拟机。
生成 SSH 密钥。
此 SSH 密钥仅用于临时访问虚拟机。
rm /tmp/tenablesc ssh-keygen -t rsa -b 4096 -f /tmp/tenablesc -N ""设置以下环境变量。
export VM_PUBLIC_KEY=$(cat /tmp/tenablesc.pub) export VM_NAME=tenablesc-as1创建临时（24 小时）
VirtualMachineRequest。VirtualMachineRequest用于在虚拟机上安装生成的 SSH 证书。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将虚拟机 SSH IP 导出为本地环境变量。
INGRESS_IP=$(kna get vmexternalaccess tenablesc-as1 -n tenablesc-system -o jsonpath='{.status.ingressIP}') echo "VM SSH IP: ${INGRESS_IP:?}"测试 SSH 连接是否正常运行：
ssh -i /tmp/tenablesc -o "StrictHostKeyChecking no" alice@${INGRESS_IP:?} whoami预期输出为
alice，即 SSH 用户名。如果 SSH 连接超时，则说明缺少入站流量政策。使用以下命令创建 Ingress 政策，然后重试。
创建入站政策：
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在
tenablesc-system命名空间中预配iotoolspod：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将私钥转移到
iotoolspod：将私钥转移到
iotoolspod：knu -n tenablesc-system cp /tmp/tenablesc iotools:/tmp/tenablesc
33.9.7. 安装 Web 服务证书
请按照以下步骤安装 Tenablesc Web 服务证书。
将虚拟机 SSH IP 地址导出为本地环境变量：
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:?}"准备 Web 服务器证书和密钥。
以下命令将安装用于提供 Tenable 界面的 TLS 证书和密钥。
设置 TLS 证书名称
TLS_SECRET_NAME=nessus-tls在本地保存
nessus-tls证书：knu get secret ${TLS_SECRET_NAME:?} -n tenable-nessus-system -o yaml > nessus-tls.yaml将
nessus-tls证书复制到iotoolspod：knu -n tenablesc-system cp nessus-tls.yaml iotools:/tmp/nessus-tls.yaml暂存 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\""暂存 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\""暂存 TLS CA 证书。
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\""
准备证书安装脚本。
将以下代码保存到
/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将脚本复制到
iotoolspod：knu -n tenablesc-system cp /tmp/tenable-sc-install-web-tls.sh iotools:/tmp/tenable-sc-install-web-tls.sh安装 Web 服务器证书和密钥。
在 Tenable.sc 虚拟机上执行
install-web-tls.sh。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"Tenable.sc 服务现在使用相应的 TLS 证书和密钥。
33.9.8. 在 TenableSC 中启用日志转发
按照 NES-R0002 中的说明登录 Tenablesc 界面。
在导航栏中，依次前往系统 > 配置。
在配置页面中，点击其他。
前往 Syslog 部分：
- 开启启用转发。
- 将设备设置为用户。
- 在严重程度中，选择全选。
点击提交以保存配置。
33.9.9. 启用 OIC 到 GDC 的网络连接
针对 nessus1 和 nessus2 虚拟机完成以下步骤：
设置以下环境变量：
SITE_ID= OIC_DNS_SUFFIX= NESSUS_SUFFIX= GDC_SERVICES_ORG_URL_SUFFIX=$(kna get configmap dnssuffix -n gpc-system -o jsonpath='{.data.dnsSuffix}')将配置发布到 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将配置发布到 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. 清理
删除临时 Nessus 目录。
rm -rf /tmp/nessus
33.9.11. 许可激活
本部分详细介绍了如何应用 Tenablesc 许可。
使用以下网址打开 Tenablesc 网页界面：
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:?}"在应用许可之前，界面会显示设置向导。
如果界面显示登录提示，则表示许可已应用，应跳过本部分的其余步骤。
点击下一步。
上传 Tenablesc 许可文件
SecurityCenter-<version>-<number>IPs-<uid>.key。潜在问题：
Error Activating License File. License Is Invalid. No Valid License Found.：此错误表示提供的许可文件无效。请逐一排查以下潜在原因：
主机名不正确
相应许可的 Tenabe.com 产品页面中设置了错误的主机名。检查 Tenable.com 产品页面中的许可主机名是否为
tenablesc-as1。如果主机名不匹配：请将其设置为tenablesc-as1，下载新许可，然后使用新许可文件。文件格式错误
许可文件可能在传输过程中被修改：与 Nessus 预激活文件类似，此许可文件在传输过程中无法修改。必须将从 Tenable.com 产品页面下载的确切文件上传到 Tenable 界面。您可以通过比较文件在转移前后的 SHA 来仔细检查文件是否被修改。
许可文件不正确
确保您使用的是从 Tenable.com 产品页面获得的
Tenable.sc许可文件。文件的内容应类似于 PEM 密钥。
如果许可仍无法正常使用，请向 VULN 团队提交 metabug，并附上迄今为止尝试过的所有问题排查步骤。
刷新页面。如果您看到登录界面，则表示许可已成功应用。
Tenablesc 现已完全完成自举。有关配置和使用 Tenablesc 的更多步骤，请参阅操作员手册，这些步骤预计将在引导后完成。
33.9.12. 可选：卸载
本部分包含用于移除 Tenable.sc 部署的命令。
请按照以下步骤从集群中卸载 Helm 图表：
从组织基础架构集群中卸载 Helm 图表：
helm uninstall --namespace tenablesc-system tenablesc-system --kubeconfig ${ORG_INFRA_KUBECONFIG:?}从管理 API 服务器中卸载 Helm 图表：
helm uninstall --namespace tenablesc-system tenablesc-admin --kubeconfig ${ORG_MGMT_KUBECONFIG:?}从管理 API 服务器卸载 Tenable SC 虚拟机的 Helm 图表：
VIRTUAL_MACHINE_NAME=$(knu get virtualmachine -n tenablesc-system -o custom-columns=NAME:.metadata.name | sort -r -k 1 | head -1) kna patch virtualmachines.virtualmachine.gdc.goog ${VIRTUAL_MACHINE_NAME:?} -n tenablesc-system --type merge --patch '{"spec":{"runningState":"Stopped"}}' helm uninstall tenablesc-vms -n tenablesc-system --kubeconfig ${ORG_MGMT_KUBECONFIG:?}
33.9.13. Tenable.SC 设置
按照 NES-G0001 - 设置 Tenable.SC 设置 Tenable.sc。
33.10. 验证 Nessus 部署
本部分详细介绍了验证 Nessus 管理器和代理是否正在运行并按预期关联在一起的步骤，并提供了修复已知潜在问题的步骤。
此部分旨在在安装结束时运行，但建议在执行扫描之前先完成这些验证步骤。有关执行扫描的步骤，请参阅操作员手册。
在开始之前，请按照设置环境变量中的说明设置对根管理员集群的访问权限，并定义 kra 命令行别名。
33.10.1. 验证集群
验证 Nessus Manager 和代理是否已关联在一起的主要方法是通过主 Nessus Manager 界面。在界面中，Nessus 子级必须列在代理集群默认集群组中，并且所有 Nessus 代理必须列在默认代理组中。
获取主 Nessus Manager 界面的 DNS：
echo Nessus Manager UI: https://$(kra get dnsregistration \ -n tenable-nessus-system nessus -o jsonpath='{.status.fqdn}')打开互联网浏览器，然后前往上一步中的链接。这会将您导航到主要 Nessus Manager 界面。
使用用户名
admin和默认密码admin登录 Nessus Manager 界面。如果在登录时遇到任何身份验证问题，请按照 NES-T0004 轮替 Nessus 凭据，然后重试登录。
点击页面顶部的设置。
在设置页面上，查看插件信息。如果未定义插件集的值，请按照 NES-T0001 将最新插件集重新应用于主 Nessus Manager。
点击页面顶部的传感器，然后点击代理聚类。
点击默认代理组，查看所有已注册的节点。
如果任何组织的群组为空或节点（子 Nessus 实例）缺失，则必须重新注册子 Nessus 实例。