Admission Webhooks i polityki

#sympozium #security #admission #webhook

Koncepcja

Polityki Sympozium są enforcowane at admission time - przed utworzeniem poda, nie at runtime. To gwarantuje że żaden AgentRun nie ominie polityki.

Przepływ

kubectl apply -f agentrun.yaml
    ↓
K8s API Server → Admission Webhook
    ↓
Webhook:
  1. Odczytuje policyRef z SympoziumInstance
  2. Ładuje SympoziumPolicy
  3. Sprawdza:
     ├── Sandbox requirements (required? image? resources?)
     ├── Agent Sandbox requirements (runtime class allowed?)
     ├── Tool gating (allow/deny/ask per tool)
     ├── Feature gates (memory? web-endpoint? channels?)
     ├── Subagent limits (maxDepth? maxConcurrent?)
     └── Network policy rules
  4. ALLOW → AgentRun created
     DENY → AgentRun rejected z clear error message

Kluczowe różnice vs runtime enforcement

Aspekt	Admission-time	Runtime
Timing	Przed tworzeniem zasobu	Po uruchomieniu
Obejście	Niemożliwe (K8s API layer)	Możliwe (process-level)
Feedback	Natychmiast (synchroniczny)	Opóźniony (async)
Overhead	Tylko przy tworzeniu	Ciągły monitoring

Tool Gating

toolGating:
  defaultAction: deny
  rules:
    - tool: read_file
      action: allow
    - tool: execute_command
      action: deny
    - tool: write_file
      action: ask    # Human-in-the-loop

Trzy akcje:

allow - tool dozwolony
deny - tool zablokowany (webhook reject)
ask - wymaga human approval (future feature)

Presetowe polityki

config/policies/
  ├── permissive.yaml    # Dev/demo: all allowed
  ├── default.yaml       # General: execute_command requires approval
  └── restrictive.yaml   # Production: deny-by-default, whitelist

Powiązane: SympoziumPolicy | Model bezpieczeństwa Defence-in-Depth | Efemeryczny RBAC per-run

1.9 KiB Raw Permalink Blame History