Overview

Kfuse supports RBAC by enforcing access/permission (authorization) on ALL resources based on the logged in user’s role. Kfuse enforces this access on both workflows/operations (like creating alerts o saving metrics from logs) and the data (all telemetry collected from various sources). Authentication of the logged in user is derived from the IAM solution (OKTA, Google Auth, etc.) integrated and configured to be used with Kfuse.

Configuration

Configure kfuse for implementing RBAC in your deployment. Copy the following code in your <custom_values.yaml> file and make edits as necessary. Please look through the comments for example and. To learn more review the concepts.

# user-mgmt-service:
#   config:
    # # Learn more:
    # # - "reserved" built group names (should not to be used):
    # #   "kf_admin", "kf_reader_all"
    # # - in built scope types:
    # #   scope_allow_all, scope_viewer_all, scope_allow_none
    # # - role types:
    # #   admin, editor, viewer
    # #
    # groups:
    # - name: group_admin
    #   users:
    #   - id_key: X-Auth-Request-Email
    #     value: admin1@company.com
    # - name: group_viewer_target_namespace
    #   users:
    #   - id_key: X-Auth-Request-Email
    #     value: op1@company.com
    # - name: group_editor_otel_namespace
    #   users:
    #   - id_key: X-Auth-Request-User
    #     value: maintainer2userid
    # rbac_policies:
    # - name: rbac_viewer_target_namespace
    #   role: viewer
    #   scope:
    #     filters:
    #     - key: kube_namespace
    #       op: =
    #       value: target
    #     type: custom
    # - name: rbac_editor_otel_namespace
    #   role: editor
    #   scope:
    #     filters:
    #     - key: kube_namespace
    #       op: =
    #       value: otel-demo-app
    #     type: custom
    # rbac_configs:
    # - group: group_admin
    #   policy: scope_allow_all
    # - group: group_viewer_target_namespace
    #   policy: rbac_viewer_target_namespace
    # - group: group_editor_otel_namespace
    #   policy: rbac_editor_otel_namespace

Concepts

Roles & Capabilities

kloudfuse platform has following roles and their capabilities.

Capabilities
\
Role

(UM) User management

  • add admin user

(add UserConfig)

R/W (Kfuse)

  • ASM (Alerts)

  • Recording Rule

  • Save APM/Log Metrics

  • parser pipeline config

R/W (grafana**)

  • Alerts

  • Dashboards

  • Folders

  • AlertMgr

Read

  • Logs Explorer

  • Metrics Explorer

  • APM Explorer

  • List Alerts

Admin

Yes

Yes

Yes

Yes

Editor

No

Yes

Yes

Yes

Viewer

No

No

No

Yes

** Only for user with admin role

Access to Data (from monitored clusters)

As part of RBAC implementation, a user can also achieve role based data access (view). To achieve this,

kloudfuse can be configured with "groups" having assigned "rbac_policy" (role and the associated view/scope) and together they define the "rbac_configuration" of the system. To configure the system correctly please go through the following definitions.

Scope

A scope defines what data a given user has access to. Kloudfuse platform has following inbuilt (reserved) access types.

Type: scope_allow_all

This scope allows access to all data. Typically used for users with "Admin" capabilities.

Type: scope_allow_none

Fully restricted. User will not be allowed any access.

Type: scope_viewer_all

Only read access to all data. Typically used for support operators who only needs to visualize and wouldn’t be making configuration changes.

Type: custom

Custom scopes can be used to provided limited access to data. A custom scope is defined as follows:

      scope:
        type: custom
        filters:
        - key: kube_namespace
          op: =
          value: target

Policy

An RBAC policy is defined by a role (one of the "admin"/"editor"/"viewer") and a scope assigned to that role.

Example policy: Viewer role for a custom scope.
    # policy name
    - name: rbac_viewer_target_namespace
      # Role (one of admin/viewer/editor)
      role: viewer 
      # Custom scope giving access to data generated from kube_namespace called "target" 
      scope:
        filters:
        - key: kube_namespace
          op: =
          value: target
        type: custom
Example policy: Admin for all.
    # policy name
    - name: rbac_admin_all
      # Role (one of admin/viewer/editor)
      role: admin
      # using inbuilt scope scope_allow_all
      scope:
        type: scope_allow_all

Group

A group is set of users (a team) who share same RBAC configuration. In other words, share the same role and scope. 

    # Group name
    - name: group_editor_otel_namespace
    # List of users
      users:
      - id_key: X-Auth-Request-Email
        value: user@company.com
      - id_key: X-Auth-Request-User
        value: 123456789

User

A user is defined by a user id value. For example an email address. Kloudfuse RBAC uses the information obtained from the configured IAM during the login process. See following example of some user valid configurations.

      - id_key: X-Auth-Request-Email
        value: user@company.com

kfuse uses id keys by default. Other id keys can be added as well.

RBAC Configuration

An RBAC configuration ties a given group to a given RBAC policy. Many such configurations can be configured in kfuse. 

    rbac_configs:
    - group: group_editor_otel_namespace
      policy: rbac_editor_otel_namespace
    - group: group_viewer_target_namespace
      policy: rbac_viewer_target_namespace