Containers are changing the way of how software’s are built and delivered, build it once and run it anywhere, onsite, or on the cloud.
IBM Security QRadar is capable of ingesting and detecting security threats in Kubernetes deployments, onsite, and on the cloud.
Many use cases can be derived to highlight the threats for security analysts. These include:
- 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.
- Mounting of sensitive or critical volumes to a container.
- Creation of a privileged container, or DaemonSet.
- Successful API requests from anonymous user.
- Successful API requests from unusual countries.
- Successful 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.
- To dynamically baseline which users can call which APIs.
The Kubernetes use cases are available out of the box and can be downloaded here:
IBM QRadar Container Content Extension
You can have a Kubernetes cluster onsite or on-cloud, and in this post we will go over the needed steps to ingest Kubernetes API logs from Amazon Elastic Kubernetes Service (Amazon EKS).
From AWS console, go to Amazon Container Services -> Amazon EKS -> Clusters
In my case, I only have one cluster as seen in this image:
Click update, and enable the audit logs (Kubernetes API logs) option, as following:
Going inside the log stream, we can see the kubernetes API logs already being saved there: