33. Nessus コンポーネントをデプロイする

完了までの推定時間: 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 Namespace で role/system-artifact-management-admin ロールを取得します。

• 必要なツール

  • kubectl
  • gdcloud
  • helm
  • yq
  • docker

• ライセンス

  • Nessus ライセンス 1 つ
    • NES-G0004 - Nessus ライセンスの事前有効化を行う方法に沿って、「GDCH 1」事前有効化バンドルを準備します。

注: gdcloud はデフォルトで解決されない場合があります。そうでない場合は、PATH=/root/release:${PATH:?} でパスを修正して、もう一度お試しください。

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 UI に直接アップロードする必要があるため、メモしておきます。

要件:

• 1000 個以上の IP 制限とホスト名 tenablesc-as1 を含む Tenablesc ライセンス ファイル 1 つ

33.2. Nessus デプロイ ファイルの場所

Nessus をデプロイする前に、Windows PowerShell を使用して次の手順を行い、Nessus インストール ファイルを見つけます。

1. 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
   

2. これらのファイルをローカル ワークステーションに移動して、後で使用できるようにします。

   # 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 - Nessus ライセンスの事前有効化を行う方法に沿って、続行する前に「GDCH 1」事前有効化バンドルを準備します。

1. インターネットに接続されたマシンで、nessus-preact-gdch1.tar.gz を自分で取得するか、Google エンジニアリングの POC を通じて取得します。

2. このファイルをワークステーションに転送し、$env:USERPROFILE\tenable-nessus に配置します。

3. ディレクトリ $env:USERPROFILE\tenable-nessus には、事前アクティベーション バンドルが含まれている必要があります。

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

33.4. WSL を開く

このページの残りの手順では、特に記載がない限り、すべてのコマンドに WSL が必要です。

1. 省略可: Sudo が必要です。sudo ユーザーのパスワードがわからない場合は、次のコマンドを実行して WSL sudo ユーザーの oc-it パスワードを設定します。

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

33.5. 環境変数を設定する

次の手順に沿って、必要な環境変数を設定します。

1. 現在のターミナルで後で使用する環境変数 ROOT_ADMIN_CLUSTER_KUBECONFIG を定義します。これは、前提条件として生成された管理クラスタの kubeconfig の絶対パスである必要があります。

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. 現在のターミナルで、選択した管理クラスタの kubectl コマンドのエイリアスを定義します。

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

3. USERPROFILE 変数を設定します。

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

   $USERPROFILE は $env:USERPROFILE と同じ場所を指すようになりました。

33.5.1. v1 組織の環境変数を設定する

1. 現在のターミナルで後で使用する環境変数 ORG_ADMIN_KUBECONFIG を定義します。これは、前提条件として生成された選択した組織管理クラスタの kubeconfig の絶対パスである必要があります。

   ORG_ADMIN_KUBECONFIG=
   

2. 現在のターミナルで、選択した組織管理クラスタの kubectl コマンドのエイリアスを定義します。

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

3. 現在のターミナルで後で使用する環境変数 ORG_SYSTEM_KUBECONFIG を定義します。これは、前提条件として生成された選択したシステム クラスタの kubeconfig の絶対パスである必要があります。

   ORG_SYSTEM_KUBECONFIG=
   

4. 現在のターミナルで、選択したシステム クラスタの kubectl コマンドのエイリアスを定義します。

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

33.5.2. v2 組織の環境変数を設定する

1. 現在のターミナルで後で使用する環境変数 ORG_MGMT_KUBECONFIG を定義します。これは、前提条件として生成された選択した v2 組織の管理プレーン API サーバー kubeconfig の絶対パスである必要があります。

   ORG_MGMT_KUBECONFIG=
   

2. 現在のターミナルで、選択した組織管理クラスタの kubectl コマンドのエイリアスを定義します。

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

3. 現在のターミナルで後で使用する環境変数 ORG_INFRA_KUBECONFIG を定義します。これは、前提条件として生成された選択した v2 組織のコントロール プレーン API サーバー kubeconfig の絶対パスである必要があります。

   ORG_INFRA_KUBECONFIG=
   

4. 現在のターミナルで、選択したシステム クラスタの kubectl コマンドのエイリアスを定義します。

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

33.6. 事前有効化バンドルをアップロードする

重要: アップグレードにはこの手順は必要ありません。

次の手順に沿って、アーティファクトの Harbor レジストリをアップロードします。

