IBM QRadar

The Kubernetes master API server logs will help us to detect several security threats, in this tutorial, we will go over the need steps to forward them to QRadar using the webhook option (Dynamic backend).

Kubernetes offer different ways to deliver its API logs, in the previous tutorial, we have seen how Kubernetes can be configured to store its logs to a local file, then to use a log forwarder utility like: syslog-ng or fluentd to read the logs from a local file and to forward them to QRadar.

In this blog, we will use the WebHook / AuditSink method (Dynamic backend), a seamless way to configure Kubernetes to push its API logs to a remote HTTP/HTTPs Receiver/listener, its easier to configure than the syslog option.

Configuration steps on QRadar side:

1) You will need to install the following parser extension:

Kubernetes-Parser-Webhook-extension-20200617134041.zip

This can be downloaded from the following X-Force collection

You can add it to QRadar from the admin tab -> Extension Management.

2) To create the Kubernetes log source, choose the log source type as Kubernetes Auditing:

Choose the protocol type to be: HTTP Receiver, as following:

Fill in the log source name, description ….:

For the protocol parameters:

log source identifier: can be any keyword, like: kube

Communication Type: I used HTTP, you can use HTTPs as well.

Listen port: I used 12469 but you can choose any port.

Message Pattern: [^\r\n]+ which will take the events line by line, as Kubernetes will push the events one by one, line by line.

After saving the log source, you need to deploy the changes.

QRadar will be listening on that port for any incoming HTTP connections.

Configuration steps on Kubernetes side:

To enable the dynamic auditing webhook / auditsink you need to add the following flags to the api-server config:

To enable the dynamic auditing webhook / auditsink you need to add the following flags to the api-server config:

vi /etc/kubernetes/manifests/kube-apiserver.yaml

spec:

  containers:

  - command:

    - kube-apiserver

…..

    - --audit-dynamic-configuration

    - --feature-gates=DynamicAuditing=true

    - --runtime-config=auditregistration.k8s.io/v1alpha1=true

Wait a few minutes until the api-server will start to use the new config, then you can deploy the following yaml file:

vi auditsink.yaml

Make sure to change the URL to your QRadar HTTP listener URL.

You can apply the above yaml config to your Kubernetes cluster using the kubectl commands:

kubectl apply -f auditsink.yaml

Kubernetes Logs in QRadar

 

QRadar will start to receive the logs, they will be auto discovered as Kubernetes. Security analysts can detect several threats targeting the Kubernetes cluster, like:

• Creation of a privileged container.
• Mounting of sensitive or critical volumes to a container.
• Failed requests to get the Kubernetes secrets.
• Leaked container token
• If a container token will be used to execute commands over other containers.
• If a container token will be used to create another container.
• Successful Kubernetes API requests from anonymous user.
• Successful Kubernetes API requests from unusual countries.
• Successful Kubernetes API requests from different geographies using the same access token.
• Multiple forbidden requests initiated from the same username.
• Command execution over containers in the Kubernetes system namespace.
• Creation of an unusual privileged role

 

The Kubernetes use cases are available out of the box and can be downloaded here: IBM Security QRadar Container Content Extension

All the config files referenced above can be downloaded from this IBM Security X-Force Exchange collection.