.trivyignore

# Trivy ignore list — 5-Spot Machine Scheduler
#
# Each entry is a Trivy rule ID followed by a short justification. We only
# suppress findings where the flagged behaviour is a deliberate architectural
# choice; every other finding is expected to be fixed in code/config.
#
# Review cadence: audit this file on every major release. If a provider-
# agnostic RBAC rule can be tightened, tighten it instead of extending this
# list. Do not add new entries without a written justification.
#
# Docs: https://aquasecurity.github.io/trivy/latest/docs/configuration/filtering/

# ─────────────────────────────────────────────────────────────────────────────
# RBAC — deploy/deployment/rbac/clusterrole.yaml
# ─────────────────────────────────────────────────────────────────────────────

# KSV-0046 — ClusterRole manages all resources in an API group.
# The controller is provider-agnostic by design: it must create and delete
# any CAPI bootstrap- or infrastructure-provider custom resource the cluster
# operator installs (k0smotron, AWS, Azure, vSphere, Metal3, …). Enumerating
# every known provider's resources would make the manifest fragile and would
# silently break when a new provider is installed. The wildcard is scoped to
# the two dedicated CAPI API groups (bootstrap.cluster.x-k8s.io and
# infrastructure.cluster.x-k8s.io) — it does NOT grant access to core/v1 or
# to arbitrary groups.
AVD-KSV-0046

# KSV-0048 — ClusterRole can manage Kubernetes workloads and pods.
# Required for node drain: the controller issues pod eviction requests
# (pods/eviction: create) and deletes pods that refuse eviction during
# machine shutdown. Scoping is already minimal — get/list/watch/delete on
# pods, create on pods/eviction — and is a standard pattern for CAPI-style
# controllers that manage node lifecycle.
AVD-KSV-0048

# KSV-0041 — ClusterRole can manage secrets.
# Access is READ-ONLY (get/list/watch). The controller resolves SSH key
# Secrets and bootstrap-data Secrets referenced by ScheduledMachine specs;
# it never creates, mutates, or deletes secret material. Tightening further
# would require a per-namespace Role + RoleBinding per provider Secret,
# which is impractical for a cluster-wide controller.
AVD-KSV-0041

# ─────────────────────────────────────────────────────────────────────────────
# Deployment — deploy/deployment/deployment.yaml
# ─────────────────────────────────────────────────────────────────────────────

# KSV-0125 — Restrict container images to trusted registries.
# This is a cluster-level admission policy (Kyverno / OPA Gatekeeper /
# ValidatingAdmissionPolicy), not a workload-level field. We document the
# canonical image registry (ghcr.io/finos/5-spot) in docs/installation and
# leave registry allow-listing to the operator's cluster policy stack.
AVD-KSV-0125

# ─────────────────────────────────────────────────────────────────────────────
# ConfigMap — deploy/deployment/configmap.yaml
# ─────────────────────────────────────────────────────────────────────────────

# KSV-01010 — ConfigMap with sensitive content.
# False positive. The ConfigMap contains only log-level strings and port
# numbers (RUST_LOG, RUST_LOG_FORMAT, METRICS_PORT, HEALTH_PORT). The
# controller reads no credential, token, or private-key material from
# ConfigMaps — all sensitive material is sourced from Secrets.
AVD-KSV-01010

# ─────────────────────────────────────────────────────────────────────────────
# DaemonSet — deploy/node-agent/daemonset.yaml
# ─────────────────────────────────────────────────────────────────────────────

# KSV-0010 — Access to host PID namespace (hostPID: true).
# Architecturally required. The reclaim-agent is a host-process watcher: it
# detects the emergency-reclaim match by scanning /proc for processes whose
# argv matches a curated kill-list, and it executes the graceful stop by
# signalling those host PIDs. Both capabilities depend on the agent sharing
# the host's PID namespace — pod-scoped /proc would only expose the agent's
# own container and make the entire feature inoperable. The agent runs with
# a narrow SecurityContext (read-only root fs, no privilege escalation, no
# extra capabilities beyond what hostPID implies) and is deployed only on
# nodes that have opted in via the 5spot.finos.org/reclaim-agent label.
AVD-KSV-0010

