ファイアウォールとセキュリティ

Zenavo のために開けるポートはありません

セットアップ後、Zenavo からサーバーに接続しに行くことはありません。セットアップでインストールされる Zenavo エージェントがサーバー上で動き、HTTPS（ポート 443）でコントロールプレーンに外向きに接続します。Zenavo はこの接続を通じて、デプロイ、ログ、ターミナルを送ります。したがって：

• Kubernetes API（6443）：インターネットからは閉じてください。使うのはサーバー内のエージェントだけです。
• SSH（22）：Zenavo コントロールプレーンが使うのはセットアップ中だけです。その後は、サーバーを管理する場所からのみ許可するか、閉じてください。

80、443、（ポートを公開する場合は）30000–32767 は全員に開けておきます。サーバーの Firewall タブがコントロールプレーンからこれらを確認します。サーバーはコンソールのアドレスに HTTPS で到達できる必要があります。

エージェントにできること

エージェントは専用の Kubernetes サービスアカウントを使い、権限は Zenavo に必要な範囲に限られています。

• 管理できるのはプロジェクトの名前空間（zv-…）だけです。各名前空間では Kubernetes の Pod Security baseline レベルを強制するため、特権での実行、ホストネットワークの使用、ホストディレクトリのマウントはどのワークロードにもできません。
• プロジェクトの名前空間以外の Secret を読んだりコマンドを実行したりできず、自身の権限を変更できず、K3s のシステムコンポーネントにも触れられません（状態の読み取りは可能）。
• これらの制限は Kubernetes のアドミッションポリシーで強制され、エージェントはそれを削除できません。

エージェントのコンテナは非 root ユーザーで、読み取り専用のファイルシステムで動きます。/var/lib/rancher/k3s のディスク使用量を報告するため、ホストのディレクトリをひとつ読み取り専用でマウントします。

Zenavo が保存するもの

• エージェントのトークンのハッシュ。トークン自体はあなたのサーバーにしかありません。
• チームのイメージだけを読み取れる、イメージレジストリの pull 用認証情報。

稼働中のサーバーについて、Zenavo は SSH 鍵、パスワード、クラスターの認証情報を一切保持しません。入力した SSH のパスワードや鍵はセットアップジョブが使い、セットアップが成功するとすぐに消去されます。失敗した場合は、再入力なしで再試行できるよう 1 日間暗号化して保持し、その後消去します。セットアップは ~/.ssh/authorized_keys に何も追加しません。

サーバーを削除すると、Zenavo はエージェントのトークンを削除するので、エージェントは接続できなくなります。K3s、エージェント、データはマシンに残ります。不要なら、サーバーで /usr/local/bin/k3s-uninstall.sh を実行してください。

エージェント導入前に追加したサーバー

エージェントが登場する前に追加されたサーバーには、Zenavo がインストールした鍵による SSH と、K3s の管理者認証情報による Kubernetes API でアクセスしていました。Zenavo はこれらを自動でエージェントに移行します。エージェントをインストールし、~/.ssh/authorized_keys から Zenavo の鍵を削除し、保存していた鍵と認証情報を削除します。Settings → Connection で状態を確認でき、すぐに移行を始めることもできます。自分の秘密鍵を貼り付けていた場合、もう使わないならサーバーから自分で削除してください。その後 k3s certificate rotate（K3s が再起動します）で K3s の証明書をローテーションすれば、Zenavo がかつて持っていた管理者認証情報は使えなくなります。

ビルドがあなたのサーバーで動くことはありません

Git のビルドは Zenavo のビルドマシンで動きます。ビルドマシンはコントロールプレーン、他の顧客、クラウドの認証情報にアクセスできません。サーバーは完成したイメージを digest に固定して pull するだけです。