RBAC Authz
最后更新于
最后更新于
Kubernetes now support Role-Based Access Control (RBAC) as of version 1.6, providing administrators more precise access control over resources associated with user or service accounts. The exciting thing with RBAC is permissions are tied to roles, and users are granted authority through their affiliation with specific roles, hugely simplifying management.
The key here is roles are created to accomplish various tasks within an organization, and users are assigned certain roles based on their responsibilities and qualifications. Users can effortlessly be assigned from one role to another, providing flexibility.
One of the highlights of Kubernetes 1.6 is the upgrade of RBAC to beta status (version rbac.authorization.k8s.io/v1beta1). RBAC is the tool used to manage resource access permissions in a Kubernetes cluster. Notably, RBAC aids in refreshing access authorization policies without the need to reboot the cluster.
Starting with Kubernetes 1.8, RBAC entered a stable release; its API is rbac.authorization.k8s.io/v1. Usage of RBAC is simple by initiating the kube-apiserver with the --authorization-mode=RBAC configuration.
Kubernetes now has a range of authorization mechanisms in action. They determine a user's authority to perform certain actions on the Kubernetes API. They not only affect components like kubectl but also influence the operation of internal cluster software, like a Jenkins setup with Kubernetes plugin or Helm which utilizes the Kubernetes API for software deployment. ABAC and RBAC both can configure access policies.
ABAC (Attribute-Based Access Control) is an excellent concept, but implementing it in Kubernetes has proven a little tricky, particularly concerning management and comprehension. It requires SSH and filesystem permissions on the Master node, and to implement an authorized change, the API Server needs to be restarted.
RBAC authorization policies, on the other hand, can be set directly using kubectl or Kubernetes API. In RBAC, users can be given the right to manage authorizations, allowing for authorization management without directly touching the nodes. In Kubernetes, RBAC is mapped to API resources and operations.
Due to the Kubernetes community's preference and investment, RBAC is a superior option in comparison to ABAC.
A better understanding of the underlying concepts and attributes of RBAC as the go-to authorization method for Kubernetes API resources is needed.
RBAC defines two objects to analyze the connection between user and resource permissions.
Role is an aggregate of permissions––for instance, a role might include permissions to read and list Pods. Role is used for authorization for resources within a specific namespace. For multiple namespaces and cluster-level resources or non-resource API (like /healthz), ClusterRole is used.
Role examples:
ClusterRole examples:
RoleBindings map the permissions of a role (Role or ClusterRole) to a user or user group, thus endowing these users with the role privileges within a namespace. ClusterRoleBindings extend a user the prerogatives of a ClusterRole across the entire cluster.
Note the username format for ServiceAccount is system:serviceaccount:<service-account-name>, all under user group system:serviceaccounts:.
RoleBinding example (references Role):
RoleBinding example (references ClusterRole):
Starting with v1.9, ClusterRoles can now be used in aggregate with other ClusterRoles via the aggregationRule (feature went GA in v1.11).
For example
RBAC is deeply integrated into Kubernetes and authorizes its system components. System Roles typically start with system:, making them easy to identify:
Other inbuilt roles can be referred to in default-roles-and-role-bindings.
RBAC system roles provide sufficient coverage for the cluster to operate under RBAC management entirely.
In a shift from ABAC to RBAC, some permissions seen as 'open package' in ABAC are considered extraneous in the RBAC model and are subsequently downgraded. This will likely impact applications using Service Account. In ABAC settings, requests from the Pod utilize the Pod Token and the API Server grants it higher privileges. In RBAC, however, the below command would return an error instead of a JSON result.
All applications running on a Kubernetes cluster might be impacted if they communicate with the API Server.
You can smoothly upgrade from ABAC to RBAC by enabling both ABAC and RBAC simultaneously when setting up the 1.6 cluster. When both are enabled, resource permission requests are approved if either RBAC or ABAC gives a green signal. However, the permissions are too extensive in this configuration, and RBAC might not work independently.
While RBAC is now in a stable release, ABAC may be deprecated. It's likely ABAC will be retained in Kubernetes in the foreseeable future, but development focus is largely shifted to RBAC.
Permissive RBAC is a specific configuration that grants all Service Accounts administrator privileges. Note, it's generally not a recommended setup.
For access rights to namespace resources, use Role and RoleBinding
For access to cluster-level resources or specific resources across all namespaces, use ClusterRole and ClusterRoleBinding
For access to specific resources across several namespaces, use ClusterRole and RoleBinding
