Role-based access control (RBAC) is a method of regulating access to a 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 namespaces
Define permissions on namespaced resources and be granted across all namespaces
Define permissions on cluster-scoped resources
Roles are used to define API access rules for resources within the namespace of the role, and ClusterRole is used to define API access across all cluster namespaces.
Alcide’s rbac-tool viz
Alcide’s rbac-tool, an open-source tool from Alcide, introduces a visualization functionality of the relationships between the resources that make your cluster RBAC configuration.
The diagram above captures the various relationship combinations between resources.
Roles - Defines the policy rules that constitute which API actions (read/create/update/delete) the subject (user/service) is allowed to perform on resources within the namespace resources.
ClusterRoles - Defines the policy rules that constitute which API actions (read/create/update/delete) the subject (user/service) is allowed to perform on resources cluster-wide.
Bindings, are the Kubernetes RBAC resources that define the link between principals (users of automated services).
Bindings can point to multiple Roles:
RoleBindings can point to ClusterRoles which grants the subject (user/service) cluster-wide access to the resources specified in the rules.
ClusterRoleBindings can point to ClusterRoles which grants the subject (user/service) cluster-wide access to the resources specified in the rules.
Nginx Ingress Controller RBAC
The following diagram shows the moving parts of the RBAC resources created by an Nginx Ingress Controller.
You can see 2 roles were created:
A role that defines the allowed resources access within the namespace
ClusterRole defines the cluster-wide access permissions
Note for example that the ClusterRole grants Nginx-ingress account to
Update the resource status of ingress within the extensions and networking.k8s.io API group.
The above visualization was generated by running the following command:
$ rbac-tool viz --include-subjects="nginx-ingress"
Under the hood, Alcide’s rbac-tool connects to the cluster context pointed by your kubeconfig , lists the various RBAC related resources, and visualize the resources based on the command line filters.
Example: API access for system:unauthenticated Group on GKE
$ rbac-tool viz --include-subjects="system:unauthenticated"
Example: GCP permission covered cloud-provider ServiceAccount for GKE
$ rbac-tool viz --include-subjects="^cloud-provider" --exclude-namespaces=""
Conclusion
Kubernetes RBAC is a critical component in your Kubernetes deployment, which is definitely something cluster operators and builders must master.
Alcide’s rbac-tool visualization and filtering capabilities helps to unfold and simplify Kubernetes RBAC.
Top comments (0)