Metrics Security Policy Rules

In a large enterprise, certain data is confidential. VMware Aria Operations for Applications (formerly known as Tanzu Observability by Wavefront) allows you to limit who can see or modify data in several ways.

• Permissions are global settings.
  • Some permissions limit who can modify objects (e.g. proxies or events). For example, users with Dashboards permission can modify all dashboards.
  • Other permissions make certain information completely invisible. For example, only users with SAML IdP Admin permission can see the Self Service SAML menu or access that page.
• Access Control allows administrators with the right permissions fine-grained control over individual dashboards or alerts. For example, it’s possible to limit view and modify access to a Finance_2020 dashboard to just the Finance department.
• Metrics Security supports even finer-grained control. In the example above, access to the Finance_2020 dashboard is limited to the Finance department. With metrics security, you can limit access to confidential time series, histogram, and delta counter metrics to the leadership team.

Video: Metrics Security Policy

Watch this video for an overview.

</td>

How Metrics Security Protects Sensitive Data

Metrics security policy rules allows fine-grained support for limiting access to sensitive data.

Block or Allow Access

With a metrics security policy, you can block or allow access:

• To metrics, optionally filtered by source or point tag
• Based on groups, roles, and individual users.

When an account attempts to access metrics, the backend looks at the rules in priority order. Higher priority rules overwrite lower priority rules.

For example, assume you have two rules:

After the rules are in force, only users in the Finance group can access data that starts with revenue*.

Sensitive Data Become Invisible

Data protected by a metrics security policy rule can become invisible to users.

• Not visible in charts. The chart either includes a warning that some metrics are protected, or, if all metrics are protected, the chart shows only the message.
• Not visible in alerts (if Secure Metrics Details is selected for the alert). The alert fires based on the complete set of metrics, and the complete set is shown in notification images by default. A check box allows administrators to hide alert details so that confidential metrics are not shown.
• Not visible in auto-complete in Chart Builder, Query Editor, Metrics browser, etc.

Rule Priority and Rule Pairs

Rules are evaluated in priority order. In many cases, it’s useful to think of pairs of rules, for example:

• Create a rule that blocks access to all metrics for a user group. For example, Block all. This rule is with lower priority.
• Create another rule to allow access to a small set of metrics for that user group. E.g. metrics starting with the cpu.* prefix and that are tagged with env=dev, i.e. developers environment. For example Allow CPU metrics. This rule is with higher priority.

When you apply this policy, the users included in the user group will have access to the metrics starting with the cpu. prefix and point tag env=dev, because the Allow metrics rule overrides the Block all rule.

See the Examples below for some scenarios.

Alert Notifications

To protect metrics from inclusion in alert notifications, use the Secure Metrics Details check box. Operations for Applications looks at all metrics when determining when an alert status should change and shows them in alert notifications. When the check box is selected, details are not shown in the notification.

Derived Metrics and Events

The current implementation has limitations:

• Does not protect metrics in events.
• Does not protect metrics in the Derived Metrics browser. When you select Browse > Derived Metrics, you still see metrics on that page even if a metrics security policy rule blocks access for you elsewhere in the GUI.

Warning Messages for Protected Metrics

• Charts in Dashboard. If certain charts in a dashboard include protected metrics, those charts display that information, as follows:
  • Some metrics protected. If some metrics in a chart are protected, the chart shows metrics but includes the following Warning message.

     Some metrics returned by this query might be excluded due to metrics security policy rules.
    

  • All metrics protected. If all metrics in a chart are protected, the chart shows only the following message:

     All metrics in this chart are excluded due to metrics security policy rules.
    

• Chart in Edit Mode. When you edit a chart and your query result include protected metrics, the following message is displayed below the query.

   All metrics returned by this query are excluded due to metrics security policy rules.
  

Create a Metrics Security Policy Rule

Privileged users can create rules, change rule priority, and change the scope of each rule.

Plan Your Strategy

Before you create rules, plan your strategy.

• Metrics Dimensions allow you to determine what to block or allow.
  • Specify one or more metric prefixes. You can specify an exact match (e.g. requests or request.) or a wildcard match (e.g. *.cpu.loadavg.*, cpu.*).
  • Specify a combination of metric sources or point tags to narrow down the metrics. For example, you can block visibility into production environments for some developers, or you can block some development environments metrics for contractors.
• Access allows you to allow or block access for a combination of accounts, groups, or roles.

See the Examples further below.

Create One or More Rules

You create a metrics security policy rule following these steps. See the annotated screenshot below for an example.

1. From the gear icon on the toolbar, select Metrics Security Policy and click Create Rule
2. In the Create Rule dialog, specify the rule parameters.

3. Specify a meaningful name and, optionally, a description.

   Users might later modify the rule, so a clear name is essential. The description is visible only when you edit the rule. The name is visible on the Metrics Security Policy page.

4. Specify and describe the metrics:
   • You can specify the full metric name or use a wildcard character in metric names, sources, or point tags. The wildcard character alone (*) means all metrics.
   • Specify key=value pairs, for example, source="app-24" or env=dev.
   • If you want to specify multiple key=value pairs, select whether you want to combine them with and or or using the dropdown menu on the right.
