At its heart, Kubernetes-native security relies on deep integrations with Kubernetes to pull in rich context and tap into the native controls of Kubernetes. This architecture improves security in two key ways: (1) providing rich context and insights; and (2) detecting Kubernetes-specific threats.
Kubernetes context and insights remove blind spots
Integrating with the Kubernetes API server provides security monitoring for both the containers running in Kubernetes clusters as well as Kubernetes resources such as Deployments, DaemonSets, Services, Pods, and other resources.
Kubernetes-native security provides visibility into the configuration not just of your containers but also your Kubernetes deployment. To understand your overall security posture, you must ensure that Kubernetes configurations such as role permissions, access to secrets, allowed network traffic, and the settings on the master components are locked down, follow best practices, and are scoped to the least-possible priviledges needed for your applications to run.
It’s also important to understand how — or if — your workloads are isolated. Kubernetes, by default, allows all deployments to talk to all other deployments, within and beyond their namespaces. Deep visibility into the network policy settings, preferably in a visual format vs. reading the text of a YAML file, will highlight which workloads are not isolated.
Kubernetes integrations reveal critical vulnerabilities and threat vectors
To be effective, container security platforms must identify vulnerabilities and threats to Kubernetes, not just your containers. Getting cluster-level access to Kubernetes essentially means getting the keys to the kingdom — malicious actions at this layer have a far greater reach across your environment.
Detecting Kubernetes-specific vulnerabilities, especially any that put the Kubernetes API server at risk, are especially crucial to prevent, identify, and remediate. Kubernetes-native security tooling can automatically identify these vulnerabilities.
IBM famously pioneered the research showing that 95% of security breaches were caused by human error. Kubernetes is no different from any other infrastructure in the need to identify and prevent such mistakes. Given the learning curve most users are on with Kubernetes, it’s easy to make mistakes, including granting elevated privileges using Kubernetes Role-based Access Controls (RBAC), such as giving a user or service account full cluster administrative permissions, or unnecessarily exposing Kubernetes secrets by enabling deployments to pull secrets even when they aren’t needed. Kubernetes-native security platforms identify these misconfigurations automatically and continuously, protecting this vital asset.
The wide-open nature of Kubernetes deployments presents another threat vector. Because Kubernetes is first and foremost a platform for infrastructure operations, all components are not necessarily secure by default for operational ease of use. Applying Kubernetes network policies to limit communications is another critical element in securing your Kubernetes deployments. Kubernetes-native security platforms can automatically baseline your network activity, identify which communications paths are needed to service your application, and create the correct YAML file to reduce network access scope.
By leveraging the automatic security settings in a Kubernetes-native platform, you’ll be able to continuously identify and stop threats at the Kubernetes layer.
Last updated: May-30-2020
- Kubernetes Networking Demystified: A Brief Guide
- Protecting Kubernetes API Against CVE-2019-11253 (Billion Laughs Attack) and Other Vulnerabilities
- 5 Kubernetes RBAC Mistakes You Must Avoid
- Guide to Kubernetes Egress Network Policies
- Guide to Kubernetes Ingress Network Policies