Identity Management is a Vital Part of Cloud Security
As a container orchestrator, Kubernetes has taken off. Its security provides an open-source system for automating containerized applications through deployment and management. And, despite Kubernetes lacking native functionality to handle typical security functions, it offers excellent Role-based Access Control (RBAC). Through a built-in and required RBAC framework, Kubernetes enforces user access policies based on defined roles.
What is Role-Based Access Control (RBAC)?
Kubernetes RBAC offers fundamental security control to ensure that any cluster user or workload can access only those resources appropriate to carry out their role. With their level of access, users can perform specific tasks like viewing, creating, or modifying particular files.
In RBAC language, roles comprise user groups with similar characteristics that may relate to their department, business unit location, seniority or job level, or functional duties. Using the Kubernetes API (rbac.authorization.k8s.io) enables authorization decisions, enabling administrators to configure permission policies dynamically. Essential to role-based access includes having policies and definitions that clearly reflect employee functionality needs. Privileges should be adequate and appropriate based on the nature of those role groups.
Assigning permissions for role groups should address the following:
- Which materials are accessible by whom?
- What operations can each role carry out, including read, write, create, delete?
- What rules relate to each session, including log-out time?
According to the National Institute of Standards and Technology (NIST), four RBAC subtypes help clarify role levels that each user or group may require, including:
- Flat – users with at least one role at the most standard or primary level.
- Hierarchical – users at higher or more senior levels may have specific or more complete access.
- Constrained – users are separated by duties, projects, or time-related needs.
- Symmetrical – user permissions change as roles and needs change.
Role-based Access Control is different in Kubernetes compared to other frameworks in a few key ways. It defines human user access as user accounts; however, RBAC can also govern software behavior for service accounts. This instance of RBAC manages access to “resources,” which can include a host of artifacts like containers, logs, or controllers. Kubernetes RBAC goes beyond broad controls like read, write, and execute to enable specific access actions.
How is RBAC Different from ABAC?
Both RBAC and attribute-based access control (ABAC) work to set and enforce permissions, but there are distinctions worth exploring. Using ABAC, administrators can assign permissions based not only on the user’s role (similar to RBAC with seniority or duties) but also on the resource attributes, like file type or data sensitivity, and environmental attributes, like access location and date or time of access.
While RBAC provides simple rules to govern access, ABAC provides more varied and sophisticated levels of access policy. RBAC can create too many roles, bogging its simplicity; ABAC can be time-consuming to fix if initially misconfigured.
Choosing between or combining RBAC and ABAC capabilities depends on the identity management and security use cases a team encounters most often.
RBAC tends to work best in the following scenarios:
- Small teams, companies, or workgroups
- Defining access by roles are clear, and the most straightforward route
- Seniority or hierarchy primarily influences access
ABAC tends to work best in the following scenarios:
- Teams, business units, or workgroups are distributed across multiple locations
- Workgroups are time-bound, where document access must be more or less accessible around particular times or time zones
- Work is more defined by the types of documents versus the role or functions of the users
Regardless of the framework, there are best practices that should govern access control, particularly role-based.
RBAC Best Practices
General good practice suggests that IT or security administrators take the following steps to implement and configure Role-based Access Control with the most flexibility for the desired security level.
The Principle of Least Privilege recommends that a user be given the exact access rights necessary to execute their role’s responsibilities—no more and no less. In Kubernetes, each cluster may need to follow specific technical configurations to ensure accurate access, including assigning permissions down to the namespace level or using cluster-admin accounts in rare cases.
Don’t stop at Kubernetes defaults because they can provide too much access to particular clusters. Review RBAC rights to ensure security hardening. Particularly with default service accounts, creating service-specific service accounts is better suited to provide granular access controls.
Keep privileged tokens privileged by avoiding assigned service accounts to pods. Instead, handle formidable permissions by limiting the number of nodes running those pods or avoid running them simultaneously with publicly-exposed pods that aren’t trusted.
Audit Kubernetes RBAC settings and policies consistently to uncover any redundant entries or possible privilege levels that are no longer appropriate. Ensure user lists are automatically culled when an employee is promoted or leaves. Policies can over-permission over time, so periodic reviews of roles, rolebindings, clusterroles, and clusterrolebindings are essential.
Leverage Kubernetes Default RBAC Capabilities But Don’t Stop There
Depending on an organization’s structure, the nature of their user roles, and the types of files various roles interact with, roles-based access control in Kubernetes provides a straightforward, policy-driven approach to access management. A hybrid system of RBAC and ABAC can provide high-level access and fine-grained controls to meet the varied needs of a small or large enterprise.
Modern Cloud-Native Security Starts with Panoptica
Cisco’s Emerging Technologies and Incubation (ET&I) team is paving the way with “DevOps-friendly” cloud-native security solutions that fundamentally simplify conventional offerings. Our Panoptica solution simplifies cloud-native application security, making it easy to embed into the software development lifecycle. Panoptica protects the full application stack from code to runtime by scanning for security vulnerabilities in the cloud infrastructure, microservices (Containers or Serverless), the software bill of materials, and the interconnecting APIs. And best of all, it integrates with the tools that your application development and SecOps teams are already using. Try Panoptica for free!
