[BUG] DLS accepts `now` / date math in role definition but rejects at query time

[sutadaka]

Describe the bug

DLS accepts a role definition containing date math expressions (e.g., now-30d/d) without any validation error (HTTP 201). The issue only surfaces at query time when a user mapped to that role attempts a search, resulting in:

'now' is not allowed in DLS queries

The role appears correctly configured but fails at query time. Either date math should be supported in DLS filters (preferred), or the Security plugin should validate and reject at role creation time.

Related component

Other

To Reproduce

1. Create a DLS role with a date math filter:

PUT _plugins/_security/api/roles/time_restricted
{
"cluster_permissions": [],
"index_permissions": [
{
"index_patterns": ["test-index-*"],
"dls": "{"range": {"@timestamp": {"gte": "now-30d/d"}}}",
"allowed_actions": ["read"]
}
]
}

Response: 201 Created — no validation error.

2. Map a user to the role:

PUT _plugins/_security/api/rolesmapping/time_restricted
{
"users": ["restricted_user"]
}

3. Query as the restricted user:

GET test-index-*/_search
{
"query": { "match_all": {} }
}

4. Error returned:
   {
   "error": {
   "root_cause": [{"type": "parse_exception", "reason": "could not read the current timestamp"}],
   "caused_by": {
   "type": "illegal_argument_exception",
   "reason": "'now' is not allowed in DLS queries"
   }
   },
   "status": 400
   }

Expected behavior

Either:

1. (Preferred) Support date math expressions (now, now-30d/d, etc.) in DLS queries, resolving them at query time. This is a common access control pattern — restricting users to a rolling time window of data.
2. (Minimum fix) Validate the DLS query string at role creation time and reject expressions containing now with a clear error, rather than silently accepting them and failing later at query time.

Additional Details

Plugins
Security plugin (Fine-Grained Access Control / DLS)

Screenshots

Host/Environment (please complete the following information):

• Amazon OpenSearch Service (managed)
• Version: 2.13

Additional context
Use case: Multiple users query the same index. Some users should only see data from the last N days (rolling window), while admins retain full access. DLS with a time-range filter is the natural solution, but the lack of date math support forces workarounds like scheduled Lambda functions to rotate hardcoded epoch timestamps in the role definition.

[github-actions]

Possible Duplicate

Found 1 possible duplicate issue(s):

• DLS now keyword issue #6505

If this is not a duplicate:

• Add a comment on this issue, or
• 👎 this comment to prevent auto-closure

Otherwise, this issue will be automatically closed in 7 days.

[sutadaka]

This is related to but not a duplicate of #6505.

The workaround suggested in #6505 is to set plugins.security.unsupported.allow_now_in_dls: true in opensearch.yml (ref: opensearch-project/security#1038). However, this is not available on Amazon OpenSearch Service (managed) — users do not have access to opensearch.yml on managed domains, so this configuration cannot be changed.

This means there is currently no way to use date math (now, now-30d/d, etc.) in DLS queries on the managed service. The only workarounds are:

Restructuring to time-based indices and using index-level FGAC permissions instead of DLS
Hardcoding an absolute timestamp in the DLS filter and rotating it via external automation (Lambda + EventBridge)
Both add significant complexity for what should be a straightforward DLS use case.

The ask:

Make plugins.security.unsupported.allow_now_in_dls configurable on Amazon OpenSearch Service (managed domains), or
Support now / date math natively in DLS without requiring an opt-in flag — ideally promoted from "unsupported" to a supported feature, or
At minimum, reject DLS definitions containing now at role creation time (HTTP 400) rather than accepting them (HTTP 201) and failing at query time
Environment: Amazon OpenSearch Service (managed), OpenSearch 2.13