RBAC or Role-based Access Control, is a key feature of Kubernetes (a.k.a. k8s) that provides access control by roles and role bindings. A role will be defined with a set of api_groups (“” for default, “apps”, “autoscaling”, “batch”, “extensions”, “networking.k8s.io”, “authentication.k8s.io”,”storage.k8s.io”,”certificates.k8s.io), resources (pods, deployments, namespaces, secrets, persistentvolumes, configmaps, nodes), and vebs (create, get, delete, list, update, edit, watch, exec). Here’s an example role in TF code:
resource "kubernetes_role_v1" "appdev-group" {
metadata {
name = "eks-app-dev-role"
namespace = "test1"
labels = {
}
}
rule {
api_groups = ["","apps","autoscaling","batch","extensions"]
resources = ["*"]
verbs = ["*"]
}
}
There are Roles and ClusterRoles. Roles are for more granular control and ClusterRoles are for cluster-wide permissions. Roles can be scoped to namespaces (e.g. “test1”). The above example is a role that grants full access to all resources in the test1 namespace via the api_groups listed. This means role does not grant access to any api that is not listed. Permissions are allow only there is not a “deny” feature in k8s RBAC.
A rolebinding assigns the given role to a set of subjects (user, groups, service accounts). There are RoleBindings and ClusterRoleBindings each are used to bind the appropriate role-type. Here’s an example of a rolebinding in TF code:
#Assign role
resource "kubernetes_role_binding_v1" "app-dev" {
metadata {
name = "app-dev-role-binding"
namespace = "test1"
}
role_ref {
api_group = "rbac.authorization.k8s.io"
kind = "Role"
name = "eks-app-dev-role"
}
subject {
kind = "User"
name = "eks-app-dev"
api_group = "rbac.authorization.k8s.io"
}
}
To have a rolebinding for more than one role, simply add additional “subject” section in the TF code.
After testing this with my first rolebinding and assigning to a namespace, it was very satisfying to see the permission settings work.
I you find this as interesting as I do.
Until next time,
Happy Building