1. 適切なメタデータを使用してバンドルを 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"
   

2. 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
   

3. 事前有効化バンドルを 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 をインストールする

警告: 1.14 より前のバージョンからアップグレードする場合は、インストールに進む前に「省略可: アンインストール」セクションの手順に沿って操作してください。

1. 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. インストールが完了するまで約 1 時間半待ちます。

33.7.1. 省略可: Nessus をアンインストールする

このセクションでは、必要なすべてのクラスタから Nessus デプロイを削除するコマンドについて説明します。

警告: 再インストールまたはアップグレードを行う場合にのみ、既存の Nessus デプロイをアンインストールしてください。それ以外の場合は、このセクションをスキップします。

1. ルート管理クラスタから 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:?}
   

2. 組織アーキテクチャ v1 の場合:

   1. 組織の管理クラスタから Nessus をアンインストールします。

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

   2. 組織のシステム クラスタから Nessus をアンインストールします。

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

3. 組織アーキテクチャ v2 の場合:

   1. 組織管理クラスタから Nessus をアンインストールします。

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

   2. 組織のインフラストラクチャ クラスタから 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 を確認する

1. 鍵と証明書が公開されていることを確認します。

   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. 親 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
   

3. 親 Nessus Manager が異常と報告された場合（前のコマンドの出力が false の場合など）、次のコマンドを使用して親 Nessus Manager を再起動します。

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

4. 1 時間半ほど待ってから、ステータスをもう一度確認します。

5. 1 時間半経過しても親 Nessus Manager が異常と報告される場合は、問題をオンコールにエスカレーションします。

   1. Grafana UI から指定されたクエリを実行した後、次の情報を含めます。

      {pod="<pod_name>"}
      

   2. 親 Nessus Manager の構成を含めます。

      kra get pnm -A -o yaml
      

6. 子 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
   

7. 子 Nessus Manager が異常と報告された場合は、次のコマンドで子 Nessus Manager を再起動し、20 分待ってからステータスを再度確認します。

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

8. 20 分経過しても子 Nessus マネージャーが異常と報告される場合は、問題をエスカレーションし、Grafana UI から指定されたクエリを実行した後に次の情報を含めます。

   1. Grafana UI から指定されたクエリを実行した後、次の情報を含めます。

      {pod="<pod_name>"}
      

   2. 子 Nessus Manager の構成を含めます。

      kra get cnm -A -o yaml
      

9. 異常なエージェントがないことを確認します。

   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. 異常なリストに表示されているすべてのエージェントについて、変数 NESSUS_AGENT_NAME を設定し、次のコマンドをすべてに対して実行します。

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

11. 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 リポジトリの構成を効果的に削除するため）。

12. 20 分経過しても異常なエージェントがリストに表示される場合は、問題をエスカレーションし、Grafana UI から指定されたクエリを実行した後に次の情報を含めます。

    1. Grafana UI から指定されたクエリを実行した後、次の情報を含めます。

       {pod="<pod_name>"}
       

    2. Nessus エージェントのステータスを含めます。

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

    3. Nessus エージェント構成を含めます。

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

33.8. Nessus Manager - 組織の確認

このセクションでは、Distributed Cloud 組織内で Nessus を検証するために必要な手順について説明します。

Nessus の検証を確実に完了するには、Operations Center IT 組織クラスタを含む、Distributed Cloud の各組織クラスタに対してこの手順を実行します。

使用可能な組織を一覧表示します。

kra get -n gpc-system organization

root 組織（すでに説明済み）を除く各組織について、次の手順を行います。

33.8.1. 前提条件

• v1 組織に必要なアクセス権

  • 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 を生成します。

• 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 クラスタロールを取得します。
  • IAM-R0004 に従います。
    • インフラストラクチャ クラスタの cp KUBECONFIG を生成します。

環境変数を設定するに沿って、組織クラスタへのアクセスを設定し、kna と knu のコマンドライン エイリアスを定義します。

33.8.2. v1 組織の組織管理クラスタの Nessus と、v2 組織のインフラストラクチャ管理プレーンの kube API サーバーを確認する

1. 異常なエージェントがないことを確認します。

   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. 異常なリストに表示されているすべてのエージェントについて、変数 NESSUS_AGENT_NAME を設定し、次のコマンドをすべて実行します。

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

3. 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 リポジトリの構成を効果的に削除するため）。

