RBAC (V2): Best Practices & FAQ

Introduction

To safeguard your Kubernetes environment and ensure operational efficiency, follow these RBAC best practices.

Key Recommendations

1. Principle of Least Privilege

• Only grant the minimum permissions required for a user’s role.
  • Permissions in Komodor are Additive
• Regularly review and adjust roles as needed.

2. Use Clear Naming Conventions

• Name roles and policies in a way that immediately reflects their scope and purpose.
  • This helps in quickly identifying the correct policy during audits.

 3. Regular Auditing and Monitoring

• Use audit logs and change tracking to keep your RBAC policies up-to-date.
• Schedule regular reviews to ensure that permissions still align with current organizational roles.

How-To Guides

Users

How to Add users?

Within the Komodor User Interface (Web Application) you'll need the manage:users action.

In the Komodor Web Application to create users, you'll need to complete the flow below:

1. Go to Organization settings (⚙️) from the top-right-hand corner.
2. Under Access Management select Users

3. Select Add a User +

4. In the modal that appears, enter the user's Name, Email & Select the relevant Role.

-- NOTE: If no role is selected, the default role for the account is applied. --

5. Select Save.

How to Edit users?

In the Komodor Web Application to edit a user, you'll need to complete the flow below:

1. Go to Organization settings (⚙️) from the top-right-hand corner.
2. Under Access Management select Users

3. Select the user from the table or search via the filter. 

4. On the row for the user, upon hovering, you will see a pencil. Select the ✏️.

-- NOTE: If no role is selected, the default role for the account is applied. --

5. Make the desired changes. 

6. Select Save.

How to Delete users?

In the Komodor Web Application to delete users, you'll need to complete the flow below:

1. Go to Organization settings (⚙️) from the top-right-hand corner.
2. Under Access Management select Users

3. Select the user from the table or search via the filter. 

4. On the row for the user, upon hovering, you will see a pencil. Select the 🗑️.

How to Restore users?

In the Komodor Web Application to restore users, you'll need to complete the flow below:

1. Go to Organization settings (⚙️) from the top-right-hand corner.
2. Under Access Management select Users

3. Select the user from the table or search via the filter. 

4. On the row for the user, upon hovering, you will see a pencil. Select the ↺.

Temporary Roles

To attach a temporary role to a user:

• Access the Organization settings ⚙️ page
• Go to the Users tab.
• For the specific user, Click the Edit (✏️)button
• In the modal select Add Temporary Role

• Select the role from the Temporary Role dropdown.

• Click Save.

Policy

Step-by-Step Guide (V2)

1. Creating a new RBAC Policy

   Navigate to the Organization Settings -> Policies -> + Add policy 

   

2. Choose a Name for the new policy and add a Description.
3. Now select  + Add statement
    
4. Choose the Scope:
   
   A. Cluster-based - For resources that are not namespace context-specific (Nodes, Persistent volumes etc.)
   
   B. Namespace-based - For resources that exist within the context of a specific Namespace. 
   
   C. Label/Annotation-based (CWR) - This works by filtering via Kubernetes annotations or labels, at the cluster level. 
   
5. Komodor admin - This set of actions are exclusively related to Komodor, e.g. manage:workspaces
6. Define the policy using wildcards or patterns to include or exclude resources.
7. Select Add statement to save the policy statement. 
   
8. Select Create Policy to save the policy and begin assigning to users.

• You can create multi-statement policies.
• You can view one or more statements at a time by using the <> View JSON button in the UI.

Example

Create a policy that grants read-only access to all namespaces matching *-dev* but excludes those ending in *-dev-test*.

• In policy form:
• In JSON form:

Updating Existing RBAC Policies

You may find that your existing RBAC policy doesn't achieve the access you expected, fret not - here are the steps to edit them below. 

• Editing a Policy:

1. Navigate to the Organization Settings -> Policies.
2. Select the pencil in the UI to Edit Policy.
3. Make the necessary changes to the statement via the wizard.
4. Select Update Policy.
   

• Deleting a Policy:

  1. Navigate to the Organization Settings -> Policies.

• Select the bin in the UI to Edit Policy.
  

Please note: Use the delete option carefully, as removing a policy may impact user access.

How to Create a Policy in Komodor