# KSV-0121 — DaemonSet shouldn't have volumes set to {"/proc"}.
# Architecturally required (HIGH-severity variant of KSV-0023 that names
# the specific disallowed host paths). Same rationale: the agent's
# detection contract IS reading `/proc/<pid>/{comm,cmdline}` for every
# host process, and Kubernetes exposes no non-hostPath mechanism for
# that. The mount is scoped to exactly `/proc`, `readOnly: true`,
# `type: Directory`, and the agent never writes back. Phase 2 rung-2
# (netlink proc connector) will replace the read-side but still needs
# host `/proc` for the initial match fan-out, so this suppression is
# durable. No other hostPath volumes exist on this DaemonSet.
AVD-KSV-0121

# KSV-0023 — hostPath volume mounted.
# Architecturally required. The single hostPath volume is `/proc`, mounted
# read-only at /host/proc so the agent can read /proc/<pid>/{comm,cmdline}
# for every host process. The detection contract IS reading host process
# state — there is no Kubernetes-native substitute (the Downward API,
# projected volumes, and CSI drivers do not expose kernel /proc). Scope is
# already minimal: one path (`/proc`), read-only, `type: Directory`, and
# the agent writes nothing back. No other hostPath volumes exist in the
# DaemonSet. Future rung-2 work (netlink proc connector) will replace the
# /proc read-side with event-driven push but still requires host /proc for
# the initial match fan-out, so this suppression is durable.
AVD-KSV-0023

# KSV-0020 — Container 'agent' securityContext.runAsUser should be > 10000.
# Architecturally required (same root cause as KSV-0012 / KSV-0105 /
# KSV-0118 — this rule is the "high-UID" strictness variant of KSV-0105).
# UID 0 is required for `/proc/<pid>/{comm,cmdline}` reads under hardened
# `hidepid=2` mounts. The rule's intent (avoid low-numbered UIDs that may
# collide with reserved host accounts) is moot at UID 0: the collision
# with `root` is deliberate, not accidental. Every other hardening lever
# is already pulled (readOnlyRootFilesystem, capabilities.drop [ALL],
# no privilege escalation, seccomp RuntimeDefault, opt-in nodeSelector).
AVD-KSV-0020

# KSV-0105 — Container 'agent' securityContext.runAsUser should be > 0.
# Architecturally required (same root cause as KSV-0012 / KSV-0118 —
# different rule wording, identical finding). UID 0 is required to read
# `/proc/<pid>/{comm,cmdline}` under hardened `hidepid=2` /proc mounts;
# the only non-root alternative is re-adding `CAP_SYS_PTRACE`, which is
# strictly broader. Every other hardening lever is already pulled:
# readOnlyRootFilesystem, capabilities.drop [ALL], no privilege escalation,
# seccomp RuntimeDefault, opt-in nodeSelector.
AVD-KSV-0105

# KSV-0021 — Container 'agent' should set securityContext.runAsGroup > 10000.
# Architecturally required (follows from KSV-0012 / KSV-0118). The agent
# runs as UID 0 to read host /proc under `hidepid=2`; UID 0 implies GID 0,
# so runAsGroup > 10000 cannot be satisfied without abandoning the root
# requirement already justified above. The rule exists to avoid a shared
# high-GID supplementary group leaking filesystem access between
# unrelated workloads — not a risk here, since the container mounts only
# host /proc (read-only) and has `readOnlyRootFilesystem: true` with
# `capabilities.drop: [ALL]`.
AVD-KSV-0021