4. 20 分経過しても異常なエージェントがリストに表示される場合は、問題をエスカレーションし、Grafana UI から指定されたクエリを実行した後に次の情報を含めます。

   {pod="<pod_name>"}
   

33.8.3. v1 組織のシステム クラスタの Nessus と、v2 組織のインフラストラクチャ コントロール プレーンの kube API サーバーを確認する

1. 子 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
   

2. 子 Nessus Manager が異常と報告された場合は、次のコマンドで子 Nessus Manager を再起動し、20 分待ってからステータスを再度確認します。

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

3. 20 分経過しても子 Nessus マネージャーが異常と報告される場合は、問題をエスカレーションし、Grafana UI から指定されたクエリを実行した後に次の情報を含めます。

   1. Grafana UI から指定されたクエリを実行した後、次の情報を含めます。

      {pod="<pod_name>"}
      

   2. 子 Nessus Manager の構成を含めます。

      knu get cnm -A -o yaml
      

4. 異常なエージェントがないことを確認します。

   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. 異常なリストに表示されているすべてのエージェントについて、変数 NESSUS_AGENT_NAME を設定し、次のコマンドをすべてに対して実行します。

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

6. 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 リポジトリの構成を効果的に削除するため）。

7. 20 分経過しても異常なエージェントがリストに表示される場合は、問題をエスカレーションし、Grafana UI から指定されたクエリを実行した後に次の情報を含めます。

   1. Grafana UI から指定されたクエリを実行した後、次の情報を含めます。

      {pod="<pod_name>"}
      

   2. Nessus エージェントのステータスを含めます。

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

   3. Nessus エージェント構成を含めます。

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

33.9. Tenable.sc をインストールする

このセクションでは、Operations Center IT 組織内で Tenable.sc の既存の VM をインストールまたはアップグレードする手順について説明します。

33.9.1. 前提条件

• アクセス権が必要です

  • 組織アーキテクチャ v1 の場合:
    • IAM-R0005 に従います。
      • ルート管理クラスタで clusterrole/tenable-nessus-admin-root クラスタロールを取得します。
    • IAM-R0004 に従います。
      • ルート管理クラスタの KUBECONFIG を生成します。
    • IAM-R0005 に従います。
      • gdchservices 管理クラスタで clusterrole/tenable-nessus-admin-org-legacy クラスタロールを取得します。
    • IAM-R0004 に従います。
      • gdchservices 管理クラスタの KUBECONFIG を生成します。
    • IAM-R0005 に従います。
      • gdchservices システム クラスタで clusterrole/tenable-nessus-admin-system-legacy クラスタロールを取得します。
    • IAM-R0004 に従います。
      • gdchservices システム クラスタの KUBECONFIG を生成します。
  • 組織アーキテクチャ v2 の場合:
    • IAM-R0005 に従います。
      • ルート管理クラスタで clusterrole/tenable-nessus-admin-root クラスタロールを取得します。
    • IAM-R0004 に従います。
      • ルート管理クラスタの KUBECONFIG を生成します。
    • IAM-R0005 に従います。
      • gdchservices-management クラスタで clusterrole/tenable-nessus-admin-infra-mp クラスタロールを取得します。
    • IAM-R0004 に従います。
      • gdchservices-management クラスタの KUBECONFIG を生成します。
    • IAM-R0005 に従います。
      • gdchservices-infra クラスタで clusterrole/tenable-nessus-admin-infra-cp クラスタロールを取得します。
    • IAM-R0004 に従います。
      • gdchservices-infra クラスタの KUBECONFIG を生成します。

33.9.2. 環境変数を設定する

次の手順に沿って、必要な環境変数を設定します。

1. 現在のターミナルで後で使用する環境変数 ROOT_ADMIN_CLUSTER_KUBECONFIG を定義します。これは、前提条件として生成された管理クラスタの kubeconfig の絶対パスである必要があります。

   ROOT_ADMIN_CLUSTER_KUBECONFIG=
   

2. 現在のターミナルで、ルート管理クラスタの kubectl コマンドのエイリアスを定義します。

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

