Kubernetes Role-Based Access Control (RBAC) provides the standard method for managing authorization for the Kubernetes API endpoints. Your cluster’s RBAC configuration controls which subjects can execute which verbs on which resource types in which namespaces. For example, a configuration might grant user “alice” access to view resources of type “pod” in the namespace external-api. The RBAC API includes four declarative objects:
Roles are a namespaced-resource consisting of
rules that set permissions for individual namespaces, whereas
ClusterRoles are non namespaced-resource that grant clusterwide permissions or permissions that span multiple namespaces. Each rule is a combination of verbs, resource types, and namespace selectors.
A role binding is the bridge that ties a user, group of users, or a service account (also known as subjects) to a role and grants those users the permissions defined in that role. A cluster role binding ties a
ClusterRole to all the namespaces in your cluster. In this way, a
RoleBinding assigns permissions within a namespace, whereas a
ClusterRoleBinding grants those permissions clusterwide.
Based on our experience with customers, we have discovered the following five most common mistakes to look for in RBAC configuration settings.
Configuration mistake 1: cluster administrator role granted unnecessarily
cluster-admin role grants unlimited access to the cluster. During the transition from the legacy ABAC controller to RBAC, some administrators and users may have replicated ABAC’s permissive configuration by granting
cluster-admin widely, neglecting the warnings in the relevant documentation. If users or groups are routinely granted
cluster-admin, account compromises or mistakes can have dangerously broad effects. Service accounts typically also do not need this type of access. In both cases, a more tailored Role or Cluster Role should be created and granted only to the specific users that need it.
Configuration mistake 2: improper use of role aggregation
In Kubernetes 1.9 and later, role aggregation can be used to simplify privilege grants by allowing new privileges to be combined into existing roles. However, if these aggregations are not carefully reviewed, they can change the intended use of a role; for instance, the
system:view role could improperly aggregate rules with verbs other than view, violating the intention that subjects granted
system:view can never modify the cluster.
Configuration mistake 3: duplicated role grant
Role definitions may overlap with each other, giving subjects the same access in more than one way. Administrators sometimes intend for this overlap to happen, but this configuration can make it more difficult to understand which subjects are granted which accesses. This situation can make access revocation more difficult if an administrator does not realize that multiple role bindings grant the same privileges.
Configuration mistake 4: unused role
Roles that are created but not granted to any subject can increase the complexity of RBAC management. Similarly, roles that are granted only to subjects that do not exist (such as service accounts in deleted namespaces or users who have left the organization) can make it difficult to see the configurations that do matter. Removing these unused or inactive roles is typically safe and will focus attention on the active roles.
Configuration mistake 5: grant of missing roles
Role bindings can reference roles that do not exist. If the same role name is reused for a different purpose in the future, these inactive role bindings can suddenly and unexpectedly grant privileges to subjects other than the ones the new role creator intends.
Properly configuring your cluster RBAC roles and bindings helps minimize the impact of application compromises, user account takeovers, application bugs, or simple human mistakes.
Last updated: May-31-2020