In this blog, we introduce the new integration between Sysdig Secure and Red Hat® Advanced Cluster Management for Kubernetes that protects containers, Kubernetes, and cloud infrastructure with out-of-the-box policies based on the Falco open-source runtime security project. Organizations are quickly growing their Kubernetes footprint and need ways to achieve consistent management and security across clusters.

If you’re running containers and Kubernetes on IBM Cloud, you can now enable the key security workflows of Sysdig Secure as a service within your IBM Cloud deployments. This makes it easier for you to implement security tools and policies to ensure your containers and your Kubernetes environment are protected and running as intended. The new container and Kubernetes security features are integrated into IBM Cloud Monitoring with Sysdig and offered as an additional service plan.

Microservices and Kubernetes have completely changed the way we reason about network security. Luckily, Kubernetes network security policies (KNP) are a native mechanism to address this issue at the correct level of abstraction. Implementing a network policy is challenging, as developers and ops need to work together to define proper rules. However, the best approach is to adopt a zero trust framework for network security using Kubernetes native controls.

In support of modern application development built on CI/CD, containers and open source, Google Cloud launched Artifact Registry (now generally available), a new artifact management solution. Sysdig helps DevOps teams using Artifact Registry confidently secure the build pipeline with comprehensive image scanning that identifies container vulnerabilities and misconfigurations to reduce risk.

The control plane is the brain and heart of Kubernetes. All of its components are key to the proper working and efficiency of the cluster. Monitor Kubernetes control plane is just as important as monitoring the status of the nodes or the applications running inside. It may be even more important, because an issue with the control plane will affect all of the applications and cause potential outages.

The most common problems and outages in a Kubernetes cluster come from coreDNS, so learning how to monitor coreDNS is crucial. Imagine that your frontend application suddenly goes down. After some time investigating, you discover it’s not resolving the backend endpoint because the DNS keeps returning 500 error codes. The sooner you can get to this conclusion, the faster you can recover your application.

This article contains useful tips to implement SOC 2 compliance for containers and Kubernetes. The Service Organization Controls (SOC) reports are the primary way that service organizations provide evidence of how effective their controls are for finance (SOC 1) or securing customer data (SOC 2, SOC 3). These reports are issued by the American Institute of Certified Public Accountants (AICPA).

While auditing the Kubernetes source code, I recently discovered an issue (CVE-2020-8566) in Kubernetes that may cause sensitive data leakage. You would be affected by CVE-2020-8566 if you created a Kubernetes cluster using ceph cluster as storage class, with logging level set to four or above in kube-controller-manager. In that case, your ceph user credentials will be leaked in the cloud-controller-manager‘s log.