🛃Custom Roles
Preset roles in rbac-manager are designed for ease and efficiency. However, custom roles become your go-to solution when your access control requirements demand specificity. It allows you to define access rules with exceptional precision. Whether it's read or write access, resource-specific permissions, or complex scenarios, custom roles give you complete control over who can do what within your Kubernetes clusters. The following capabilities provide you with the flexibility you need to craft access policies that align perfectly with your requirements:
denyResources:
This feature lets you specify the Kubernetes resources that should be explicitly denied access. This allows you to create strict controls and block access to specific resources.
Example Use Case: Restricting Secrets Management
Imagine a scenario where you need to grant users full access to the cluster but prevent them from managing one resource, say secrets. With rbac-manager, achieving this level of control is straightforward. You can create a Custom Resource Definition (CRD) like the one below:
apiVersion: rbac-manager.k8smgmt.io/v1
kind: RBACPolicy
metadata:
name: tc007-custom-rbac
spec:
version: 1.0.0
namespaceCreatePolicy: "IfNotPresent"
customClusterRoles:
- name: deny-secret
denyResources:
- secrets
allowedVerbs:
- "*" # for other resources
customRbacBindings:
- name: bind-robot-sa
subjects:
- kind: ServiceAccount
namespace: app
name: robot
clusterRoleBindings:
- clusterRole: deny-secretIn this example, the deny-secret Custom Cluster Role is configured to deny access to the secrets resource while permitting full access to all other resources. This specific binding ensures that the user, represented by the ServiceAccount named robot in the app namespace is prevented from managing secrets but has full access to all the other resources in the cluster.
Inspect the ClusterRole and ClusterRoleBinding created by rbac-manager for the above CRD using the commands below.
When you run the above commands, you'll witness the rbac-manager's remarkable capability in action. It automatically identifies and includes all available resources within the cluster while crafting a ClusterRole that encompasses whitelisting rules for each resource. It's important to note that it excludes the secret resource, thus ensuring a comprehensive access policy.
The alternative of manually crafting such extensive YAML specifications for RBAC can be daunting and error-prone. rbac-manager streamlines this process, making complex access control manageable and accurate, ultimately enhancing the security and manageability of your Kubernetes environment.
allowedResources:
allowedResources enables you to specify the Kubernetes resources that should be granted access. Whether it's pods, services, or other resources, you can define exactly what can be accessed.
Example Use Case: Grant Access To pods.
Imagine a scenario where you need to grant users access to only manage pods in the cluster. With rbac-manager, achieving this level of control is straightforward. You can create a Custom Resource Definition (CRD) like the one below:
In this example, the allow-pods Custom Cluster Role is configured to grant access to specific pods resources and subresources while denying access to all other resources. This specific binding ensures that the user, represented by the ServiceAccount named robot in the app namespace is only allowed to manage specific resources and subresources in the cluster.
Inspect the ClusterRole and ClusterRoleBinding created by rbac-manager for the above CRD using the commands below.
allowedGroups:
This feature lets you specify Kubernetes resource API groups that should be granted access. You can fine-tune access based on specific resource groups, ensuring that permissions are granted only where necessary.
Example Use Case: Grant Access To Specific API Groups
Imagine a scenario where you need to grant users access to manage all resources in specific API groups. With rbac-manager, achieving this level of control is straightforward. You can create a Custom Resource Definition (CRD) like the one below:
In this example, the allow-groups Custom Cluster Role is configured to grant access to all resources in specific groups such as core, events.k8s.io, apps, networking.k8s.io, while denying access to all other resources. This specific binding ensures that the user, represented by the ServiceAccount named robot in the app namespace is allowed to manage all resources in the above specific groups.
Inspect the ClusterRole and ClusterRoleBinding created by rbac-manager for the above CRD using the commands below.
allowedVerbs:
With rbac-manager, you can easily define which actions on Kubernetes resources are permissible. You can specify actions, such as create, read, update, or delete, that are permitted.
Below is a list of available verbs.
In the example provided, you've witnessed how rbac-manager utilizes customClusterRoles to create ClusterRole resources. However, rbac-manager offers another powerful feature, customRoleswhich allows you to create Role resources in response to the CRD. Let's explore more.
Imagine a scenario where you need to grant users access to specific namespaces to manage resources in specific API groups while denying access to secrets and services. You can achieve this with a Custom Resource Definition (CRD) like the one below:
In this CRD, you define a customRole named edit-role with specific access controls based on a namespaceSelector. This role grants all verbs for resources within specific API groups while denying access to services and secrets. The customRbacBindings section binds this role to the ServiceAccount named robot within the app namespace.
Automatic Creation of Roles and RoleBindings
Here's where rbac-manager shines: It automatically generates Roles and RoleBindings in all existing namespaces that match the namespaceSelector. To inspect these created resources, you can use the following commands:
Furthermore, any future namespace created with the label key1: value1 will automatically receive the corresponding Role and RoleBinding. To confirm this, you can create a new namespace with this label:
Then, inspect the Role and RoleBinding in the newly created namespace:
rbac-manager simplifies and automates access control management in Kubernetes, ensuring that your policies remain consistent and effective across existing and future namespaces.
Last updated