5. Specify the Access definition for the rule.
   1. Select Allow or Block from the menu.
   2. Specify accounts, groups, or roles.
6. Click OK.

Here’s an annotated screenshot that shows the main actions:

Manage Multiple Metrics Security Policy Rules

The following annotated screenshot gives an overview of rule management options:

Here’s a tour:

1. Click Version History to:
   • Revert to an earlier version of the policy.
   • Look at information on who last edited the security policy and when that happened.
2. Examine the Metric Prefix column to see the metrics affected by a rule.
3. Look at the Access column to see whether the rule allows or blocks access.
4. Select the check box to the left of a rule to select it, then use the icons above to clone or delete the selected rule.
5. Select the check boxes to the left of multiple rules to select them, use the icons to indicate changes, and click Save to commit the changes.
6. Click the six-dot icon to explicitly drag a rule where you want it and change the rule prioritization.
7. If you’ve moved, cloned, or deleted one or more rules, use the Undo button to undo the change, or Redo to revert the undo.

Example for Metrics Security Policies

Before you start, plan your strategy. Here are some common scenarios.

Example: Restrict Access to Confidential Metrics

This example restricts access to specific ranges of highly-sensitive metrics, say revenue numbers, to select groups of users.

The image above shows how to restrict metrics starting with revenue.* to be accessible only by members of the group Finance. The policy grants all users access to all other metrics.

• When the metric revenue.saas is queried by a user in the Finance group, this access matches Rule 1 (Finance Group can access Revenue). The rule grants the access, so the metric is shown to the user and no other rules are consulted.

• When the metric revenue.saas is queried by a user not in the Finance group, the access does not match Rule 1. The engine moves on to Rule 2 (No one else can access Revenue), which matches because all users belong to the Everyone group. Because the rule denies the access, the metric is not shown to the user. No other rules are consulted.

Example: Restrict Access for a Group of Users

This example restricts access for a group of users, making only a subset of the metrics in the system available to them.

The image above shows how to restricts access for users in the group Contractors. Those users can only query metrics tagged with the point tag env=dev. This policy imposes no restrictions on any other groups.

• When a user belonging to group Contractors runs a query for cpu.usage tagged with env=dev, this access matches Rule 1 (Contractors can access dev environment metrics) and access is granted.
• But when the user issues a query for cpu.usage tagged with env=prod, this access does not match Rule 1. Rule 2 (Contractors cannot access any other metrics) acts as a catch-all for users of group Contractors and denies them access to this metric.

Example: Restrict Access for a User Role

This example restricts access for a specific user when the restrict rule is applied to a user role. The metrics security rules take into account both direct and indirect roles.

The image above shows how to restrict access for a user with the role Operator. The user cannot access any metrics.

By applying the above security policy:

• When a user who is in the retail group runs a query for metrics tagged with the env=retail point tag, access is granted.
• A user who is assigned with the Operator role (either directly or indirectly, coming from other user groups) cannot access any metrics at all, because Rule 2 (Block all data) is applied.

Example: Restrict Access to All Except Specific Metrics

This example restricts access to all metrics except for two specific groups of metrics that are additionally narrowed down by specifying tags.

The image above shows how to restrict access for a specific user. The user cannot access any metrics except the ones specified in the first two rules. This Metrics Security Policy can also be applied to a user group.

• Rule 3 (Block all) restricts access to all existing metrics for the user.
• Rule 2 (Allow by tag) provides access to all metrics that start with the prefix customer. and customerStatus=ACTIVE tag.
• Rule 1 (Allow by tag for K8s integration) provides access to all metrics with the kubernetes. prefix for a specific cluster.

When you apply the above security policy, the user CAN see all metrics starting with the customer. and kubernetes. prefixes in the Metrics Browser. Also, the user CAN explore and create charts with the customer.* metrics having the customerStatus=ACTIVE tag and the kubernetes. metrics for the specific cluster. Autocomplete will work of these metrics.

Example: Strictly Limit Access on a Need-to-Know Basis

Some companies want to make metric accessible only to the team that needs to know about it. Access to metrics outside a team’s scope of work is disabled. Only administrators are allowed access to all metrics.

The image above shows how to use a set of rules to accomplish this.

• Rule 4 (Block All Metrics by default) applies to any access that doesn’t match a higher-up rule. It denies access to all users. Users get access only when an “exception” rule with higher priority access matches.
• Rule 3 (Allow All Metrics to Admins) grants access to all metrics to users in the Admins group.
• Rule 2 (Allow Gadgets Team access to Gadget Metrics) grants access to any metrics starting with gadget.* to members of the Gadgets group.
• Rule 1 (Allow Widgets Team access to Widget Metrics) grants access to any metrics starting with widget.* to members of the Widgets group.

In this example, ordering (priority) between rules 1 and 2 does not matter because describe rules for independent metric regions.

With this policy in place:

• Members of the Widgets group are granted access if the metric starts with widget.* (Rule 1) and denied otherwise (Rule 4).
• Members of the Gadgets group are granted access if the metric starts with gadget.* (Rule 2) and denied otherwise (Rule 4).
• Members of the Admins group are granted access to all metrics (Rule 3).
• Users who don’t belong to the groups covered by the rules have no access.