duyne

    Enforcing RBAC on Kubernetes

    • gcp

    Small world. Big idea!

    Control your role!

    For example, you might want to restrict access to production systems to a handful of individuals. Or you might want to grant a narrow set of permissions to an operator deployed in the cluster. The Role-Based Access Control (RBAC) framework in Kubernetes allows you to do just that.

    Overview of RBAC on Kubernetes

    The Kubernetes RBAC implementation revolves around four main object types:

    • Roles: Define a set of permissions within a namespace.
    • RoleBindings: Associate roles with users, groups, or service accounts within a namespace.
    • ClusterRoles: Similar to roles, but apply across the entire cluster.
    • ClusterRoleBindings: Associate cluster roles with users, groups, or service accounts across the entire cluster.

    Making sense of Roles, RoleBindings, ClusterRoles, and ClusterBindings

    At a high level, Roles and RoleBindings are placed inside and grant access to a specific namespace, while ClusterRoles and ClusterRoleBindings do not belong to a namespace and grant access across the entire cluster.

    However, it is possible to mix these two types of resources. For example, what happens when a RoleBinding links an account to a ClusterRole? Let's explore this next with some hands-on practice.

    Roles & Role Bindings

    We have a Kubernetes namespace called development and we want to grant permissions to a user named developer to manage pods within that namespace

    Role Example

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-manager
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]

    👉 This role pod-manager allows the developer to get, list, create, and delete pods within the development namespace.

    RoleBinding Example

    apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-manager-binding
  namespace: development
subjects:
- kind: User
  name: developer
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-manager
  apiGroup: rbac.authorization.k8s.io

    This role binding pod-manager-binding binds the pod-manager role to the developer user within the development namespace.

    Cluster Roles & Cluster Role Bindings:

    Let’s consider a scenario where we want to grant permissions to view nodes across the entire cluster to a group named ops-team.

    ClusterRole Example

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list"]

    This cluster role node-viewer allows the ops-team group to get and list nodes across the entire cluster.

    ClusterRoleBinding Example

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: node-viewer-binding
subjects:
- kind: Group
  name: ops-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

    This cluster role binding node-viewer-binding binds the node-viewer cluster role to the ops-team group, allowing them to view nodes across the entire cluster.

    In summary, roles & role bindings are used to manage permissions within namespaces, while cluster roles & cluster role bindings are used to manage permissions across the entire cluster.

    Conclusion

    Most Kubernetes clusters are now created on Cloud providers. In other words, accessing the cluster on the Cloud environment is quite easy.