- last edited on by
MaciejNeumann
Glossary
Resource attribute = a key-value-pair that is sent by the Dynatrace OneAgent that is easily customisable by the customer. (Resource attributes - Dynatrace Docs )
K8s labels = Labels that are set on various Kubernetes resources when managing the Kubernetes environment (Labels and Selectors )
Tips for engaging with the New rules
We suggest creating the new rules first and verifying with the per-rule preview to make sure the desired entities are matched.
After you’re satisfied with the rules, you can flip the toggle called Enable new monitoring rules in Settings app > Application security > General settings.
Every rule can consist of multiple conditions that are linked by a logical AND operator.
ℹ️Please be mindful when switching the monitoring rules, as switching from Classic to New monitoring rules has an impact on the entities that you monitor.
The problem
In classic Dynatrace, you could define rules for Third-party vulnerabilities based on management zones, host tags, and process tags.
This approach had some inconveniences:
-
Time delay when adding new entities to a management zone.
-
The necessity to understand various Dynatrace concepts (like “management zones” and “tags”) to create rules based on them.
-
A lot of complexity and a lack of transparency on what will be monitored.
-
One ruleset targeting different entity types, Application Security is monitoring (processes, K8s resources)
-
No ease-of-use when modifying rules (e.g., no auto-complete - making the rule prone to typos)
-
A different setup from code-level vulnerabilities and attack protection.
The solution
We introduced a new way of setting up what you want to monitor with Application Security.
Existing customers are eligible to see both Classic and New rules, while new customers will only be able to see the New ones.
Existing customers can see a toggle in the classic settings (Application security > General settings) called Enable new monitoring rules to switch between the rule sets.
The New rules are based on more transparent and straightforward concepts:
-
Library and runtime vulnerability monitoring can be configured using resource attributes, for example, host.name contains prod
-
Kubernetes vulnerability monitoring can be configured using Kubernetes labels, for example, kubernetes.io/hostname contains prod
We introduced more ease-of-use and transparency when setting up rules:
-
You get suggestions for keys & values
-
Based on the information available in your environment
-
You’re still able to enter any text in these fields
-
-
You have more comparison options (e.g. contains, exists, startsWith, …)
-
Each rule allows you to preview the entities that are matched with the conditions given
Suggestions
Per-rule preview of matched entities of the rule
You can read more about the new monitoring rules in the public documentation: Monitoring rules - Third-party Vulnerability Analytics - Dynatrace Docs.
We came up with a set of common use cases you could consider when setting up the “new” monitoring rules. They can also be found in the public documentation: use cases for monitoring rules - Dynatrace Docs .
Featured Posts
