Add regex examples for audit ignore policies

deploy-manage/security/logging-configuration/logfile-audit-events-ignore-policies.md

@@ -25,7 +25,7 @@ The drawback of an audited system is represented by the inevitable performance p
 When utilizing audit events ignore policies you are acknowledging potential accountability gaps that could render illegitimate actions undetectable. Take time to review these policies whenever your system architecture changes.
 ::::
 
-A policy is a named set of filter rules. Each filter rule applies to a single event attribute, one of the `users`, `realms`, `actions`, `roles` or `indices` attributes. The filter rule defines a list of [Lucene regexp](elasticsearch://reference/query-languages/query-dsl/regexp-syntax.md), **any** of which has to match the value of the audit event attribute for the rule to match. A policy matches an event if **all** the rules comprising it match the event. An audit event is ignored, therefore not printed, if it matches **any** policy. All other non-matching events are printed as usual.
+A policy is a named set of filter rules. Each filter rule applies to a single event attribute, one of the `users`, `realms`, `actions`, `roles` or `indices` attributes. The filter rule defines a list of [wildcard patterns](elasticsearch://reference/query-languages/query-dsl/query-dsl-wildcard-query.md) or [Lucene regexp](elasticsearch://reference/query-languages/query-dsl/regexp-syntax.md), **any** of which has to match the value of the audit event attribute for the rule to match. A policy matches an event if **all** the rules comprising it match the event. An audit event is ignored, therefore not printed, if it matches **any** policy. All other non-matching events are printed as usual.
 
 All policies are defined under the `xpack.security.audit.logfile.events.ignore_filters` settings namespace. For example, the following policy named *example1* matches events from the *kibana_system* or *admin_user* principals that operate over indices of the wildcard form *app-logs**:
 
@@ -35,8 +35,16 @@ xpack.security.audit.logfile.events.ignore_filters:
     users: ["kibana_system", "admin_user"]
     indices: ["app-logs*"]
 ```
+An audit event generated by the *kibana_system* user and operating over multiple indices, some of which do not match the indices wildcard, will not match. As expected, operations generated by all other users (even operating only on indices that match the *indices* filter) will not match this policy either.
 
-An audit event generated by the *kibana_system* user and operating over multiple indices , some of which do not match the indices wildcard, will not match. As expected, operations generated by all other users (even operating only on indices that match the *indices* filter) will not match this policy either.
+The following policy named *example2* matches events that operate over any index except *logs-app1* and *logs-app2*:
+
+```yaml
+xpack.security.audit.logfile.events.ignore_filters:
+  example2:
+    indices: ["/~(logs-app1|logs-app2)/"]
+```
+Only events operating over *logs-app1* and *logs-app2* indices will not match and will not be ignored by the policy.
 
 Audit events of different types may have [different attributes](elasticsearch://reference/elasticsearch/elasticsearch-audit-events.md#audit-event-attributes). If an event does not contain an attribute for which some policy defines filters, the event will not match the policy. For example, the following policy will never match `authentication_success` or `authentication_failed` events, irrespective of the user’s roles, because these event schemas do not contain the `role` attribute:
 
@@ -46,7 +54,7 @@ xpack.security.audit.logfile.events.ignore_filters:
     roles: ["admin", "ops_admin_*"]
 ```
 
-Likewise, any events of users with multiple roles, some of which do not match the regexps will not match this policy.
+Likewise, any events of users with multiple roles, some of which do not match the wildcard patterns or the regexps will not match this policy.
 
 For completeness, although practical use cases should be sparse, a filter can match a missing attribute of an event, using the empty string ("") or the empty list ([]). For example, the following policy will match events that do not have the `indices` attribute (`anonymous_access_denied`, `authentication_success` and other types) as well as events over the *next* index.