A few weeks ago, we announced Sysdig partnership with Google to integrate Sysdig Secure with Google Cloud Security Command Center, a single pane of glass for your security events in Google Cloud. Today we announce that Sysdig Falco, our open source project for container and Kubernetes run-time security, can also send Kubernetes security events to Google Cloud Security Command Center. Sysdig Falco is part of the underlying technology of Sysdig Secure. Sysdig Falco is an interesting option if you are building the infrastructure layer yourself and you don’t need all the enterprise features of Sysdig Secure (image scanning, reporting, incident response, UI for building security policy, audit trail, compliance, integrated forensics capabilities, etc). To have Falco forward events into Google Cloud SCC you just need to:
- Deploy the Sysdig Google Cloud SCC connector in your Kubernetes cluster
- Deploy Falco in your Kubernetes cluster and configure it to send alerts to the connector
Deploy the Sysdig Google Cloud SCC connector in your Kubernetes cluster
When we presented the Sysdig Google Cloud SCC connector, we saw how to deploy it in Google App Engine. This time, we are going to deploy it directly in our Kubernetes cluster. We have cooked a Sysdig Google Cloud SCC connector Kubernetes manifest file that deploys the connector. A Service exposes the application handled by a Deployment. A ConfigMap and a Secret handles configuration and credentials. Make sure you update them first:kind: ConfigMap
apiVersion: v1
metadata:
name: sysdig-gcscc-connector
data:
org_id: "534901558763"
project_id: cscc544401558763
compute_project_id : arboreal-logic-197806
compute_zone: europe-west3-a
webhook_url: https://arboreal-logic-198306.appspot.com/events
---
kind: Secret
apiVersion: v1
metadata:
name: sysdig-gcscc-connector
type: Opaque
data:
sysdig_token: [...]
webhook_authentication_token: [...]
compute_service_account_info: [...]
security_service_account_info: [...] deployment.yaml
Notice that key values in the ConfigMap are using the same names that environment variables, but lowercased. Secret values must be base64 encoded, like this:
$ echo "secret_value" | base64
Once you have updated the YAML file with your configuration and credentials, you can go ahead and create resources in your Kubernetes with:
$ kubectl create -f deployment.yaml
Deploy Falco in your Kubernetes cluster and configure the connector
We already showed how to deploy Falco as a daemonSet in your Kubernetes cluster, so for deploying Falco here, we are going to build on those instructions. Ensure your /etc/falco/falco.yaml configuration file contains the following settings:json_output: true
program_output:
enabled: true
keep_alive: false
program: ""curl -d @- -X POST --header 'Content-Type: application/json' --header 'Authorization: {{ webhook_authentication_token }}' http://sysdig-gcscc-connector.default.svc.cluster.local:8080/events/""
This piece of configuration tells Falco will send alerts using curl to http://sysdig-gcscc-connector.default.svc.cluster.local:8080/events, which is the URL where Sysdig Google Cloud SCC connector Service will be listening. If you have deployed connector to other URL (given by the Namespace and Service names), change that value. Also, notice that you have to replace webhook_authentication_token surrounded by brackets with the value that will be used the webhook authentication. If webhook_authentication_token is myS3cr3tT0kenZ!, program configuration should look like:
json_output: true
program_output:
enabled: true
keep_alive: false
program: ""curl -d @- -X POST --header 'Content-Type: application/json' --header 'Authorization: myS3cr3tT0kenZ!' http://sysdig-gcscc-connector.default.svc.cluster.local:8080/events/""
Kubernetes security events in Google Cloud Security Command Center
Once the two components (the connector and Falco) are configured, you will start receiving security events in Google Cloud Security Command Center. For any runtime security policy that gets triggered you will get:- The asset id, or where in your infrastructure the event happened
- When did this happen
- The Kubernetes pod name and the container id where the event was originated
- The runtime security rule that was triggered
- A summary of the event, as defined in the Falco rule