Tapping into the robust, scalable nature of Kubernetes to apply those attributes to security enables you to invoke controls with lower operational risk than applying container controls outside of Kubernetes. In addition, having controls embedded directly in Kubernetes removes the risk of having separate control software that, in the event of a failure, would either fail open and allow all traffic with no security enabled or fail closed and break all application traffic.
Scale your enforcement
Having the orchestrator, and not separate control software, enforce policy controls means security immediately gains all the scalability of Kubernetes itself as well as the range of policy enforcement options it includes. In contrast, using inline proxies or shims for enforcement introduces single points of failure, scalability challenges, and performance limitations.
With Kubernetes, you can, for example, apply network policies to segment your traffic, Admission Controllers to apply policies to requests going to the Kubernetes API server, secrets for storing sensitive credentials, and Role-based Access Control (RBAC) to authorize certain capabilities for certain users and service accounts. You can also use additional standardized tools, such as network plugins that adhere to the Container Network Interface (CNI) in conjunction with the Kubernetes-native security platform and change those additional tools as needed.
Eliminate operational conflict
Kubernetes-native security helps reduce operational issues that stem from inconsistent configurations, lack of coordination, and user errors.
When DevOps and Security teams are using different tools, it’s easy for conflicts to arise in how they’re configured. DevOps may specify a Kubernetes network policy allowing traffic between two nodes, and security could introduce a control via separate control software that blocks that traffic. Looking at the settings in Kubernetes would show DevOps that the application should be working with traffic flowing, and they could easily have no idea why the app is failing, because they cannot see the controls exerted by the separate control software.
Kubernetes-native security treats Kubernetes as the source of truth for security policies, and everyone — security, operations teams, DevOps, and site reliability engineering (SRE) teams — will all be working off that same source of truth. In addition, security issues map directly to the Kubernetes objects and resources these teams use daily, further simplifying operations.
Avoid the operational risk that comes with implementing out-of-band security by leveraging Kubernetes-native enforcement for your security policies.
Last updated: May-30-2020