Role-based access control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within your organization. RBAC authorization uses the rbac.authorization.k8s.io API group to drive authorization decisions, allowing you to dynamically configure policies through the Kubernetes API.
Permissions are purely additive and there are no “deny” rules.
A Role always sets permissions within a particular namespace ; when you create a Role, you have to specify the namespace it belongs in. ClusterRole, by contrast, is a non-namespaced resource, and grants access at the cluster level. ClusterRoles have several uses.
You can use a ClusterRole to:
define permissions on namespaced resources and be granted within individual namespace(s)
define permissions on namespaced resources and be granted across all namespaces
define permissions on cluster-scoped resources
If you want to define a role within a namespace, use a Role; if you want to define a role cluster-wide, use a ClusterRole.
Default Cluster Roles
While Kubernetes RBAC is a complex topic, one would always want to implement RBAC in the cluster. For this purpose Kubernetes offers out-of-the-box default cluster roles that can be used as a starting point.
These are visible in the output of kubectl get clusterrole, and four cluster roles you can use right away are:
cluster-admin
admin
edit
view
With these roles, you can start to define who can interact with your cluster and in what way. It is highly recommended to follow the principle of least privilege, and grant additional privileges as necessary for work to proceed.
Kubernetes RBAC Resource Relationship
Example: Nginx Ingress Controller RBAC Policy
Explicitly Tuning RBAC Policies - ‘It's Complicated’
Components like Operators or highly privileged controllers that require Cluster wide ‘Read-Only’ but do not necessarily require to read secrets for example, may leave a user to take a shortcut and provision RBAC policy with excessive permissions.
Kubernetes RBAC additive model does not enable us to implement semantics that capture:
deny access to specific resource groups,
allow access to all other resources.
If we can have the explicit set of policy access rules of all cluster resources - and “subtract” from that group the resources we would like to deny access to - we achieve the above semantics.
Let’s how we can achieve that:
Run kubectl api-resources and get all of the cluster installed/supported resources and their respective api-groups
Derive the RBAC policy from the above list
Manually tune the policy and reduce any resource and/or api-groups that we wish to deny access to.
While this method will work, it’s manual, and takes significant effort.
An easier way to achieve this is with Alcide rbac-tool
rbac-tool - Simplify RBAC Policy Tuning
Alcide rbac-tool has the ability to address this exact use case.
Example: Generate a Role policy that allows create,update,get,list (read/write) everything except secrets, services, networkpolicies in core,apps & networking.k8s.io API groups
rbac-tool gen --generated-type=Role --deny-resources=secrets.,services.,networkpolicies.networking.k8s.io --allowed-verbs=* --allowed-groups=,extensions,apps,networking.k8s.io
The generated policy is cluster specific.
For a Kubernetes KIND cluster v1.16 the generated policy looks as follows:
Conclusion
Kubernetes RBAC helps us as users, to define and regulate API access to the Kubernetes cluster. In many cases where users wish to achieve even more granular controls, Validating Admission Controllers are the Kubernetes construct to achieve that. The Kubernetes ecosystem, and open-source tools such as Alcide’s rbac-tool help to unfold and simplify Kubernetes RBAC. get it here: https://github.com/alcideio/rbac-tool
Top comments (0)