3. gdchservices 組織の管理プレーン kubeconfig の環境変数を定義します。

   • 組織アーキテクチャ v1 の場合: 現在のターミナルで後で使用する環境変数 ORG_ADMIN_KUBECONFIG を定義します。これは、前提条件として生成された gdchservices 管理クラスタの kubeconfig の絶対パスである必要があります。

     ORG_ADMIN_KUBECONFIG=
     

   • 組織アーキテクチャ v2 の場合: 現在のターミナルで後で使用する環境変数 ORG_MGMT_KUBECONFIG を定義します。これは、前提条件として生成された gdchservices 管理クラスタの kubeconfig の絶対パスである必要があります。

     ORG_MGMT_KUBECONFIG=
     

4. 上記の kubeconfig を使用して kubectl コマンドのエイリアスを作成します。

   • 組織アーキテクチャ v1 の場合: 現在のターミナルで gdchservices 管理クラスタの kubectl コマンドのエイリアスを定義します。

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

   • 組織アーキテクチャ v2 の場合: 現在のターミナルで gdchservices 管理クラスタの kubectl コマンドのエイリアスを定義します。

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

5. gdchservices 組織のコントロール プレーン kubeconfig の環境変数を定義します。

   • 組織アーキテクチャ v1 の場合: 現在のターミナルで後で使用する環境変数 ORG_SYSTEM_KUBECONFIG を定義します。これは、前提条件として生成された gdchservices システム クラスタ kubeconfig の絶対パスである必要があります。

     ORG_SYSTEM_KUBECONFIG=
     

   • 組織アーキテクチャ v2 の場合: 現在のターミナルで後で使用する環境変数 ORG_INFRA_KUBECONFIG を定義します。これは、前提条件として生成された gdchservices インフラストラクチャ クラスタ kubeconfig の絶対パスである必要があります。

     ORG_INFRA_KUBECONFIG=
     

6. 上記の kubeconfig を使用して kubectl コマンドのエイリアスを作成します。

   • 組織アーキテクチャ v1 の場合: 現在のターミナルで gdchservices システム クラスタの kubectl コマンドのエイリアスを定義します。

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

   • 組織アーキテクチャ v2 の場合: 現在のターミナルで gdchservices インフラストラクチャ クラスタの kubectl コマンドのエイリアスを定義します。

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

7. USERPROFILE 変数を設定します。

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

   $USERPROFILE は $env:USERPROFILE と同じ場所を指すようになりました。

8. Tenable.sc がデプロイされている組織の名前を定義します。

   ORG=gdchservices
   

33.9.3. インストールの準備をする

次の手順に沿って組織を準備します。

1. 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. 2 分後、組織管理者クラスタとシステム クラスタの両方に Namespace が存在することを確認します。

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

   resourcemanager.gdc.goog/attach-all-user-clusters: "true" プロジェクト ラベルを指定すると、組織のすべてのユーザー クラスタにも名前空間が作成されます。

3. Tenable.sc の管理者とマネージャーのユーザー認証情報を生成し、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. 管理チャートをインストールする

1. インストールに備えて、次の環境変数を設定します。

   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. 管理 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 VM 接頭辞を示します。

     OCIT VM 接尾辞を示す OCIT_NESSUS_URL_SUFFIX を設定します。

     管理プレーンの 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:?}"'"}]'
     

     正しいエンドポイントをプローブするように prober リソースにパッチを適用します。

     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. デプロイを確認します。

   次のコマンドの出力を確認して、tenablesc-admin デプロイが成功したことを確認します。

   • 組織アーキテクチャ v1 の場合:

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

   • 組織アーキテクチャ v2 の場合:

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

4. 仮想サービスが存在することを確認します。

   • 組織アーキテクチャ v1 の場合:

     kna get virtualservice -n tenablesc-system
     

   • 組織アーキテクチャ v2 の場合:

     knu get virtualservice -n tenablesc-system
     

5. DNS エントリが存在することを確認します。

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

6. 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 Namespace を作成する必要があります。続行するには、名前空間を作成してから、メタバグを開いて、このエラーが発生する理由の調査を開始します。チケットに 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'
     EOF
     

     5 分後、出力は次のようになります。

     {
         "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 分経過してもステータス出力が正しくない場合は、オブザーバビリティ プラットフォームが正常でない可能性があります。デバッグに役立つステータス情報を含むメタバグを開きます。

33.9.5. VM のインストール グラフ

1. インストールに備えて、次の環境変数を設定します。

   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 }')
     

