Granular RBAC access with Verrazzano

In this short blog, I will be sharing a step-by-step guide on how to grant users/groups created in Verrazzano User Management Console granular RBAC access to in resources in Verrazzano Infrastructure Management Console and Verrazzano GitOps tool.

TLDR;

1. Create custom Groups in Verrazzano User Management Console -Keycloak.

2. Map Groups from external Identity Provider to Keycloak groups (if users are stored outside Verrazzano)

3. Create a custom RoleTemplate in Verrazzano Infrastructure Management tool -Rancher- with specific permissions to manage Verrazzano clusters resources

4. Assign custom RoleTemplate in Rancher to groups created in Keycloak.

5. Define custom permissions in Verrazzano GitOps -ArgoCD- following RBAC permission structure : p, <role/user/group>, <resource>, <action>, <object>

6. Add policy.csv values to ArgoCD overrides in Verrazzano Custom Resource.

argoCD:
        enabled: true
        overrides:
        - values:
            configs:
              cm:
                exec.enabled: true
              rbac:
                policy.csv: |
                  p, role:staging-dev-admins, applications, create, dev-project/*, allow
                  p, role:staging-dev-admins, exec, create, dev-project/*, allow
                  g, ACME-project-key, role:staging-dev-admins

Intro

In Verrazzano -at least in version 1.5.x- user management is accomplished by mapping individual roles and groups to a specific set of users in Keycloak. User information can be stored either locally or delegated to an external user store. In the example presented in this blog, Keycloak is configured as an Identity Broker with Oracle Cloud Infrastructure Identity Cloud Service as an Identity Provider. Remember that Verrazzano can be integrated with any Identity Provider that supports SAML v2.0, OpenID Connect v1.0, OAuth 2.0.

Once users and groups are defined, granular RBAC access is configured based on scopes included in the authentication token sent when using OAuth 2.0 framework. In other words, Keycloak will attach a list of groups, a user belongs to, in the request to access a resource in ArgoCD or Rancher or any Verrazzano Console that is enabled during install. Then, each console will have its own group mapping to limit its own resources.

Below is a very high level diagram of how groups scopes are passed down to each tool. One of key feature in Verrazzano is that it comes pre-configured to authenticate users using OpenID Connect (OIDC) PKCE flow.

Note that using an external Identity Provider is not a must for granting granular permissions, but is a very common use case.

Let’s start with Keycloak groups.

Create Custom Groups in Keycloak

• Login to KeyCloak with keycloakadmin
• Create a Group Structure under verrazzano-system Realm
• Create a group named ACME with a child group ACME-DevOpsGroups

• Select Members tab and add verrazzano admin user to custom Group created (ACME-DevOpsGroup)

2) Map Groups from external Identity Provider to Keycloak group

If your Keycloak is configured to store user information locally, you can skip to step 3.

For reference on how to configure OCI IDCS, see : coupling-keycloak-and-oracle-cloud-iam-domains

In Keycloak, go to Identity providers and create an identity provider configuration under verrazzano-system realm.

For fields:

• Alias: oidc
• Display Name: Any name will do.. Let’s say “Employee Login”
• Discovery Endpoint, Client authentication, Client ID, Client Secret values are to retrieved from the Confidential Application configured in OCI IDCS. see : coupling-keycloak-and-oracle-cloud-iam-domains

Select Tab “Mappers” and proceed to create a Group Mapper for the recently created OpenID configuration

• Set Name
• Set Sync Mode override : Force
• Set Mapper type: “Advanced Claim to Group”

For Oracle OCI IDCS, set Claims Key to groups[0].name and Claims Value to the group name that will be federated from the configured IDp. It has to match exactly . In the image below, note that you have to replace GROUP_NAME_FROM_OCI with your group name.

· Select a Group created in Item 1 ( Acme-DevOpsGroup)

Grant Access to specific resources in Rancher.

A Rancher Custom Cluster Role can be tailored to grant specific access to resources in a registered Kubernetes cluster. In this example, we are enforcing a single cluster access policy to pods and namespaces resources, but you can customized further depending on your own requirements.

Go to Rancher Dashboard and Authenticate with Verrazzano SSO user. It is important to authenticate with a user who has been federated from Keycloak, otherwise groups created in the first step will not be listed.

• Click on Users & Authentication
• Click on “Roles”
• Select “Cluster” tab in the Center Pane

• Select the option to “Create Cluster Role” in the upper right cornet
• Name: “ACME-DevOps-ClusterRole”
• Description: “ACME-DevOps-ClusterRole Description”
• Cluster Creator Default: No
• Locked: No
• In Grants Resources section: The assumption is that members of a DevOps Team should only have access to do CRUD operations on Pods, Persistentvolumes, and list namespaces only.

You can add more grants and customized further depending on your requirements.

Assign custom RoleTemplate to imported Keycloak group.

There is two options to assign a RoleTemplate to a user; either by assigning a Global Role or via Cluster Member option.

Option 1: Cluster Members

• Go to Rancher Dashboard. Login with Verrazzano SSO user.
• Click on Explore Cluster, and select Local cluster.
• Select Cluster and Project Members
• Click on “Add” to include a new Cluster Member.

At this point, all ACME groups created in Keycloak should be added to Rancher automatically. Those groups will be visible in the Select Member drop-down field.

Select ACME-DevOpsGroup and choose the newly created Cluster Role Template ACME-DevOps-ClusterRole

Users that belong to Group Acme-DevOpsGroup should be able to login and only have access to resources specified in custom RoleTemplate. In this case, CRUD operations on Pods and list namespaces only.

Option 2: Assign Global Roles To Groups.

a) Go to Rancher Dashboard and go to Users & Authentication Groups.

b) Click on Groups

c) Go to the upper right corner and click on Assign Global Roles .

d) From “Select Member” drop-down — you should see all Keycloak Groups — select ACME-DevOpsGroup/ Keycloak group. This group should be a child group.

e) From Global Permission section, select Standard User or if you want to be more restrictive, select User-Base

f) From Built-in section, select DevOpsLocalClusterRole (Roles not created by Verrazzano) that was created at the beginning of this section.

At this point, All resources required to federate Keycloak groups into Rancher should have been created. Next, testing…

Testing RoleTemplate with Keycloak Groups

To test and validate that a given federated user is constraint based on an assigned RoleTemplate, open an new browser window ( or a private tab) to make sure JWT tokens/sessions are not stored from previous VZ dashboard logins

• Go to Rancher Dashboard. Select option to “Log in with Keycloak”
• Select the external Identity Provider configured in Keycloak. i.e Employee Login
• Provide the user credentials for your external identity provider. In this example, OCI IDCS authorization form is displayed.

At this point the user should only be able to list the resources that the mapped grouped was allowed to. Compare an Admin user options displayed when user authenticated is an admin user vs a user who belongs to the group ACME-DevOps-group in Keyclaok.

Restricting access in ArgoCD

Next in line is ArgoCD. This GitOps Tool, pre-configured with Verrazano, is regularly used by developers to deploy applications in a Verrazzano managed cluster. It is imperative to limit how much access a given developer has to avoid messing up with production or somebody else deployments. Furthermore, ArgoCD has a single super-privilege user built-in out of the box.

To limit access you have to follow ArgoCD’s Permission structure:

RBAC Permission Structure

All resources except application-specific permissions (see next bullet):

p, <role/user/group>, <resource>, <action>, <object>

Applications, applicationsets, logs, and exec (which belong to an AppProject):

p, <role/user/group>, <resource>, <action>, <appproject>/<object>

Resources can be clusters, applications, repositories, etc. A complete list of resources and action is well described in ArgoCD’s documentation.

Once you have the idea of the RBAC structure you want to set, you can define them in Verrazzano Custom Resource as an override value under configs to policy.csv attribute similar to :

spec:
  components:
    argoCD:
      enabled: true
      overrides:
      - values:
          configs:
            rbac:
              policy.csv: |
                p, role:staging-dev-admins, applications, create, dev-project/*, allow
                p, role:staging-dev-admins, exec, create, dev-project/*, allow
                g, ACME-DevOpsGroups, role:staging-dev-admins

The snippet above defines ACME-DevOps-Group group example created in Keycloak and “broadcasted” to every Verrazzano Console.

In order to limit the access to ACME-DevOps-Group to a set of resources, we are mapping it to staging-dev-admins custom role. Permissions to this role where limited to “create” actions on any application and “exec” privileges to pods created under dev-project project.

If your system is already installed, update Verrazzano Custom Resource with snippet code above and then wait for all changes to complete and Verrazzano is back to Ready state.

kubectl edit vz 
kubectl get vz -w

Look for any errors in Verrazzano Platform Operator Log.

Testing ArgoCD RBAC policies.

Testing require you to login to ArgoCD with a user added to ACME-DevOps-Group. Then, attempt to create a project. You should see a similar error message “Unable to create project: permission denied”

Verrazzano centralizes user management using Keycloak, which makes it easier to have one single place to manage groups and user memberships. Uses OIDC to support Single Sign On across all Open Source Tools which enables Admins/Operators to grant permissions based on RBAC policies defined in each individual Verrazzano Console like Rancher and ArgoCD, to groups and users stored in Keycloak.