{"id":15693735,"url":"https://github.com/developer-guy/falco-hot-reload-with-sidecar","last_synced_at":"2025-10-06T12:56:56.270Z","repository":{"id":52228766,"uuid":"362762401","full_name":"developer-guy/falco-hot-reload-with-sidecar","owner":"developer-guy","description":"Proof Of Concept about adding hot-reloading support to Falco using sidecar container concept in Kubernetes environment","archived":false,"fork":false,"pushed_at":"2021-05-09T10:44:37.000Z","size":4248,"stargazers_count":7,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-05-08T04:54:20.656Z","etag":null,"topics":["charts","falco","falco-hot-reloader","hot-reload","hot-reloading","sidecar"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/developer-guy.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-04-29T09:29:22.000Z","updated_at":"2023-08-09T10:14:18.000Z","dependencies_parsed_at":"2022-09-24T17:58:15.713Z","dependency_job_id":null,"html_url":"https://github.com/developer-guy/falco-hot-reload-with-sidecar","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/developer-guy%2Ffalco-hot-reload-with-sidecar","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/developer-guy%2Ffalco-hot-reload-with-sidecar/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/developer-guy%2Ffalco-hot-reload-with-sidecar/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/developer-guy%2Ffalco-hot-reload-with-sidecar/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/developer-guy","download_url":"https://codeload.github.com/developer-guy/falco-hot-reload-with-sidecar/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253002851,"owners_count":21838640,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["charts","falco","falco-hot-reloader","hot-reload","hot-reloading","sidecar"],"created_at":"2024-10-03T18:48:08.906Z","updated_at":"2025-10-06T12:56:51.227Z","avatar_url":"https://github.com/developer-guy.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Hot Reloading Support for Falco against its configuration and rule file changes in Kubernetes environment\n\n![screen_shoot](./screen_shoot.png)\n\nThe falco project has a builtin [hot-reload feature](https://falco.org/docs/getting-started/running/#hot-reload), so, what is our concern to do that kind of project ? Simple, the Falco project can reload itself when it receives a _SIGHUP_ signal, so, think of that scenario in a Kubernetes environment, the Falco uses a [ConfigMap](https://github.com/falcosecurity/charts/blob/master/falco/templates/configmap.yaml) which includes configuration and rule files for Falco can use. The thing we want to add as a support is monitoring these files and detecting changes againts them and sending _SIGHUP_ signal to the Falco. In order to do that we need to know a couple of things:\n\n* How can access PID of the Falco process within the same Pod ?\n* Are ConfigMaps mounted inside the Pod reloading itself againts updates ?\n\nLet's start with explaining these two questions above:\n\n## How can access PID of the Falco process within the same Pod ?\n\nWe know that Pod is a concept which can include one or more containers in it and we are generally using Pods with a one container inside of it. Sometimes we might need an extra container to assist the main container in Pod. So, how containers in the Pod can communicate each other ? There are multiple ways of doing this such as _Shared Volume_, _IPC_ and _localhost_ net interface etc. In our case, we are going to share process namespace between containers in a Pod, with that we will now be able to access the Falco container PID from a different container.\n\nTo get more detail about the concept, please follow the [link](https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/).\n\n## Are ConfigMaps mounted inside the Pod reloading itself againts updates ?\n\nThere is a really well explained section about this question in the Kubernetes documentation and it says:\n\n\u003e When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well. The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, the kubelet uses its local cache for getting the current value of the ConfigMap. The type of the cache is configurable using the ConfigMapAndSecretChangeDetectionStrategy field in the KubeletConfiguration struct. A ConfigMap can be either propagated by watch (default), ttl-based, or by redirecting all requests directly to the API server. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the Pod can be as long as the kubelet sync period + cache propagation delay, where the cache propagation delay depends on the chosen cache type (it equals to watch propagation delay, ttl of cache, or zero correspondingly).                                                                                   ConfigMaps consumed as environment variables are not updated automatically and require a pod restart.\n\nWe can configure this sync frequency in the _Kubelet_ with a parameter called [--sync-frequency](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/#--sync-frequency).\n\n## Prerequisites\n\n* minikube v1.19.0\n* kubectl v1.21.0\n* buildx v0.5.1-docker 11057da37336192bfc57d81e02359ba7ba848e4a\n* helm v3.5.4+g1b5edb6\n\n## Demo\nFirst, we need to clone the _Falco Helm Chart_ repository.\n\n```bash\n$ git clone --depth=1 https://github.com/falcosecurity/charts\nCloning into 'charts'...\nremote: Enumerating objects: 88, done.\nremote: Counting objects: 100% (88/88), done.\nremote: Compressing objects: 100% (83/83), done.\nremote: Total 88 (delta 16), reused 23 (delta 1), pack-reused 0\nReceiving objects: 100% (88/88), 101.19 KiB | 446.00 KiB/s, done.\nResolving deltas: 100% (16/16), done.\n```\n\nThen start your local _Minikube_ cluster.\n\n```bash\n$ minikube start --extra-arg=kubelet.sync-frequency=\"10s\"\n😄  minikube v1.19.0 on Darwin 10.15.7\n✨  Using the virtualbox driver based on user configuration\n👍  Starting control plane node minikube in cluster minikube\n🔥  Creating virtualbox VM (CPUs=3, Memory=8192MB, Disk=20000MB) ...\n🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.4 ...\n    ▪ kubelet.sync-frequency=10s\n    ▪ Generating certificates and keys ...\n    ▪ Booting up control plane ...\n    ▪ Configuring RBAC rules ...\n🔎  Verifying Kubernetes components...\n    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5\n🌟  Enabled addons: storage-provisioner, default-storageclass\n🏄  Done! kubectl is now configured to use \"minikube\" cluster and \"default\" namespace by default\n```\n\nNow, let's build and push our container image.\n\n```bash\n$ docker buildx -t $DOCKER_USERNAME/falco-hot-reloader:v1 .\n...\n```\n\n\u003e Buildx is a Docker CLI plugin for extended build capabilities with BuildKit, if you want to get more details about it, please follow the [link](https://github.com/docker/buildx).\n\n\nThen go into the chart folder of the Falco and add these lines to the _daemonset.yaml_ file.\n```yaml\nshareProcessNamespace: true # to be able to access Falco process from the sidecar\ncontainers:\n- name: falco-hot-reloader\n  image: devopps/falco-hot-reloader:v1 # don't forget to replace with your $DOCKER_USERNAME\n  env:\n  - name: FALCO_ROOTDIR\n    value: /etc/falco\n  volumeMounts:\n  - mountPath: /etc/falco\n    name: config-volume\n```\n\nLet's install the Falco chart.\n```bash\n$ helm upgrade --install falco charts/falco --namespace falco --create-namespace\nRelease \"falco\" does not exist. Installing it now.\nNAME: falco\nLAST DEPLOYED: Fri Apr 30 14:02:10 2021\nNAMESPACE: falco\nSTATUS: deployed\nREVISION: 1\nTEST SUITE: None\nNOTES:\nFalco agents are spinning up on each node in your cluster. After a few\nseconds, they are going to start monitoring your containers looking for\nsecurity issues.\n\n\nNo further action should be required.\n\n\nTip:\nYou can easily forward Falco events to Slack, Kafka, AWS Lambda and more with falcosidekick.\nFull list of outputs: https://github.com/falcosecurity/charts/falcosidekick.\nYou can enable its deployment with `--set falcosidekick.enabled=true` or in your values.yaml.\nSee: https://github.com/falcosecurity/charts/blob/master/falcosidekick/values.yaml for configuration values.\n```\n\n\u003e If you get the same error below, you can run simply \"helm dependency update\" first.                                                                                                           Release \"falco\" does not exist. Installing it now.                                                                                                                                              Error: found in Chart.yaml, but missing in charts/ directory: falcosidekick\n\nVerify if everything is working before move on.\n\n```bash\n$ kubectl get pods --namespace falco\nNAME          READY   STATUS    RESTARTS   AGE\nfalco-7269h   2/2     Running   0          59s\n```\n\nNow, open the logs of the Falco pod, and then change something inside of the _ConfigMap_ which is in _falco_ namespace, you should see similar output above:\n```bash\n$ kubectl logs -f falco-7269h --namespace falco\n...\n# These logs belongs to a falco-hot-reloader container\n2021/04/30 11:09:16 a config file has changed, falco will be reloaded \n2021/04/30 11:09:16 found executable falco (pid: 19)\n2021/04/30 11:09:16 SIGHUP signal sent to falco (pid: 19)\n...\n\n# These logs belongs to a falco container\nFri Apr 30 11:09:16 2021: SIGHUP received, restarting...\n2021/04/30 11:09:16 starting to watch file: /etc/falco/falco_rules.yaml\n2021/04/30 11:09:16 a config file has changed, falco will be reloaded\n2021/04/30 11:09:16 found executable falco (pid: 19)\n2021/04/30 11:09:16 SIGHUP signal sent to falco (pid: 19)\nSyscall event drop monitoring:\n   - event drop detected: 0 occurrences\n   - num times actions taken: 0\nEvents detected: 0\nRule counts by severity:\nTriggered rules by rule name:\nFri Apr 30 11:09:16 2021: Falco version 0.28.0 (driver version 5c0b863ddade7a45568c0ac97d037422c9efb750)\nFri Apr 30 11:09:16 2021: Falco initialized with configuration file /etc/falco/falco.yaml\nFri Apr 30 11:09:16 2021: Loading rules from file /etc/falco/falco_rules.yaml:\nFri Apr 30 11:09:16 2021: Loading rules from file /etc/falco/falco_rules.local.yaml:\nFri Apr 30 11:09:16 2021: Starting internal webserver, listening on port 8765\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdeveloper-guy%2Ffalco-hot-reload-with-sidecar","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdeveloper-guy%2Ffalco-hot-reload-with-sidecar","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdeveloper-guy%2Ffalco-hot-reload-with-sidecar/lists"}