Skip to content

Data Access


Logs, RUM, APM, and Metrics data may contain sensitive information. Therefore, for security reasons, even within the same business organization, data access permissions need to be carefully divided.

The data access function is implemented in the following ways:

  1. Based on indexes from different sources, set member roles level data access ranges for visitors.
  2. Use tools such as regular expressions and masking fields to perform necessary processing on the data based on access restrictions, ensuring that sensitive information is properly protected without reducing the value of the data.

On the Management > Data Access page, you can start creating rules using the following two methods:

Click the Create Rule button at the top left of the page to start creating.
If there are historical access rules on the current page, click the icon under the operation options on the right side of the rule to clone an existing rule and then create.

Configuration

  1. Select the data type.
  2. Define the name of the current rule.
  3. Enter a description of the current rule.
  4. Select the workspace sites to which the current rule applies.
  5. For the selected data type, choose the corresponding Indexes, Services, Applications, and Metrics.
  6. Define the access scope of the data under the current rule.
  7. Add one or more fields that need to be masked.
  8. Use regular expressions to mask sensitive information in the field content.
  9. Select one or more member roles that the current access rule can be applied to, including default roles and custom roles in the system.
  10. Save.

Configuration Notes

Data Access Scope Definition

Data Scope: Members within the access rule can only view data that matches the filter conditions.

The logical relationship between different fields can be customized to Any (OR) or All (AND).

  • All (AND) is selected by default, and you can switch to Any (OR).

  • Examples of logical relationships are as follows:

    • Example 1: (Default AND)

      • host=[host1,host2] AND service = [service1,service2]
    • Example 2: (Switched to Any OR)

      • host=[host1,host2] OR service = [service1,service2]
  • Supports filtering by tags/attributes using various methods, including positive filtering, negative filtering, fuzzy matching, negative fuzzy matching, exist, and not exist.

Regular Expression Masking

When setting access rules, even if the data scope has been defined, additional measures are needed to prevent the leakage of sensitive or unnecessary information. You can use masking fields or regular expressions to further process the data and enhance data protection.

On the configuration page, in addition to directly adding individual masking fields, if you need to further mask specific parts of the log message content, such as hiding token or IP information, you can add regular expressions to meet this requirement.

  • Supports configuring multiple regular expressions, with a maximum of 10 expressions per access rule.
  • Supports disabling or enabling a regular expression. Subsequent applications and previews will only apply masking based on the enabled regular expressions.
  • Supports directly editing or deleting a regular expression here.
  • Supports dragging to move the position of regular expressions. When data matches this masking rule, the regular expressions are applied in order from top to bottom for masking.
  • Supports directly creating a new regular expression here:

In the pop-up window, enter the required information.

If Apply to Rule is checked, the rule will be directly added below the regular expression.

Role Scenarios and Query Permissions

Simple Cases

Assume a member only holds one role, such as read-only. After selecting this role, the system will only apply masking for the configured role.

If the role "All" is selected, all roles except Owner will be affected by masking.

Note
  • Default roles that do not have data access rules configured have query permissions for all data.
  • The data access rules take effect only based on the user role's existing data query permissions.
  • After a role matches a rule, you can only add filters within the basic scope defined by the rule. If you query beyond this scope, the returned data will be empty.

Multi-Role Permission Overlap

If a member has multiple roles and the query permission scopes of these roles differ (as shown in the figure below), the member's final data query permission will be the sum of all roles' data access and view scopes.

Multi-Rule Permission Control

In scenarios where business data is complex and has multiple levels, sometimes multiple access rules need to be set to adapt to different data access requirements.

  • The relationship between multiple filters in a single rule: Multiple values of the same key are OR, and the relationship between different keys is AND.
  • The relationship between multiple rules is OR.

Therefore, if:

Rule 1: host = [host1, host2] AND service = [service1, service2]
Rule 2: host = [host3, host4] AND source = [source1, source2]

The same role has both of the above permission rules, then the actual data will be displayed as Rule 1 OR Rule 2 to achieve a union effect.

The actual viewable data scope is:

(host = [host1, host2] AND service = [service1, service2]) OR (host = [host3, host4] AND source = [source1, source2])

If the same role has multiple permission rules, and one of the rules (e.g., Rule 1) contains a masking configuration, then all data returned under all permission rules will be affected by the masking rule.

Maintain Associations in Role Management

In addition to selecting applicable roles in the data access rules, you can also uniformly view and maintain the data access rules associated with roles in Management > Role Management.

  • The Data Access Rules column in the role list displays the number of rules associated with the current role.
  • By clicking or hovering over the number, you can search, paginate, select rules, and save the association in the right-side drawer, or jump to the data access page to continue configuration.
  • This entry only maintains the association between roles and rules; it does not modify the rule's data scope, filter conditions, data type, or masking configuration.
  • After the rule is saved successfully, the associated number in the role list will be updated synchronously.

Viewing and editing this association are controlled by role view, data access view, and data access management permissions. For details, please refer to Role Management.

Configuration Example

  1. Select the index rp70 of the current workspace.
  2. Set the data scope to host:cn-hangzhou.172.**.** and service:kodo.
  3. Do not set masking fields here; directly write the regular expression tkn_[\da-z]* to encrypt the token information.
  4. Finally, directly assign the current access rule to all Read-only members in the current workspace.
  5. Click Save. If needed, click Preview at the bottom left to view the masking effect.

The above access rule applies to all Read-only members in the current workspace. They can only access data within the log index rp70 that matches host:cn-hangzhou.172.**.** and service:kodo, and within this type of data, all token information is invisible.

Use Cases

Based on the already effective data access rules, members who are hit by the rules will automatically have their snapshot data filtered according to their permission rules. Even if the data contained in the snapshot exceeds the member's access permissions, the system will filter it first, and the member will only be able to view data that conforms to their access rules.

Management List

  • You can view the rule's associated indexes, query conditions, whether masking is enabled, the number of associated roles, and the number of members. You can also view and maintain associated rules by role in Role Management.
  • Show only rules related to me: Default is "Off", showing all rules. When enabled, only rules related to the current role are displayed.
  • Enable/Disable Rules: Modify the rule status. When disabled, the role's access is unrestricted; when enabled, the restriction is restored.
  • Edit: Modify the rule's name, description, bound indexes, filter conditions, and authorized roles.
  • Clone: Quickly copy the current rule.
  • Operation Audit: Record operations related to the rule.
  • Delete: Delete the current rule.
  • Batch Operations: Supports batch enabling, disabling, and deleting multiple rules.

Further Reading

Feedback

Is this page helpful?