Version 1.8 of the open-source Kubernetes container orchestration and management platform is now available, providing features that improve both scalability and security.
Kubernetes 1.8, released on Sept. 28, is the third major milestone release for Kubernetes in 2017 and follows the 1.7 update that debuted in June. The Kubernetes project was originally started by Google and has been managed as a Cloud Native Computing Foundation (CNCF) effort since July 2015.
Among the key highlights in Kubernetes 1.8 is role-based access control (RBAC), which is now considered a stable technology. RBAC had been a beta technology since the Kubernetes 1.6 release in March 2017.
“All major new features in Kubernetes proceed through three stages—Alpha, Beta, Stable—across select releases,” Joe Brockmeier, Linux container strategist at Red Hat, told eWEEK. “Stable is the final stage, when a feature is considered ready for general production use.”
RBAC technology links users and entity roles with the required level of access to a given component. In Kubernetes, RBAC determines API access of users, groups and service accounts, according to Eric Chiang, software engineer at CoreOS.
“Users and groups can originate from a variety of sources, including user management systems like Active Directory,” Chiang told eWEEK.
The RBAC implementation in the upstream open-source Kubernetes project, however, doesn’t natively understand all of the various protocols used by identity providers, including LDAP (Lightweight Directory Access Protocol) and SAML (Security Assertion Markup Language). To help bridge that gap, CoreOS has built an open-source project called Dex.
“Dex is a shim between Kubernetes and user management systems like Active Directory that lets users authenticate to Kubernetes based on their corporate identity,” Chiang said. “RBAC then determines what those users can do inside Kubernetes.”
Part of the Kubernetes 1.8 RBAC implementation is an integration with escalation prevention capabilities to help further reduce security risks. Privilege escalation is a commonly used attack vector in security breaches.
“Users can only create or update roles if they already have the permissions that would apply to the role,” Brockmeier said. “So if a user doesn’t have the permission to do something, they can’t create a role with the permissions to do that either—i.e., they can’t escalate their permissions.”
Auto-Scaling
A key orchestration capability is providing container users with methods to manage and scale resources based on demand. The 1.8 release improves the ability to automatically scale and grow a Kubernetes container cluster thanks to the Horizontal Pod Auto-scaling feature that now provides new options on how and when to scale a Kubernetes pod.
“Previously, HPA was supported only based on CPU usage,” Brockmeier said. “The new HPA API supports custom metrics—so this expands the possibilities for auto-scaling on other usage metrics.”
Auditing
Looking beyond just the stable features, Kubernetes 1.8 provides a preview of a new advanced auditing capability.
As part of the CNCF, there is already a monitoring project called Prometheus that is used to monitor, debug and create alerts based on the performance and health of applications. In contrast, Chiang said auditing is used to track specific actions taken by users and service accounts.
“Prometheus might be good for answering questions like, ‘Why is my web server slow?'” he said. “Auditing is intended to answer questions like, ‘Who last modified this secret?'”
Another key security capability that is not yet stable in Kubernetes is encryption for resources at rest, which is currently considered to be an alpha feature.
“The 1.8 cycle added better encryption at rest options for resources like secrets, including integrations with external Key Management Services [KMS],” Chiang said. “Since these features are still Alpha, they represent good progress for Kubernetes, but shouldn’t be depended on by users.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.