# KSV-0012 — Container 'agent' should set securityContext.runAsNonRoot: true.
# Architecturally required (same root cause as KSV-0118 — this rule is the
# container-level variant, 0118 is the pod-level variant). Running as UID 0
# is required so the agent can read /proc/<pid>/{comm,cmdline} for every
# host PID under hardened `hidepid=2` /proc mounts. A non-root build would
# need CAP_SYS_PTRACE added back, which is a strictly broader privilege
# than running as root with every other capability dropped, the filesystem
# read-only, `allowPrivilegeEscalation: false`, and seccomp RuntimeDefault.
# The agent is also scoped to opt-in nodes via the
# `5spot.finos.org/reclaim-agent: enabled` nodeSelector, so even the
# root-process surface is bounded by the operator's explicit arming.
AVD-KSV-0012

# KSV-0118 — DaemonSet uses the default security context (root allowed).
# False-positive wording — an explicit pod- and container-level
# SecurityContext IS set (runAsUser: 0, runAsGroup: 0, runAsNonRoot: false,
# seccompProfile: RuntimeDefault, allowPrivilegeEscalation: false,
# readOnlyRootFilesystem: true, capabilities.drop: [ALL]). The rule fires
# because runAsNonRoot is false, not because the context is missing.
# Running as UID 0 is architecturally required: reading
# /proc/<pid>/{comm,cmdline} for every host PID needs root under hardened
# hidepid=2 /proc mounts. A non-root variant would require adding
# CAP_SYS_PTRACE back, which is a broader privilege than running as root
# with every other capability dropped and the filesystem read-only.
AVD-KSV-0118

# KSV-0116 — DaemonSet 5spot-reclaim-agent should set
# spec.securityContext.runAsGroup, supplementalGroups[*] and fsGroup to
# integer greater than 0.  Architecturally required (same root cause as
# KSV-0012 / KSV-0021 / KSV-0105 / KSV-0118).  UID 0 is required to read
# /proc/<pid>/{comm,cmdline} under hidepid=2; UID 0 implies GID 0, so
# runAsGroup > 0 cannot be satisfied without abandoning the root
# requirement already justified above.  supplementalGroups / fsGroup are
# irrelevant — the agent mounts only host /proc read-only and has no
# writable volumes whose ownership fsGroup would govern.
AVD-KSV-0116

# KSV-0022 — Container has non-default capabilities added.
# Architecturally required for rung 2 of the reclaim-agent's detection
# ladder (`5spot-emergency-reclaim-by-process-match.md` Phase 2 rung 2,
# GitHub issue #40). `CAP_NET_ADMIN` is required to open an
# `AF_NETLINK` / `NETLINK_CONNECTOR` socket and bind to the
# `CN_IDX_PROC` multicast group — the kernel-pushed event source the
# subscriber in `src/netlink_proc.rs` consumes. Rung 1 (the `/proc`
# poll) does not need this cap; operators who pin `--detector=poll`
# never exercise it. We grant the cap once at the pod level rather than
# letting the binary fall back to rung 1 silently at runtime — the
# detector choice is an operator decision, not an availability
# heuristic. Scope is bounded by the existing opt-in
# `5spot.finos.org/reclaim-agent: enabled` nodeSelector, so the cap is
# only granted on the small set of nodes the operator has explicitly
# armed.
AVD-KSV-0022

# ─────────────────────────────────────────────────────────────────────────────
# Dockerfile — Dockerfile, Dockerfile.chainguard
# ─────────────────────────────────────────────────────────────────────────────

# DS-0026 — No HEALTHCHECK defined.
# Kubernetes uses livenessProbe and readinessProbe on /healthz and /readyz
# (port 8081), configured in deploy/deployment/deployment.yaml. HEALTHCHECK
# in the Dockerfile would be dead code in the cluster path, and our
# distroless / Chainguard base images do not ship curl or wget, so the
# check cannot be a simple shell one-liner. Runtime health is authoritative.
AVD-DS-0026