Documentation
¶
Index ¶
Constants ¶
const ( BehaviorNetwork = "network" BehaviorOpen = "open" BehaviorExec = "exec" BehaviorProtocol = "protocol" BehaviorDNS = "dns" )
Behavior names emitted on findings; they match reporter.Finding.Behavior.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type FindingSink ¶
FindingSink receives the findings monitor mode produces. *reporter.Reporter satisfies it; tests use a recording fake.
type Monitor ¶
type Monitor struct {
// contains filtered or unexported fields
}
Monitor implements events.RuntimePolicyEventHandler (policy tracking), events.NamespaceEventHandler (namespaceSelector input) and runtimeevent.Sink (event evaluation). It is not a pod-event handler: events carry their own attributed pod identity (filled by pkg/attribution), so monitor keeps no pod state at all.
func New ¶
New builds a Monitor. findings and m may each be nil: a daemon without a reporter (or without metrics) still evaluates events, it just has fewer places to put the result.
func (*Monitor) HandleEvent ¶
func (m *Monitor) HandleEvent(ev runtimeevent.Event)
HandleEvent evaluates ev against every tracked policy that selects the event's pod, emitting at most one finding per (policy, pod) for this event. Monitor-mode policies produce counterfactual findings for every violation; enforce-mode policies produce enforced findings only for events the kernel actually denied.
It satisfies runtimeevent.Sink: fast, non-blocking and never panicking outward. The whole body runs behind utils.Guard because the finding sink is an interface supplied by the daemon.
func (*Monitor) NamespaceEvent ¶
NamespaceEvent keeps the namespace label cache in step. A delete drops the entry, which leaves an event from a pod in that namespace matching only the policies whose namespaceSelector is empty — the namespace is going away, so no policy should keep selecting into it.
func (*Monitor) RuntimePolicyEvent ¶
func (m *Monitor) RuntimePolicyEvent(rp *compiler.EvaluationResult, rpEventType string) error
RuntimePolicyEvent tracks monitor- AND enforce-mode policies and forgets everything else.
Monitor-mode policies are tracked for the counterfactual ("would this have been denied"). Enforce-mode policies are tracked so a kernel deny can be attributed to the policy whose lists produced it: the kernel maps have no policy dimension, so this userspace re-evaluation is what answers "which policy denied that". A deleted policy is untracked, as is one whose behaviors hold no value at all or whose mode is unknown: none of those can ever produce a finding, and keeping them would only slow the event path down.
Source Files