Establish minimum privileges and an evidence-based platform support matrix

[Anujramola1999]

User outcome

Operators know whether runtime can run on their platform and which permissions are necessary.

Current behavior

The DaemonSet requests privileged/hostPID access. Removing a capability does not establish managed/serverless platform support; access to hooks, cgroups and node deployment must also be available.

Scope

• Audit each requested privilege against an actual feature and test the smallest supported configuration.
• Separately evaluate provider/platform restrictions using current official documentation and reproducible installation evidence.
• Record supported, unsupported, and unverified configurations; avoid promising non-root or CAP_BPF-only operation in advance.

Acceptance

• A tested privilege matrix covers enforcement, observation and cgroup resolution.
• Installation docs name prerequisites and actionable unsupported-platform reasons.
• A platform is marked supported only after installation plus allow/deny validation succeeds.

Dependencies and boundaries

Needs evidence. Related to #191 and #230. Platform access restrictions may require a different deployment model, not just fewer capabilities.

Validation and completion

• Table-driven tests pin the stated invariant, including invalid input and policy updates.
• For code changes: make build and make test; significant changes also require make kind-install and a targeted behavioral check. Pipeline, collector, evaluator, or reporter changes require make smoke-quickstart.
• Kernel changes use the pinned BPF builder, generated-artifact verification, verifier loading, and allowed/denied behavior tests on supported hook paths.
• Update DESIGN, development guidance where affected, and the RuntimePolicy reference and limits. Every rejected user rule must reach an operator log and policy condition; count every observation drop. Preserve the reporter redaction boundary.