eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The quest to enable autonomous vehicles involves many moving parts and a whole lot of software. Among the software components used by General Motors’ Cruise Automation division is the open-source Kubernetes cloud-native platform.
Cruise isn’t just consuming Kubernetes as a project, it’s also expanding it and helping to improve security policy control with a project called RBACSync. RBAC, or Role Based Access Control, is a key security component of Kubernetes, and by default it doesn’t quite work in the way that Cruise needs it to work. In true open-source fashion, Cruise engineers built the RBACSync project and have open-sourced it, enabling broader usage and participation.
“Kubernetes is used to run most server-side workloads at Cruise,” Stephen Day, senior software engineer for the Infrastructure Engineering Team at Cruise, told eWEEK. “This includes ride dispatch, mapping, data processing and fleet management.”
Kubernetes is an open-source platform first developed by Google that has been at the core of the Cloud Native Computing Foundation (CNCF) since the organization was founded in July 2015. Kubernetes is a container orchestration system, which enables organizations to provision, manage, deploy and run containers across distributed systems. Kubernetes benefits from a diverse set of adopters and contributing organizations and is supported on all the major public cloud providers. On March 25, the Kubernetes 1.14 platform was released, integrating support for Windows nodes.
Kubernetes at Cruise
While Kubernetes is part of the Cruise development and infrastructure stack, it doesn’t actually go into autonomous vehicles.
“We do not use Kubernetes on the vehicle, but the vehicle does talk to services running on Kubernetes,” Day said.
Cruise makes use of the Google Kubernetes Engine as its platform provider, which integrates the core Kubernetes RBAC capabilities that enable operators to define roles for operations. The roles are then connected to resources in an approach known as “role binding” that enables policy-based access control. The challenge for Cruise was that there is a gap in defining how users belong to groups within the Kubernetes RBAC approach. Day said that while the core Kubernetes project does have capabilities for adding individuals to groups, there are some limitations that caused issues for Cruise.
“Our approach allows us to decouple the identity provider and group membership, giving us the ability to change where they come from and how the groups are formed,” Day explained. “As long as we have strong identity coming into the cluster, we can map the groups according to our requirements.”
RBACSync benefits from a core capability within Kubernetes known as a controller, which enables new capabilities to be added to the platform. The RBACSync controller looks at configurations within a Custom Resource Definition (CRD) attached to Kubernetes that identifies group and role references. Whenever a change occurs, the system creates a role binding with the group for RBAC policy.
“By following conventions in the existing RBAC system, RBACSync fits into what is already there,” Day said. “It can seamlessly use existing roles, including those defined by other projects and Helm charts. Our goal was to push RBAC as far as possible, then work from there.”
Open-Source Contribution
In publicly announcing RBACSync as an open-source effort, Cruise is looking to both help itself and others. Day noted that Cruise just released version 1.1 of RBACSync that had some stability fixes and support for binding out to cluster roles.
“Our goal was to give something back that might be useful to others and see where that takes us,” he said. “We hope that others will pick it up in their infrastructure and add support for new upstreams or different scenarios.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.