Secure Helm Chart

[krisnova]

Motivation

Following this discussion we have been able to identify a number of security holes in the current helm chart.

This issue aims to define the constraints of building a secure-by-default Helm chart for Falco.

Feature

As a Kubernetes user I would like to be able to type

helm install falco <args>

such that a complete Falco installation is deployed to my cluster and is running as an unprivileged daemonset.

This chart should be to the default chart as hardened is to the Linux kernel.

Constraints:

• The daemonset pods are have securitycontext.privileged=false
• No access to the host network
• No access to the host PID namespace
• No access to any of the host namespaces while we are at it. Get rid of them all.

The daemonset pods should be a lightweight program (probably written in Go) that read events from the Falco Unix Socket here.

The host

There should be two options for installing the Falco components on the host. A privileged and less secure option that runs the installation in an init container, or an opt-out option that simply assumes this is already managed at the host level.

Kubernetes should NOT be watching/scheduling Falco. Falco should be scheduled with Systemd so that it will continue to run even if Kubernetes is compromised.

The only components running inside of Kubernetes will be lightweight pods that consume the falco events and can potentially forward these events around the cluster.

Alternatives

Additional context

[leogr]

I like this proposal, but I have some doubts.

It is not totally clear to me who are the consumers of events forwarded by the lightweight program running inside the pods and how events should be forwarded.

Assume falco-exporter is the consumer. I would use mount a hostPath directly in the falco-exporter pods rather than having the lightweight program forwarding events to falco-exporter.

Moreover, gRPC consumers need to connect to each node anyway, just exposing a service in the cluster would not work well (see falcosecurity/falco-exporter#26 ).

So - I might be wrong but - I don't see any need to deploy a daemonset if Falco runs on the host.

If my assumption was correct, the chart should just install Falco on the host by privilege escalating. For example, the chart could just deploy falcoctl (when the new implementation is ready) which in turn will install Falco on the host.

Just thinking, I don't have yet a definitive answer.

Let me know if I miss anything!

[poiana]

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

[poiana]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh with /remove-lifecycle rotten.

Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle rotten

[poiana]

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

[poiana]

@poiana: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue with /reopen.

Mark the issue as fresh with /remove-lifecycle rotten.

Provide feedback via https://github.com/falcosecurity/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.