Demo RBAC

In this lesson, we will explore how to set up roles and role bindings effectively. Previously, we discussed how to add roles to specific users, groups, and service accounts. Now, we'll focus on configuring roles and binding them appropriately.

Understanding Default Cluster Roles

Before diving into role creation, familiarize yourself with the default cluster roles and their descriptions:

• admin: Acts as a project manager.
• basic user: A read-only user who can access basic project details and user information.
• cluster admin: Has full access—akin to a root user—and can monitor overall cluster health.
• cluster reader: Holds comprehensive read permissions across the cluster.
• edit: Allows editing of objects and resources, though not typically done on the fly.
• self-provisioner: Permitted to create their own projects.
• view: Enables modifications while maintaining view permissions.

At the console under user management (located just above Administration), options for users, groups, service accounts, roles, and role bindings are available. Let's start with roles.

Creating a New Role

These pre-populated roles are available in all projects. To create a new role, click Create Role. You can choose to create a namespaced role or a cluster-wide role.

Example: Namespaced Role

A namespaced role is defined as follows:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: default
rules:
  - apiGroups:
      - ''
    resources:
      - pods
    verbs:
      - get
      - watch
      - list

If you remove the namespace field, the resource becomes a cluster-wide role. For example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: example
rules:
  - apiGroups:
      - ''
    resources:
      - pods
    verbs:
      - get
      - watch
      - list

A Detailed Role Example

Assume we create a role named viewpods in the default namespace to allow read-only access to pods. Below is the configuration:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: viewpods
  namespace: default
rules:
  - apiGroups:
      - ''
    resources:
      - pods
    verbs:
      - get
      - watch
      - list

This setup specifies that the viewpods role strictly grants permissions for pod-related operations (get, watch, and list) within the default namespace.

Creating a Service Account

Next, create a service account to bind with the role. The following example creates a service account named podviewer in the default namespace:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: podviewer
  namespace: default

Binding the Role to the Service Account

After the service account is created, bind it to the viewpods role through a role binding. Here’s how you proceed:

1. Choose the default namespace.
2. Select the viewpods role.
3. Set the subject type as a service account and assign the name podviewer.
4. Click Create to finalize the binding.

If you opt for a cluster-wide role binding, the binding can be specified across the entire cluster. However, in this example, we focus on a namespace-scoped binding.

Once completed, you can search for the role binding using keywords like "viewer". You should find a role binding, such as pod view for viewer, linked to the viewpods role and associated with the podviewer service account.

By following these steps, you ensure that a service account like podviewer is accurately associated with a role that defines its permissions, thereby streamlining access control within your cluster.