-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Index templates for Wazuh Server RBAC migration #288
Comments
After reviewing how we access and use the information in the current RBAC implementation, I found that it would be better from the server's perspective to have 4 separate indices, one for each entity (users, roles, rules and policies). This is because we are accessing them separately and listing all the available items at once, instead of getting users and their relationships. For example, listing all policies with just two indices would require the server to request all roles, list all the role's policies, compare them against the others to validate that they are unique (as they could be repeated) and add them to the list. On the other hand, with 4 indices, we would just get all items present in an index and return that. To fix this, we could have 4 indices Usersid: "id"
name: "name"
password: "password_hash"
allow_run_as: false
created_at: 0
roles: ["role_id_1", "role_id_2"] Rolesid: "id"
name: "admin"
created_at: 0
level: 0
policies: ["policy_id_1", "policy_id_2"]
rules: ["rule_id_1", "rule_id_2"] Policiesid: "id"
name: "policy"
actions: ["agent:create"]
resources: ["*:*:*"]
effect: "allow"
level: 0
created_at: 0 Rulesid: "id"
name: "rule"
body:
FIND|MATCH:
username: "admin"
created_at: 0
Note Usernames and names must be unique, so we could use them as IDs. |
The new index templates were generated and implemented alongside the ECS mappings and fields definitions on the PR: Please, review the defined
|
Until now, the design considered one index per entity and related them by referencing their IDs. We understand that this is not ideal for a multi-tenant environment and that a single large index is better than multiple small ones. For this reason, we aim to have only two indexes: one containing the default resources (which will be used by all tenants) and the other containing all the tenant's custom information. Each document will include all the necessary information: users, roles, policies, and rules, these elements will be duplicated across documents if needed. We will have two indices with the same template, one will be hidden to have the Wazuh's default rbac configurations, and the other for the custom ones. All-in-one index example structure: # Hidden (default/internal) wazuh-internal-users
# Non-hidden (user customized) wazuh-custom-users
- id: "id"
name: "name"
password: "password_hash"
allow_run_as: false
created_at: 0
roles:
- name: "admin"
created_at: 0
level: 0
policies:
- name: "policy-one"
actions: ["agent:create"]
resources: ["*:*:*"]
effect: "allow"
level: 0
created_at: 0
- name: "policy-two"
actions: ["agent:remove"]
resources: ["*:*:*"]
effect: "allow"
level: 0
created_at: 0
rules:
- name: "rule-one"
body: {}
created_at: 0
Mapping setting "query.default_field": [
"user.name",
"user.roles.name",
"user.roles.policies.name",
"user.roles.rules.name",
] |
Description
Related issue: wazuh/wazuh#27795
In order to migrate the Wazuh Server RBAC (role-based access control), we need to generate the index templates to migrate the databases used for it. We need to generate index templates for the
users
androles
tables described here.The
rules
andpolicies
entities could be inserted under theroles
entity, as follows:Consider using indices for the
policies
entity as well, for reusability.Functional requirements
Implementation restrictions
ecs
folder, so they are autogenerated by the GitHub Workflow.Plan
The text was updated successfully, but these errors were encountered: