Matías Davyt
Matías Davyt

Reputation: 1

Falco whitelisted rule still being triggered

The issue

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.

My setup

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"
}

I have checked that:

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
REVISION    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

Answers (0)

Related Questions