Kubernetes RBAC
The Kubernetes API provides access to sensitive data, including deployment details, persistent storage settings, and secrets. Over the years, the Kubernetes community has provided several important security features to the Kubernetes API, including role-based access control (RBAC).
Role-based access control (RBAC) is a way of granting users granular access to Kubernetes API resources. RBAC is a security design that restricts access to Kubernetes resources based on the role the user holds.
API Objects for configuring RBAC: Role, ClusterRole, RoleBinding and ClusterRoleBinding.
Role/ClusterRole only say what can be done, while who can do what is defined in a RoleBinding/ClusterRoleBinding.
Role
Role defines what can be done to Kubernetes Resources.
Role contains one or more rules that represent a set of permissions.
Permissions are additive. There are no deny rules.
Roles are namespaced, meaning Roles work within the constraints of a namespace. It would default to the default namespace if none was specified.
After creating a Role, you assign it to a user or group of users by creating a RoleBinding.
ClusterRole
ClusterRole works the same as Role, but they are applied to the cluster as a whole.
ClusterRoles are not bound to a specific namespace. ClusterRole give access across more than one namespace or all namespaces.
After creating a ClusterRole, you assign it to a user or group of users by creating a RoleBinding or ClusterRoleBinding.
ClusterRoles are typically used with service accounts.
Default ClusterRole:
cluster-admin: Cluster wide super user.
admin: Full access within a Namespace.
edit: Read/write within a Namespace.
view: Read-only within a Namespace.
RoleBinding
Role Binding is used for granting permission to a Subject.
RoleBinding holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted.
Role and RoleBinding are used in namespaced scoped.
RoleBinding may reference any Role in the same namespace.
After you create a binding, you cannot change the Role or ClusterRole that it refers to. If you do want to change the roleRef for a binding, you need to remove the binding object and create a replacement.
ClusterRoleBinding
ClusterRole and ClusterRoleBinding function like Role and RoleBinding, except they have wider scope.
RoleBinding grants permissions within a specific namespace, whereas a ClusterRoleBinding grants access cluster-wide and to multiple namespaces.
ClusterRoleBinding is binding or associating a ClusterRole with a Subject (users, groups, or service accounts).
Elements in RBAC Definition
Subjects
Subjects are nothing but a group of users, services, or team making an attempt at Kubernetes API. It defines what operations a user, service, or a group can perform.
Users: These are global, and meant for humans or processes living outside the cluster.
Groups: Set of users.
Service Accounts: Kubernetes uses service accounts to authenticate and authorize requests by pods to the Kubernetes API server. These are namespaced and meant for intra-cluster processes running inside pods.
Verbs
The set of operations that can be executed to the resources are called verbs. For examples, different verbs are get, watch, create, delete. Ultimately all of them are Create, Read, Update or Delete (CRUD) operations.
Resources
The set of Kubernetes API Objects available in the cluster are called Resources. For examples, Pods, Deployments, Services, Nodes, PersistentVolumes etc.