Over the past four years we’ve helped hundreds of organizations run reliable, secure, and compliant Kubernetes and Openshift clusters. Some of the key themes we’ve seen from organizations that have successfully grown their Kubernetes footprint are: they have immaculate labeling, understand how to leverage internal Kubernetes features to harden their platform, and understand what developers need access to and manage it with RBAC and namespaces. Even though you’ve probably seen all of these as best practices, being diligent that they always happen will take you a long way. In the 2.2 version of Sysdig Secure we’ve released a set of features with bidirectional integrations between your Kubernetes or Openshift cluster and Sysdig Secure. The data from Kubernetes helps the workflows in Sysdig Secure follow the same procedures you’d use within Kubernetes for access control and analysis. While the vulnerability and configuration data from Sysdig Secure allows Kubernetes to become more advanced in the prevention of unwanted images running on the cluster. Let’s dive into some of the new features in 2.2. Sysdig Secure 2.2 is out! Native #Kubernetes and #Openshift #security Click to tweet
Kubernetes audit events
Adds new detections based on audit data from the Kubernetes API
Sysdig is the first cloud-native security provider to tap the recently released Kubernetes Audit Policy, creating an additional feed of events to monitor. Virtually all cluster management tasks are done through the API server; therefore, the audit log contains all changes made to the cluster. By tapping the kube-apiserver, Sysdig can alert administrators of suspicious and notable behavior. These alerts help users quickly identify incidents that could negatively impact the business and lets operators answer who did what, where, and when.
File: Create-Modify-Configmap-With-Private-Credentials.yaml
-----------------------------------------------------------
- macro: contains_private_credentials
condition: >
(ka.req.configmap.obj contains "aws_access_key_id" or
ka.req.configmap.obj contains "aws-access-key-id" or
ka.req.configmap.obj contains "aws_s3_access_key_id" or
ka.req.configmap.obj contains "aws-s3-access-key-id" or
ka.req.configmap.obj contains "password" or
ka.req.configmap.obj contains "passphrase")
- rule: Create/Modify Configmap With Private Credentials
desc: >
Detect creating/modifying a configmap containing a private credential (aws key, password, etc.)
condition: kevt and configmap and kmodify and contains_private_credentials
output: K8s configmap with private credential (user=%ka.user.name verb=%ka.verb configmap=%ka.req.configmap.name config=%ka.req.configmap.obj)
priority: WARNING
source: k8s_audit
tags: [k8s]