...
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 SSO (OKTA, Google Auth, etc.) integrated and already configured to be used with Kfuse.
...
kloudfuse can be configured with "groups" Groups having assigned "rbac_policy" RBAC Policy (role and the associated view/scope) and together they define the "rbac_configuration" RBAC Configuration of the system. To configure the system correctly please go through the following definitions.
...
Group
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:
...
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 typevalue: customuser@company.com - filtersid_key: X-Auth-Request-User - keyvalue: kube_namespace123456789 |
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.
| Code Block |
|---|
op: =- id_key: X-Auth-Request-Email value: targetuser@company.com |
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_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.
...
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:
| Code Block |
|---|
scope: type: custom users: - id_key: X-Auth-Request-Emailfilters: value: user@company.com - id_key: X-Auth-Request-Userkube_namespace value: 123456789 op: = |
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.
| Code Block |
|---|
- id_key: X-Auth-Request-Email value: user@company.com |
...
target |
RBAC Configuration
An RBAC configuration ties a given group to a given RBAC policy. Many such configurations can be configured in kfuse.
...