1. Creating a new RBAC Policy: 
   Navigate to the Organization Settings -> Policies -> + Add policy
2. Choose a Name for the new policy and add a Description.
3. Now select  + Add statement
    

4. Choose the Scope:

A. Cluster-based - For resources that are not namespace context-specific (Nodes, Persistent volumes etc.)

- Cluster based scopes need to match exactly with the IS operator.
- Cluster based scopes using the Matches Wildcard can be either *to signify ALL clusters or you may decide that only PROD* or *MLOPS interest you.
- You may also decide to add an exclusion for clusters that DO NOT match a wildcard.

B. Namespace-based - For resources that exist within the context of a specific Namespace. 

- With Namespace based scopes you'll need to specify a/many clusters AND provide a scope for the NS level. 
At both the Cluster and the Namespace level you are able to additionally use the Add exclusion functionality. 

C. Label/Annotation-based (CWR) - This works by filtering via Kubernetes annotations or labels, at the cluster level. 

- Cluster wide resources scope is limited only to the resources that are not restricted to a specific namespace and apply to the entire cluster. 
- The actions related to this scope are for resources that are relevant, allowing for less confusion.
-- view:clusterroles
-- view:customresourcedefinitions
-- view:namespaces
-- view:nodes
-- view:persistentvolumes
-- view:storageclasses
-- cordon:node
-- delete:persistentvolume
-- delete:storageclass
-- drain:node
-- uncordon:node

- Within the Policy creation wizard you'll need to fill in a few parameters, as before, including Tracked keys:

• Cluster - IS or Matches Wildcard
• AND Key (Tracked Keys, configured in the Tracked keys section of the platform. 
  
• With using KEY means that we need to define the corresponding VALUE (IS or Wildcard operator).

D. Komodor admin - This set of actions are exclusively related to Komodor, e.g. manage:workspaces- Komodor-admin scope is only applicable to the Komodor platform, as such, if the RBAC Cluster Sync functionality is enabled, these permissions will not be applied as these are not Kubernetes Native and are specific to Komodor. 

5. Define the policy using wildcards or patterns to include or exclude resources.

6. Select Add statement to save the policy statement. 

7. Select Create Policy to save the policy and begin assigning to users.

• You can create multi-statement policies.
• You can view one or more statements at a time by using the <> View JSON button in the UI.

How to Create a Policy Using Komodor's API

Komodor's Public API docs can be found here and the TF Provider can be found in Github here. 

1. Navigate to the Organization Settings -> Policies -> + Add policy 

   

2. Choose a Name for the new policy and add a Description.
3. Now select  + Add statement
    
4. Choose the Scope:
   
   A. Cluster-based - For resources that are not namespace context-specific (Nodes, Persistent volumes etc.)
   
   B. Namespace-based - For resources that exist within the context of a specific Namespace. 
   
   C. Label/Annotation-based (CWR) - This works by filtering via Kubernetes annotations or labels, at the cluster level. 
   
5. Komodor admin - This set of actions are exclusively related to Komodor, e.g. manage:workspaces
6. Define the policy using wildcards or patterns to include or exclude resources.
7. Select Add statement to save the policy statement. 
   
8. Now select View JSON
9. Once in JSON form, copy the output of the JSON and add this as part of your API call or TF plan.
    

API Examples

1. POST /api/v2/users (Creating a new user):

curl -X POST \
  'https://api.komodor.com/api/v2/users' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "email": "new.user@example.com",
    "firstName": "John",
    "lastName": "Doe",
    "roles": [
      "viewer"
      // You can validate the name of the role via the UI or by using a GET call
    ]
  }'

Explanation:

• -X POST: Specifies the HTTP POST method.
• 'https://api.komodor.com/api/v2/users': The API endpoint for creating users.
• -H 'Content-Type: application/json': Sets the content type of the request body to JSON.
• -H 'Authorization: Bearer YOUR_API_TOKEN': Includes your Komodor API token for authentication.
• -d '{ ... }': Contains the JSON payload with the details of the new user. You'll need to adjust the email, firstName, lastName, and roles array with your desired values. Ensure the roles you provide exist in your Komodor account.

2. POST /api/v2/rbac/policies (Creating a new RBAC policy):