2. 仮想マシンタイプを設定します。

   1. すべての仮想マシンタイプの名前を取得します。

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

   2. Supported フィールドが true の仮想マシンタイプを選択し、環境変数に保存します。推奨: n2-standard-4-gdc と n3-standard-4-gdc。

      VIRTUAL_MACHINE_TYPE=
      

3. Tenable.sc ログを infra-obs Loki インスタンスに配信するには、ProjectNetworkPolicy が必要です。

   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. VM 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 チャートを適用する際に、次の問題が発生する可能性があります。

   • 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
     

     修復: helm upgrade コマンドを再度実行します。

5. デプロイを確認します。次のコマンドの出力を確認して、tenablesc-vm デプロイが成功したことを確認します。

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

6. Tenable.sc が実行を開始するまで待ちます。

   仮想マシンのステータスを確認します。

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

   VM がまだプロビジョニング中であることを示す出力例:

   NAME            STATUS    AGE
   tenablesc-as1   Pending   55s
   

   VM が実行中であることを示す出力例:

   NAME            STATUS    AGE
   tenablesc-as1   Running   8m25s
   

   60 分後に VM が実行されていない場合は、名前空間イベントで目立つエラーがないか確認します。

   knu get -n tenablesc-system events -o wide
   

   重要な警告やエラーを収集し、メタバグで報告します。

7. Tenable.sc UI にアクセスするには、VirtualService と DestinationRule が必要です。

   • 組織アーキテクチャ v1 の場合: 変更は必要ありません。

   • 組織アーキテクチャ v2 の場合:

     • 後で使用するために、サービス名を環境変数として設定します。

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

     • VirtualService CR と DestinationRule CR を編集します。

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

9. DNS を介してサービスが解決されることを確認します。

   注: 自分で提供したインストーラを使用している場合は、この手順をスキップしてください。

   想定される結果は、200 レスポンス コードと HTML 出力です。

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

33.9.6. Tenable.sc VM の SSH 認証情報を準備する

次の手順に沿って、Tenable VM にアクセスするように SSH を準備します。

1. SSH 認証鍵を生成します。

   この SSH 認証鍵は、VM へのアクセスに一時的にのみ使用されます。

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

2. 次の環境変数を設定します。

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

3. 一時的な（24 時間）VirtualMachineRequest を作成します。

   VirtualMachineRequest は、生成された SSH 証明書を 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. VM SSH IP をローカル環境変数としてエクスポートします。

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

5. SSH 接続が機能していることをテストします。

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

   想定される出力は alice です。これは SSH ユーザー名です。

   SSH 接続がタイムアウトしている場合は、上り（内向き）ポリシーがありません。次のコマンドを使用して上り（内向き）ポリシーを作成し、もう一度お試しください。

6. 内向きポリシーを作成します。

   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. tenablesc-system Namespace に iotools Pod をプロビジョニングします。

   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. 秘密鍵を iotools Pod に転送します。

9. 秘密鍵を iotools Pod に転送します。

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

33.9.7. ウェブ サービスの証明書をインストールする

次の手順に沿って、Tenable.sc ウェブ サービスの証明書をインストールします。

1. VM の 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:?}"
   

2. ウェブサーバーの証明書と鍵を準備します。

   次のコマンドは、Tenable UI の提供に使用される TLS 証明書と鍵をインストールします。

   1. TLS 証明書名を設定する

      TLS_SECRET_NAME=nessus-tls
      

   2. nessus-tls 証明書をローカルに保存します。

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

   3. nessus-tls 証明書を iotools Pod にコピーします。

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

   4. 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. 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. 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\""
      

3. 証明書インストール スクリプトを準備します。

   次のコードを /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. スクリプトを iotools Pod にコピーします。

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

5. ウェブサーバーの証明書と鍵をインストールします。

   Tenable.sc VM で 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. Tenable.sc でログ転送を有効にする

1. NES-R0002 に沿って Tenablesc UI にログインします。

2. ナビゲーション バーで、[システム] > [構成] に移動します。

3. [構成] ページで、[その他] をクリックします。

4. [Syslog] セクションに移動します。

   1. [転送を有効にする] をオンにします。
   2. [Facility] を [user] に設定します。
   3. [重大度] で、[すべて選択] を選択します。

5. [送信] をクリックして、構成を保存します。

   33.9.9. OIC から GDC へのネットワーク接続を有効にする

nessus1 VM と nessus2 VM に対して次の操作を行います。

1. 次の環境変数を設定します。

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

2. 構成を 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. 構成を 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. ライセンスの有効化

