Table of Contents |
---|
Note |
---|
Starting with Release 2.7.2, we manage RBAC through the UI, in the KloudFuse Admin tab. |
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 SSO (OKTA, Google Auth, etc.) already 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.
Enable RBAC
To enable RBAC, add following in the <custom_values.yaml>
Default RBAC policy when RBAC is enabled allows full access. Be sure to change default policy.
Code Block |
---|
global: ... RBACEnabled: true |
Policy Configuration
Use following template, make changes in the <custom_values.yaml>
Code Block |
---|
# 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 # # Kloudfuse has following inbuilt RBAC policies # # rbac_allow_all - allows all operations for everyone # # rbac_allow_none - No accesss # # rbac_view_all - allow all READ operations for everyone # # # default_rbac_policy: rbac_allow_all # 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: rbac_allow_all # - group: group_viewer_target_namespace # policy: rbac_viewer_target_namespace # - group: group_editor_otel_namespace # policy: rbac_editor_otel_namespace |
Change default policy
When RBAC is enabled, default policy allows full access. Add following to your <custom_values.yaml>
to use your custom policy or remove the default policy of full access to no access.
Example: Default policy to disallow all capabilities
Note: Using “scope_allow_none” as the default policy will ensure that logged in user doesn’t have any capabilities (view data or take actions) in the system. It doesn’t restrict the user from logging in to Kloudfuse system.
Code Block |
---|
user-mgmt-service: config: # # - in built scope types: # # Kloudfuse has following inbuilt RBAC policies # # rbac_allow_all - this policy grants admin like access (View + Edit capabilities for all data scope/workflows). # # rbac_allow_none - this policy denies all capabilities (No data view, No edit workflow capabilities) # # rbac_view_all - this policy grants viewer access to all data, no edit workflow capabilities. # # default_rbac_policy: rbac_allow_none |
Example: Default policy to provide custom scope
The following example uses a custom policy called rbac_viewer_target_namespace
as the default policy. Please see here to learn more about policy definition.
Code Block |
---|
user-mgmt-service: config: # # - in built scope types: # # scope_allow_all -- this policy grants admin like access # # scope_viewer_all -- this policy grants viewer access # # scope_allow_none -- this policy denies all capabilities # # default_rbac_policy: rbac_viewer_target_namespace |
Apply changes
After updating the values.yaml file with the desired configuration, upgrade the kfuse release.
Concepts
Roles & Capabilities
kloudfuse platform has following roles and their capabilities.
...
** Only for user with admin role
Role Based Data Access
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.
Group
A group is set of users (a team) who share same RBAC configuration. In other words, share the same role and scope.
Code Block |
---|
# 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.
...
kfuse uses id keys by default. Other id keys can be added as well.
RBAC 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.
Code Block |
---|
# 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.
Code Block |
---|
# policy name - name: rbac_admin_all # Role (one of admin/viewer/editor) role: admin # using inbuilt scope "all" scope: type: all |
Example policy: Viewer role for a custom scope with regular expression in filter.
Code Block |
---|
# 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: dev-.* type: custom |
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. For a scope to match all filters should match. Each filter is defined by a key
, an operator (=
, ~=
, =~
, !~
) and value
to match. For example, following custom scope is defining a filter which matches data such that kube_namespace="target"
:
Code Block |
---|
scope: type: custom filters: - key: kube_namespace op: = value: target |
RBAC Configuration
An RBAC configuration ties a given group to a given RBAC policy. Many such configurations can be configured in kfuse.
Code Block |
---|
rbac_configs: - group: group_editor_otel_namespace policy: rbac_editor_otel_namespace - group: group_viewer_target_namespace policy: rbac_viewer_target_namespace |
Adding an RBAC User
To configure a user with RBAC, follow these steps by appropriately editing your custom-values.yaml
file in user-mgmt-service
section.
With SSO
Create user or add user to existing group.
Code Block # Group name - name: rbac_group_name # List of users users: - id_key: X-Auth-Request-Email value: user@company.com
Create a RBAC policy or use an existing one
Code Block # policy name - name: rbac_policy_name # creating a viewer policy role: viewer # using inbuilt scope all scope: type: all
Create RBAC config with the group and policy
Code Block rbac_configs: ... - group: rbac_group_name policy: rbac_policy_name
With basic authentication
Create user or add user to existing group
Code Block # Group name - name: rbac_group_name # List of users users: - id_key: X-Auth-Request-User value: my_user_name
Create a RBAC policy or use an existing one
Code Block # policy name - name: rbac_policy_name # creating a viewer policy role: viewer # using inbuilt scope all scope: type: all
Create RBAC config with the group and policy
Code Block rbac_configs: ... - group: rbac_group_name policy: rbac_policy_name
...