Implement admin-driven automatic namespace bans

[dinoallo]

Background

CompliK currently has the detection and reporting pieces needed for automatic enforcement, but the actual ban workflow is split and incomplete:

• complik reports content violations to admin through /api/complik-violations.
• procscan reports runtime process violations to admin through /api/procscan-violations.
• sealos-complik-admin stores violation events and has ban / unban records plus namespace ban status APIs.
• procscan has namespace-label action code, but the deployed config keeps it disabled. That action should move to admin so enforcement decisions are centralized.
• The repository docs describe a Block Controller-style handoff where a namespace label triggers the actual namespace blocking behavior.

Goal

Implement automatic namespace banning as an admin-driven workflow:

complik / procscan detects a violation
  -> reports the violation to sealos-complik-admin
  -> admin stores the violation event
  -> admin autoban policy decides whether to ban
  -> admin creates a ban record for audit/UI
  -> admin labels the namespace
  -> Block Controller performs the actual cluster enforcement

This keeps detection, decision/audit, and cluster enforcement separated:

• complik and procscan: detection and reporting only.
• sealos-complik-admin: autoban policy, dedupe, audit record, namespace label handoff.
• Block Controller: actual Kubernetes resource enforcement.

Proposed Implementation

1. Add an admin-side autoban module

Add a new internal module under:

sealos-complik-admin/internal/modules/autoban/

Suggested files:

service.go      # public HandleComplikViolation / HandleProcscanViolation entry points
policy.go       # enablement, source-specific policy, namespace/process-name allow/deny handling
executor.go     # namespace label patch execution
model.go        # optional autoban job/action records for retry/audit
dto.go          # optional policy/config response structs

The service should:

• ignore non-illegal events;
• ignore CompliK test events;
• validate namespace;
• skip namespaces that are already banned;
• create a ban record with operator_name = "system/autoban";
• patch the namespace with the agreed block label;
• record enough reason metadata to make the ban auditable.

2. Trigger autoban after violation persistence

Call the autoban service after successful violation insertions:

• sealos-complik-admin/internal/modules/complikviolation/services.go after CreateViolation succeeds.
• sealos-complik-admin/internal/modules/procscanviolation/services.go after CreateViolation succeeds.

Autoban should not prevent violation ingestion when enforcement fails. Prefer logging and/or job status for enforcement failures.

3. Move namespace labeling responsibility to admin

Admin should be the component that patches namespace labels. procscan should continue to report violations and send alerts, but its namespace label action should remain disabled or be deprecated as the primary enforcement path.

The finalized label contract is:

block.sealos.io/locked: "true"

4. Add Block Controller enforcement

Add or restore a Block Controller that watches namespaces for the agreed label and performs actual enforcement, for example:

• apply network isolation;
• apply zero pod/service resource quotas;
• keep status/events for observability;
• support unban by reacting to label removal.

The controller should be the only component that performs destructive or resource-mutating enforcement beyond namespace labels.

5. Update admin deployment RBAC

Because admin will patch namespace labels, its ServiceAccount needs at least:

resources: ["namespaces"]
verbs: ["get", "list", "watch", "patch", "update"]

The Block Controller will need separate RBAC for the actual enforcement actions it owns.

Configuration

Add an admin-managed autoban policy through the existing project config mechanism, autoban_policy:

{
  "enabled": true,
  "dryRun": false,
  "operatorName": "system/autoban",
  "sources": {
    "complik": { "enabled": true },
    "procscan": { "enabled": true }
  },
  "processNameAllowlist": ["xmrig", "minerd"],
  "processNameDenylist": ["systemd"],
  "namespaceDenylist": ["kube-system", "sealos", "block-system"]
}

Start with conservative defaults: disabled and dry-run by default unless deployment explicitly enables it.

Acceptance Criteria

• A CompliK illegal violation can trigger an admin-created ban record and namespace block label.
• A Procscan illegal violation can trigger an admin-created ban record and namespace block label.
• Non-illegal and test events do not trigger autoban.
• Repeated violations for an already banned namespace do not create duplicate active ban actions.
• If namespace label patching fails, the violation event remains stored and the ban record does not remain active without enforcement.
• Admin deployment includes the namespace patch RBAC it needs.
• Block Controller reacts to block.sealos.io/locked=true and performs the real namespace enforcement.
• Tests cover policy decisions, duplicate-ban avoidance, and executor failure handling.

Open Questions

• Should autoban execute synchronously after violation insertion, or use an async job/outbox table for retry and failure status?
• What exact enforcement should Block Controller perform for later releases beyond network isolation and zero pod/service quota?
• Should unban remove the block label automatically, or should unban remain manual until controller recovery behavior is defined?