このセクションでは、Tenable.sc ライセンスを適用する方法について詳しく説明します。

1. 次の URL を使用して Tenablesc ウェブ UI を開きます。

   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. ライセンスが適用される前に、UI に設定ウィザードが表示されます。

   ログイン プロンプトが UI に表示されている場合は、ライセンスがすでに適用されているため、このセクションの残りの手順はスキップする必要があります。

3. [次へ] をクリックします。

4. Tenable.sc ライセンス ファイル SecurityCenter-<version>-<number>IPs-<uid>.key をアップロードします。

   考えられる問題:

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

     このエラーは、指定されたライセンス ファイルが無効であることを意味します。考えられる原因を以下に示します。

     1. ホスト名が正しくない

        このライセンスの Tenabe.com のプロダクト ページに、間違ったホスト名が設定されています。Tenable.com のプロダクト ページのライセンス ホスト名が tenablesc-as1 であることを確認します。ホスト名が一致しない場合: tenablesc-as1 に設定し、新しいライセンスをダウンロードして、代わりに新しいライセンス ファイルを使用します。

     2. 形式が正しくないファイル

        転送中にライセンス ファイルが変更された可能性がある: Nessus の事前アクティベーション ファイルと同様に、このライセンス ファイルは転送中に変更できません。Tenable.com のプロダクト ページからダウンロードしたファイルをそのまま Tenable UI にアップロードする必要があります。転送前後のファイルの SHA を比較することで、ファイルが変更されたかどうかを再確認できます。

     3. ライセンス ファイルが正しくない

        Tenable.com の [Product] ページから取得した Tenable.sc ライセンス ファイルを使用していることを確認します。ファイルの内容は PEM 鍵に似ている必要があります。

     ライセンスがまだ機能しない場合は、VULN チームでメタバグを開き、これまでに試したトラブルシューティングの手順をすべて含めます。

5. ページを更新すると、ログイン画面が表示されたら、ライセンスは正常に適用されています。

Tenablesc が完全にブートストラップされました。Tenablesc を構成して使用する手順については、オペレーター マニュアルをご覧ください。これらの手順は、ブートストラップ後に完了することが想定されています。

33.9.12. 省略可: アンインストール

このセクションでは、Tenable.sc デプロイを削除するコマンドについて説明します。

警告: Tenable.sc Helm チャートをアンインストールすると、永続ボリュームが削除され、アプリケーション データが削除されます。

クラスタから Helm チャートをアンインストールする手順は次のとおりです。

1. 組織のインフラストラクチャ クラスタから Helm チャートをアンインストールします。

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

2. 管理 API サーバーから Helm チャートをアンインストールします。

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

3. 管理 API サーバーから Tenable SC VM の 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 の UI を使用することです。UI では、Nessus 子はエージェント クラスタリングのデフォルト クラスタ グループにリストされ、すべての Nessus エージェントはデフォルトのエージェント グループにリストされている必要があります。

注: 初期インストール後にプライマリ Nessus Manager を再起動すると、プライマリ Nessus Manager とすべての子の間のリンクが切断されます。これは、Kubernetes にデプロイした結果として自然に発生する可能性があります。

1. プライマリ Nessus Manager UI の DNS を取得します。

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

2. インターネット ブラウザを開き、前の手順のリンクに移動します。これにより、プライマリ Nessus Manager UI に移動します。

3. ユーザー名 admin とデフォルトのパスワード admin を使用して Nessus Manager UI にログインします。

   ログイン時に認証に関する問題が発生した場合は、NES-T0004 に沿って Nessus 認証情報をローテーションし、ログインを再試行します。

4. ページ上部の [設定] をクリックします。

   [設定] ページで、[プラグイン] の情報を確認します。[Plugin Set] の値が定義されていない場合は、NES-T0001 に従って、最新のプラグイン セットをプライマリ Nessus Manager に再適用します。

5. ページ上部の [センサー] をクリックし、[エージェント クラスタリング] をクリックします。

6. [Default Agent Group] をクリックして、登録されているすべてのノードを表示します。

   グループが空の場合、または組織のノード（子 Nessus インスタンス）がない場合は、子 Nessus インスタンスを再登録する必要があります。

注: 親ノードからエージェントがアクセスできる子ノードへの配布により、ある組織の Nessus エージェントが別の組織の子 Nessus Manager にリンクされることがあります。