DEV Community

Gadi Naor for Alcide

Posted on

Kubernetes RBAC Visualization

Alt Text

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.

Alt Text

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.

Alt Text

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

Alt Text

$ rbac-tool viz --include-subjects="system:unauthenticated"

Example: GCP permission covered cloud-provider ServiceAccount for GKE

Alt Text

$ 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)