Podtrace documents its security requirements, including both the guarantees it provides and the limits it explicitly does not cover, primarily in:
https://github.com/gma1k/podtrace/blob/main/SECURITY.md
What users can expect. The security model section states the privilege posture and blast radius of each component. The operator runs unprivileged (distroless nonroot, no host mounts); a compromised operator can only manipulate CRDs in its own namespace and cannot escalate to host privileges directly. The agent DaemonSet runs with CAP_BPF, CAP_PERFMON, and hostPID on each node, and the documentation states plainly that a compromised agent is roughly equivalent to a compromised privileged workload on that node. Per-session Jobs inherit the agent's capability set and are confined to the same single-node blast radius.
Tenant isolation is the central guarantee, because podtrace observes decrypted application-layer traffic. Cross-namespace tracing is consent-gated: a namespaced custom resource may target pods in a foreign namespace only when that namespace opts in via the podtrace.io/allow-tracing-from annotation. This is enforced by the operator at every reconcile, which is authoritative, and by a validating webhook at admission for fast feedback. Without the grant, a custom resource is confined to its own namespace and cannot capture another tenant's decrypted L7 traffic, DNS queries, syscalls, or file paths. Full semantics are documented at https://github.com/gma1k/podtrace/blob/main/docs/cross-namespace-cr-targeting.md
Supply-chain guarantees: all published artifacts (container image, Helm chart, release tarballs) are signed with cosign keyless via GitHub OIDC, with signing events recorded in the public Sigstore Rekor transparency log. Verification commands are documented at https://github.com/gma1k/podtrace/blob/main/docs/installation.md
What users cannot expect. SECURITY.md contains an explicit out-of-scope section. Issues in upstream Kubernetes, the host kernel's BPF verifier, and third-party exporters are not in scope. Attacks that presuppose an adversary already holding cluster-admin privileges are stated to be outside the threat model. Denial of service through excessive trace events on the agent's ring buffer is a user-side concern, with the bounding controls named (samplePercent and thresholds). Development-only paths are excluded.
Feature-level limits are documented the same way. https://github.com/gma1k/podtrace/blob/main/docs/crypto-detection.md states that AF_ALG crypto-socket detection is observation rather than enforcement: it surfaces use of the vulnerable interface, but does not block the syscall, does not detect exploitation, and is not a substitute for patching. It is also off by default.
Security-relevant defaults are documented at https://github.com/gma1k/podtrace/blob/main/docs/configuration.md, including that PII redaction (PODTRACE_REDACT_PII) and DNS-name stripping (PODTRACE_REDACT_DNS_NAMES) are disabled by default, and that plaintext export to non-loopback hosts is disabled by default and must be explicitly enabled.
Hardening guidance for deployments where attacker capability is a concern, covering image digest pinning, RBAC restriction of custom-resource creation, narrow granting of the cross-namespace annotation, and per-node session capacity caps, is in the hardening section of SECURITY.md, with per-distribution notes (SELinux, AppArmor, Pod Security Standards) in the platform guides under https://github.com/gma1k/podtrace/tree/main/docs
Supported versions and the backport window are stated at the top of SECURITY.md.
级别条款。您还可以查看
或
级别条款。