rule(The docker client is executed in a container): modify condition to reduce false positive

[rung]

Signed-off-by: Hiroki Suezawa [email protected]

What type of PR is this?
/kind rule-update

Any specific area of the project related to this PR?
/area rules

What this PR does / why we need it:

• What this PR does
  • Modify condition of The docker client is executed in a container rule.
• Why we need it
  • On GKE, The rule has many false positives because default running container uses kubectl.
  • To reduce false positives, and to be able to set additional condition, I would like to add user_known_k8s_client_container macro to this rule.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

• This Deployment is the cause of false positive on GKE.
  • https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/fluentd-gcp-scaler
  • kubectl is used on scaler.sh

Does this PR introduce a user-facing change?:

rule(The docker client is executed in a container): when executing the docker client, exclude containers running in the `kube-system` namespace to avoid false positives
rule(macro user_known_k8s_client_container): macro to match kube-system namespace

[leodido]

/milestone 0.19.0

[fntlnz]

Thanks @rung - it looks good to me! I edited the release notes to match what you did since here we have a user facing change.

[poiana]

LGTM label has been added.

Git tree hash: 9ba34479acedaaf81751c7ae59b340e4048a9284

[rung]

@fntlnz Thank you!

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: fntlnz, leodido

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• rules/OWNERS [fntlnz,leodido]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Kaizhe]

@rung this change is not good to me:

- macro: user_known_k8s_client_container
  condition: (k8s.ns.name = "kube-system")

if some bad guy was able to hack into any container in namespace kube-system and run kubectl (with some of the privileged service accounts), falco will not be able to detect it with your change.

I would propose to change like:

condition:  container.image.repository = gcr/fluentd-scaler and proc.pname=xxx

[Kaizhe]

And this is GKE specific. Hopefully we will have the cloud provider info to leverage in the future.

[rung]

@Kaizhe Thank you for your comment!

How about changing the condition to this? If it's ok, I will send new PR with comments mentioning GKE behavior

condition: (k8s.ns.name="kube-system" and container.image.repository=k8s.gcr.io/fluentd-gcp-scaler)

• The condition has namespace and image repository. So Falco user can get detections other than fluentd-gcp-scaler.

if some bad guy was able to hack into any container in namespace kube-system and run kubectl (with some of the privileged service accounts), falco will not be able to detect it with your change.

Make sense. On the other hand, if we don't specify namespaces, the attack surface could be extended imho.
Because RBAC of Kubernetes is set based on namespaces. And when we don't specify namespaces, user(non-admin) can deploy "gcr/fluentd-scaler" on their namespaces. So they can use "kubectl" using the container.

[Kaizhe]

@rung adding k8s.ns.name="kube-system" is fine with me. Please add comment to the macro saying this is a GKE scenario.

Thanks!