Untitled - Documentation

ISM (Index State Management) is OpenSearch's equivalent of ILM (Index Lifecycle Management) in Elasticsearch/Kibana. Same concept, different name — Elastic renamed/rebranded it when OpenSearch forked.

Direct Mapping¶

ILM (Elasticsearch)	ISM (OpenSearch)
Hot phase	No phase names — just states you define
Warm phase	Custom state (e.g., "warm")
Cold phase	Custom state (e.g., "cold")
Delete phase	Custom state (e.g., "delete")
Rollover action	Rollover action
Freeze action	No direct equivalent
ILM policy	ISM policy
Index template attachment	`plugins.index_state_management.policy_id` in template settings

Key Differences¶

ISM uses a state machine model rather than fixed phase names. You define states and transitions yourself, which is more flexible but more verbose. For example:

{
  "policy": {
    "states": [
      {
        "name": "hot",
        "actions": [{ "rollover": { "min_size": "50gb", "min_index_age": "1d" } }],
        "transitions": [{ "state_name": "delete", "conditions": { "min_index_age": "30d" } }]
      },
      {
        "name": "delete",
        "actions": [{ "delete": {} }],
        "transitions": []
      }
    ]
  }
}

ISM polls on a schedule (default every 5 minutes) rather than being event-driven like ILM.

So your security-lifecycle-policy ISM policy is doing exactly what an ILM policy would do — rolling over and/or deleting your opnsense indices based on age/size conditions you've defined.