Reputation: 1
I have Falco installed with Helm, including a whitelists.yaml
file with macros to whitelist some rules for my environment.
This has been working until a few days ago, when I updated the deployment and now the rule Contact K8S API Server From Container
is being triggered for cases in which whitelists are in place.
The rule is defined in the stable ruleset, with a macro for user known activities, initially defined as never_true
- macro: user_known_contact_k8s_api_server_activities
condition: (never_true)
- rule: Contact K8S API Server From Container
desc: >
Detect attempts to communicate with the K8S API Server from a container by non-profiled users. Kubernetes APIs play a
pivotal role in configuring the cluster management lifecycle. Detecting potential unauthorized access to the API server
is of utmost importance. Audit your complete infrastructure and pinpoint any potential machines from which the API server
might be accessible based on your network layout. If Falco can't operate on all these machines, consider analyzing the
Kubernetes audit logs (typically drained from control nodes, and Falco offers a k8saudit plugin) as an additional data
source for detections within the control plane.
condition: >
evt.type=connect and evt.dir=<
and (fd.typechar=4 or fd.typechar=6)
and container
and k8s_api_server
and not k8s_containers
and not user_known_contact_k8s_api_server_activities
output: Unexpected connection to K8s API Server (...)
priority: NOTICE
tags: [maturity_stable, container, network, k8s, mitre_discovery, T1565]
I then override the user_known_contact_k8s_api_server_activities
macro in my whitelists.yaml
file
# Only alert when the metadata fields are populated
- macro: k8s_fields
condition: >
(
k8smeta.ns.name exists and
k8smeta.pod.name exists
)
# Don't alert for specific namespaces
- macro: privileged_namespace
condition: >
(
(k8smeta.ns.name startswith calico)
or (k8smeta.ns.name startswith cattle)
or (k8smeta.ns.name startswith syn)
)
- macro: user_known_contact_k8s_api_server_activities
condition: >
(
not (k8s_fields)
or (privileged_namespace)
or (...other macros...)
)
But now I'm getting alerts for this rule, in cases in which it should be whitelisted (e.g. k8smeta.ns.name startswith syn
)
{
"hostname":"worker-a7f3",
"output":"10:26:00.800107028: Notice Unexpected connection to K8s API Server (...))",
"output_fields":{
(...)
"k8smeta.deployment.name":null,
"k8smeta.ns.name":"syn-infra-monitoring",
"k8smeta.pod.name":"nodeexporter-infra-l9csj",
"proc.cmdline":"kube-rbac-proxy --secure-listen-address=[172.18.200.237]:9100 (...)",
"proc.exepath":"/usr/local/bin/kube-rbac-proxy",
(...)
},
"priority":"Notice",
"rule":"Contact K8S API Server From Container",
"source":"syscall",
"tags":[
"T1565",
"container",
"k8s",
"maturity_stable",
"mitre_discovery",
"network"
],
"time":"2025-01-21T10:26:00.800107028Z"
}
rules_files:
- /etc/falco/falco_rules.yaml
- /etc/falco/falco_rules.local.yaml
- /etc/falco/rules.d
> ls -l /etc/falco/rules.d
total 0
lrwxrwxrwx 1 root root 22 Jan 17 13:40 whitelists.yaml -> ..data/whitelists.yaml
K8s-metacollector
is being loaded, as the fields are populated and shown in the alertsREVISION UPDATED STATUS CHART APP VERSION DESCRIPTION
22 Wed Jul 17 07:08:06 2024 superseded falco-4.6.1 0.38.1 Upgrade complete
23 Thu Jan 16 14:19:51 2025 superseded falco-4.17.0 0.39.2 Upgrade complete
24 Fri Jan 17 10:40:40 2025 superseded falco-4.17.0 0.39.2 Upgrade complete
25 Tue Jan 21 09:16:37 2025 deployed falco-4.17.2 0.39.2 Upgrade complete
Upvotes: 0
Views: 30