Quarantine for a misbehaving actor

オープン
#3,463 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
28/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go
領域
backend, security

調査の方向性

Start by reading the QuarantineActor proposal and the named ResumeActor, SuspendActor, DeleteActor, and UpdateActorEgressPolicy RPCs, plus the router’s resume path in atenet-router. The issue describes cross-cutting changes to actor state, networking, snapshot retention, permissions, and audit events, but names no source files or tests. Done means a supported single-call quarantine meets the listed containment, preservation, permission, and audit requirements.

索引モデルが issue の本文から書いたものです。

説明

area/api-machinery area/identity area/network area/security kind/feature

We need a supported, fast, single-call way to contain a misbehaving actor and keep its state for forensics.

Current quarantine procedure

  1. UpdateActorEgressPolicy with rules: [], so new egress is denied within about 10s.
  2. SuspendActor, which checkpoints the actor and tears down the workload, closing open connections.
  3. Copy the actor's snapshot prefix out of object storage to a restricted forensics bucket, because DeleteActor deletes it.
  4. Then DeleteActor, or delete the ActorTemplate if all actors created from it can be stopped too.
  5. Gap: anything that reaches the actor between steps 2 and 4 wakes it, though the damage is limited because egress is denied. Blocking ingress to the actor would close this gap, because the router resumes the actor only when a request gets through. But there is no per-actor ingress control today. The only one is the router's caller allowlist (--ingress-allowed-spiffe-ids), and it applies to every actor in the cluster.

What's missing today

  1. ActorState has no quarantined value, so a suspended actor can always be resumed. atenet-router calls ResumeActor on every inbound request to the actor, and nothing can block ingress to a single actor.
  2. Undoing a quarantine should require a special permission, but today it needs only the same permission as normal use.
  3. There's not currently a way to signal that a snapshot should be held for evidence:
    • DeleteActor deletes the actor's snapshot prefix in object storage and hard-deletes the actor row.
    • Deleting the ActorTemplate keeps the snapshots and blocks resume (FailedPrecondition: actor template not found). But it blocks every actor created from that template, and actors that are already running keep running.
  4. Setting the egress policy to deny-all (rules: []) works and is allowed while the actor is suspended. But it only affects new connections, after a policy cache TTL of up to 10s. TLS-passthrough connections that are already open stay up until the workload is torn down.

Proposal

A QuarantineActor RPC (or a quarantine field on the actor) that does all of the following in one call:

  1. Quarantines the actor. Ingress to the actor is blocked before resume, so no request wakes it. ResumeActor from any caller returns FailedPrecondition, and the router returns a fixed error.
  2. Cuts the network now. Egress is denied without waiting for the cache TTL, and open connections are reset. Ingress to the actor is refused.
  3. Suspends and preserves. Suspend if running (or pause, if a faster stop is needed). Mark the snapshot as tainted and on hold:
    • snapshot GC and DeleteActor keep it;
    • it can't be resumed in production;
    • it can be exported or restored only into an isolated debug environment with no egress.
  4. Separate permissions to release. Add a can_quarantine permission (atespace editor, global owner, and a detection-integration role) and a can_release_quarantine permission held only by an admin or security role, not the atespace editor.
  5. Audit. Record the caller, the reason, and an incident ID in a structured audit event for quarantine, release, and each attempt to resume a quarantined actor.

Also worth considering:

  • Broader scopes: quarantine everything created from a template, or everything in an atespace, for incidents that affect a whole class of actors (e.g. a poisoned image or template).
  • Automation: an API that detection vendors (Wiz, Datadog, custom) can call, so containment doesn't need a human.
  • Supported playbook doc: the ordered steps and the guarantees and limits of each one (what stops immediately, what lasts up to the TTL, what is out of scope).
主要言語
Go
スター
5.9k
フォーク
637
平均マージ
2日 2時間
マージ済み PR(30日)
528

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

agent-substrate/substrate のほかの issue

agent-substrate/substrate の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。