curl -X POST \
  'https://api.komodor.com/api/v2/rbac/policies' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "name": "example-policy",
    "description": "A test policy with specific permissions",
    "statements": [
      {
        "effect": "Allow",
        "actions": [
          "events:list",
          "deployments:read"
        ],
        "resources": [
          "*" // Or specify specific cluster/namespace ARNs if needed
        ]
      },
      {
        "effect": "Allow",
        "actions": [
          "monitors:view"
        ],
        "resources": "*"
      }
      // Add more statements as needed
    ]
  }'

Explanation:

• -X POST: Specifies the HTTP POST method.
• 'https://api.komodor.com/api/v2/rbac/policies': The API endpoint for creating policies.
• -H 'Content-Type: application/json' and -H 'Authorization: Bearer YOUR_API_TOKEN': Similar to the previous example.
• -d '{ ... }': The JSON payload defines the new policy.
  • name: The name of the policy.
  • description: A description for the policy.
  • statements: An array of statement objects. Each statement defines:
    • effect: Usually "Allow" in an additive system.
    • actions: An array of Komodor actions this statement permits (e.g., events:list, deployments:read, monitors:view). You'll need to refer to Komodor's documentation for the exact list of available actions.
    • resources: An array specifying the resources these actions apply to. " *" typically means all resources, but you might be able to specify more granular resource ARNs (Amazon Resource Names-like identifiers) if Komodor supports it.

Important Note: The POST /api/v1/rbac/roles endpoint is a version 1 endpoint, while the role update is done in v2.

3. POST /api/v1/rbac/roles Creating a Role and Assigning v2 Policies (v2 endpoint):

Now, let's create a role and assign policies to it using the v2 endpoint (/api/v2/rbac/roles/{id_or_name}). 
To do this, we'll first need the IDs of the policies we want to assign. For this example, assume you've already created two policies with the IDs policy-123 and policy-456.

curl -X POST \
  'https://api.komodor.com/api/v2/rbac/roles' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "name": "example-role-with-v2-policies",
    "description": "Role with policies assigned using v2",
    "policyIds": [
      "policy-123",
      "policy-456"
    ]
  }'

4. PUT /api/v2/rbac/roles/{id_or_name} (Updating an existing RBAC role):

This endpoint requires you to replace {id\_or\_name} with the actual ID or name of the role you want to update. The request body will likely contain the updated role details, such as the associated policy IDs.

Let's assume you know the id of the role you want to update (e.g., role-xyz).

curl -X PUT \
  'https://api.komodor.com/api/v2/rbac/roles/role-xyz' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "name": "updated-example-role",
    "description": "Updated description for the example role",
    "policyIds": [
      "policy-abc",
      "policy-def"
      // Add or remove policy IDs as needed
    ]
  }'

Important Considerations:

• API Token: Make sure to replace YOUR_API_TOKEN with a valid API token for your Komodor account.
• Action and Resource Syntax: The exact syntax for actions and resources in the policy statements is crucial. Refer to the complete Komodor API documentation or use the policy creation wizard for the precise values and formats they expect.
• Role IDs/Names and Policy IDs: When updating roles or associating users with roles, you'll need the correct IDs or names of the existing roles and policies in your Komodor account.

Concepts

Komodor users with assigned roles can interact with the Komodor platform in multiple ways. The primary method is through the Komodor Web Application, Additionally, users can leverage the Komodor Public API to programmatically interact with the platform and integrate it with other tools and workflows.

If the RBAC Cluster Sync (KubeConfig) feature is enabled, Komodor users can directly interact with their Kubernetes clusters. This feature synchronizes role-based access control (RBAC) configurations between Komodor and the cluster, ensuring that users have the appropriate permissions to perform actions directly within their Kubernetes environment.

How to View a User's Effective Permissions 

The effective permissions section allows for users to understand exactly what permissions they have and for what resources, under which scope.

As shown in the gif below, you begin at the macro level, selecting which cluster, then namespace, relevant actions, policies and then roles, this will allow you to understand whether the permission set you have allows for actions you desire.

How to review Audit Logs

The Audit page in Komodor can be used to add additional granularity to actions performed using the Komodor platform, API and TF.  

Conclusion

Implementing these RBAC best practices will help you maintain a secure environment while ensuring that users have access only to the resources they need. Regular review and clear definitions are key to long-term success.