If you’re using Kubernetes to sell shoes, handle financial transactions, or host one of the most successful podcasts ever, you’ve found the revolutionary orchestration software to have a low barrier of entry, but probably didn’t initially see much in the way of security. Many bootstrapped clusters come with an all-powerful cluster-admin role, allowing a user to exercise all the functionality of Kubernetes without anything standing in the way. Users can typically run their first pods/containers in a matter of minutes. Many of these containers run as root, which is the norm within the Docker ecosystem, and allowing the containers to run without modification is useful early in the development process. Unfortunately, security is a real concern in modern software applications, and Kubernetes is no different. Application developers must understand the ever-changing and poorly-documented security requirements of the day or deployment environment, which may be orthogonal to the way the applications were designed.
Understanding the powerful Kubernetes-provided security and compliance primitives can inform and shape software development along with the configuration of production Kubernetes clusters. Like any large ecosystem, there are opportunities for misconfiguration. Implementation details that are not immediately obvious can have catastrophic effects. All is not lost – many of the most powerful built-in security features for running workloads are familiar to anyone who uses GNU/Linux, including support for standard discretionary access control (DAC) and more feature-rich capabilities such as SELinux. Kubernetes also provides opportunities for cluster administrators to inspect manifests applied to the API server (via kubectl or your existing tooling) before they are committed and alter the state of the running cluster. Access to the API is typically guarded by Role-based Access Control (RBAC), allowing subjects (users or service accounts) to execute only those operations for which they are authorized. When necessary, Kubernetes also allows for external validation of requests, allowing more strict security and compliance requirements to be met, and providing detailed information to users when rejecting invalid requests.
Justin Monroe provides an overview of the Kubernetes security landscape to help security teams and application developers understand available features. One of the focus areas of this talk is a deep-dive on using built-in workload security primitives to decrease the blast-radius of compromise, and embracing existing and well-understood GNU/Linux security mechanisms. The talk also provides an overview of writing secure RBAC policies and some gotchas about implementation details. Last, Justin provides a quick overview of detailed admission control in the form of policies running in Open Policy Agent, which can be self-documenting and version-controlled.
Whether you’re selling shoes, handling financial transactions, hosting one of the most successful podcasts ever, or supporting government customers in their missions, all business operations benefit from increased security. Kubernetes is not unique in this regard, and security is everyone’s responsibility.
Meet The Presenter
Justin Monroe is the Director of Emerging Technologies in the Cyber & Intelligence Market and a security-conscious application developer. He’s worked in a number of roles over his three-year employment with Parsons, including Software Engineer, Team Lead, Product Owner, and Technical Director. Prior to his time at Parsons, Justin supported a variety of customers and projects of all sizes and supported quick-reaction capability development in many of those roles. He prefers writing applications in C, Python, Go and has (at the direction of his coworkers) used Rust for some-side projects. When not working and socially distancing due to a global pandemic, Justin spends time with his wife and son, listens to podcasts, and works on a series of personal programming projects… so basically business as usual.