Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Today, we announced that Sysdig is acquiring Apolicy to enable our customers to secure their infrastructure as code. I could not be more excited because the innovation that Apolicy brings to bear is unique and highly differentiated, allowing customers to strengthen their Kubernetes and cloud security and compliance by leveraging policy as code and automated remediation workflows that close the gap from source to production.

We’re constantly told to “Shift Left” and that Secure DevOps is the only way to have confidence in your cloud native applications. But speaking to end-users and industry colleagues, it’s clear that there are some major challenges in adopting Secure DevOps. If we read our history books, we know that DevOps wasn’t successfully adopted by buying tools, and a true cultural movement towards DevOps wasn’t established by having a small dedicated team of DevOps specialists.

In this blog post, I will be looking at 10 best practices for Kubernetes security policy design. Application modernization is a strategic initiative that changes the way enterprises are doing business. The journey requires a significant investment in people, processes, and technology in order to achieve the desired business outcomes of accelerating the pace of innovation, optimizing cost, and improving an enterprise’s overall security posture.

If you’re doing open source development today, chances are high that you’re active within the GitHub community — participating in open source projects and their repositories. A recent addition to the GitHub ecosystem is GitHub Packages, which was announced back in 2019 and is now receiving even more updates with the general availability of the GitHub Packages container registry.

In Kubernetes, the task of scheduling pods to specific nodes in the cluster is handled by the kube-scheduler. The default behavior of this component is to filter nodes based on the resource requests and limits of each container in the created pod. Feasible nodes are then scored to find the best candidate for the pod placement. In many scenarios, scheduling pods based on resource constraints is a desired behavior.

Misconfigurations in infrastructure as code (IaC) can be just as dangerous as vulnerabilities in code. Small mistakes in configuration can lead to the sensitive data being readable on the internet, or private endpoints and dashboard accessible to the anonymous users and abused as the initial point of compromise. Recent security research findings indicate the rise in malware targeting the Kubernetes platform which showcases the need for secure configuration.

When you start scanning your container images, it can be disconcerting to discover that you have large numbers of vulnerabilities. Below is a scan I did last week on a vulnerable node image that I built. While a fairly extreme example, you can see that this image out of the box is showing as having over 800 vulnerabilities in it.

Container orchestration platform Kubernetes announced in December 2020 that its third and final release, Kubernetes v1.20, would deprecate dockershim and subsequently Docker as a container runtime. This deprecation has brought multiple changes that admins must be aware of and accordingly respond to.

Microsoft has discovered a new large-scale attack targeting Kubeflow instances to deploy malicious TensorFlow pods, using them to mine Monero cryptocurrency in Kubernetes cluster environments. Kubeflow is a popular open-source framework often used for running machine learning tasks in Kubernetes. TensorFlow, on the other hand, is an open-source machine learning platform used for implementing machine learning in a Kubernetes environment.