security: maximize effective Kyverno, Kubescape and Tetragon coverage with evidence-based exceptions #5629

Desired outcome

The platform runs secure by default with the maximum practically effective protection available in the existing complementary stack: Kyverno for governance/admission policies, Kubescape for posture/vulnerability coverage, and Tetragon for runtime/kernel-level observability and enforcement. Keep the three unless evidence shows a simpler solution preserving equivalent coverage. Avoid weakening security merely to avoid adapting workloads.

Maintainer requirements (2026-10-31)

• Security is a priority that is not traded away for a slightly leaner platform.
• Enable all relevant viable controls by default and improve application compatibility with them; exceptions require a documented, concrete reason. This includes effective network segmentation/default-deny with explicitly allowed necessary traffic.
• Introduce potentially disruptive enforcement safely (report/audit/observe first where appropriate, proof and gradual enforcement), preserving legitimate application behavior.
• Do not repeatedly revisit unchanged exceptions. Re-evaluate when there is relevant new evidence: e.g. a specific upstream release adds compatibility, a regression is fixed, topology/runtime requirements change, or the underlying risk shifts. A generic version update with no relevant change is not by itself a review trigger.
• Measure effective deployed/observed protection, not just Helm values marked enabled. Avoid mistaking tool overlap for full coverage or introducing new tools without a proven gap.

Engineering deliverables

• Inventory active policies, detections, relevant capabilities and actual namespace/workload coverage in Kyverno, Kubescape, Tetragon and network policy layer; compare with upstream available functionality and production requirements.
• Establish documented baseline and prioritized gaps with evidence from manifests, live status, reports and safe functional probes. Separate unenforced rules from observed-only and genuinely enforcing controls.
• Implement valuable missing coverage with tests, staged rollout and bounded exemptions. For incompatible applications, prefer safe app/runtime changes over blanket policy disablement.
• Audit default-deny/allowed network flows and node/kernel-level controls without blocking expected critical traffic or unsupported kernel paths.
• Maintain exception records with precise scope, justification, compensating controls, owner and specific evidence-trigger for reevaluation. No unconditional review loops.
• Verify representative allowed and forbidden behavior, policy admission, runtime events/enforcement, vulnerability/posture scan scope and observability; ensure alerts actionable rather than noisy.
• New or changed controls must not strand GitOps reconciliation or make recovery impossible; build production rollback and failure probes.
• Integrate and de-duplicate with existing issues, including #3156 (Kubescape coverage), #4234 (Kyverno system namespace coverage) and #5260 (security reporting).
• Document evidence-based progress and remaining exceptions rather than declaring 'all controls enabled' based only on config.

The maintainer states the outcome and priorities; autonomous engineering agents validate feasibility, make technical decisions and raise a maintainer ask only if a material decision exceeds the engineering mandate.