Auditing with Falco
Use Falco to collect audit events
Falco is an open source project for intrusion and abnormality detection for Cloud Native platforms. This section describes how to set up Falco, how to send audit events to the Kubernetes Audit endpoint exposed by Falco, and how Falco applies a set of rules to automatically detect suspicious behavior.
Install Falco
Install Falco by using one of the following methods:
Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
webserver:
enabled: true
listen_port: 8765
k8s_audit_endpoint: /k8s_audit
ssl_enabled: false
ssl_certificate: /etc/falco/falco.pem
This configuration is typically found in the /etc/falco/falco.yaml
file. If Falco is installed as a Kubernetes DaemonSet, edit the falco-config
ConfigMap and add this configuration.
Configure Kubernetes Audit
Create a kubeconfig file for the kube-apiserver webhook audit backend.
cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig apiVersion: v1 kind: Config clusters: - cluster: server: http://<ip_of_falco>:8765/k8s_audit name: falco contexts: - context: cluster: falco user: "" name: default-context current-context: default-context preferences: {} users: [] EOF
Start kube-apiserver with the following options:
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
Audit Rules
Rules devoted to Kubernetes Audit Events can be found in k8s_audit_rules.yaml. If Audit Rules is installed as a native package or using the official Docker images, Falco copies the rules file to /etc/falco/
, so they are available for use.
There are three classes of rules.
The first class of rules looks for suspicious or exceptional activities, such as:
- Any activity by an unauthorized or anonymous user.
- Creating a pod with an unknown or disallowed image.
- Creating a privileged pod, a pod mounting a sensitive filesystem from the host, or a pod using host networking.
- Creating a NodePort service.
- Creating a ConfigMap containing private credentials, such as passwords and cloud provider secrets.
- Attaching to or executing a command on a running pod.
- Creating a namespace external to a set of allowed namespaces.
- Creating a pod or service account in the kube-system or kube-public namespaces.
- Trying to modify or delete a system ClusterRole.
- Creating a ClusterRoleBinding to the cluster-admin role.
- Creating a ClusterRole with wildcarded verbs or resources. For example, overly permissive.
- Creating a ClusterRole with write permissions or a ClusterRole that can execute commands on pods.
A second class of rules tracks resources being created or destroyed, including:
- Deployments
- Services
- ConfigMaps
- Namespaces
- Service accounts
- Role/ClusterRoles
- Role/ClusterRoleBindings
The final class of rules simply displays any Audit Event received by Falco. This rule is disabled by default, as it can be quite noisy.
For further details, see Kubernetes Audit Events in the Falco documentation.
Feedback
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.