Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

A first of its kind survey looks at the relationship between open-source and K8s security. Today DevOps and security teams who deploy Kubernetes are forced to make a difficult choice between two security realities. They can either commit to a proprietary solution that they can’t adapt, access its code, influence the roadmap or contribute to its future. Or they can use open-source tools. But then they’ll end up attempting to integrate several of these tools together.

Modern containerized applications are increasingly born in the cloud and the big three managed Kubernetes services – Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE) – rule the skies. With more users picking managed services in public cloud as their preferred platform, self-managing a backup infrastructure in the cloud is an antithesis.

Kubernetes clusters consist of multiple resources and API objects interacting dynamically—which typically makes cluster management via the CLI overwhelming. Kubernetes Dashboard was built to simplify cluster operations by providing a unified, human-friendly interface. The web-based dashboard enables cluster operators to deploy applications, access running workloads, and correlate logs with cluster events. This article demonstrates how to install and use Kubernetes Dashboard.

Kubernetes uses secret objects, called Secrets, to store OAuth tokens, secure shell (SSH) keys, passwords, and other secret data. Kubernetes Secrets allow us to keep confidential data separate from our application code by creating it separately from pods. This segregation, along with well-formed role-based access control (RBAC) configuration, reduces the chances of the Secret being exposed — and potentially exploited — when interacting with pods, thereby increasing security.

As innovations in the world of application development and data computation grow every year, the “attack surface” of these technologies grows as well. The attack surface has to be understood from two sides—from the attacker’s side and from the organization being attacked.

Helm is being used broadly to deploy Kubernetes applications as it is an easy way to publish and consume them via a couple of commands, as well as integrate them in your GitOps pipeline. But is Helm secure enough? Can you trust it blindly? This post explains the benefits of using Helm, the pitfalls, and offers a few recommendations for how to secure it. Let’s get started!

Cyber attacks are an unfortunate reality in our interconnected world. The art of keeping up with malicious actors is challenging, but even more so with the move to cloud-native technologies. As a result, security is evolving. Developers, DevOps, and cloud teams must now learn a new set of best practices that balance shift-left and shield-right security approaches to reduce risk. There has never been a more critical time to revisit your cybersecurity strategy.

Many of the benefits of running Kubernetes come from the efficiencies that you get when you share the cluster – and thus the underlying compute and network resources it manages – between multiple services and teams within your organization. Each of these major services or teams that share the cluster are tenants of the cluster – and thus this approach is referred to as multi-tenancy.