- Newest
- Most votes
- Most comments
You don't need snapshots for this. The Security Plugin REST API already returns configuration in a format that can be restored directly — no conversion step required.
How it works
When you GET from any Security Plugin endpoint (e.g., /_plugins/_security/api/roles), the response is a JSON object where each key is the resource name and the value is the resource body. That value is exactly what the corresponding PUT endpoint expects.
So the workflow is simply:
- GET each security endpoint (roles, rolesmapping, tenants, actiongroups, internalusers) and save the JSON
- For each object in the response, PUT the body to the same endpoint on the target domain
No transformation, no intermediate format, no snapshots.
What to filter out
Each domain has its own system and reserved objects that must not be restored:
- Users: skip
admin,kibanaserver— these are domain-specific - Roles: skip anything prefixed with
security_and any role wherereserved: true - Tenants / Action Groups: skip any where
reserved: true
Attempting to restore reserved objects will fail with "Role is reserved" errors.
Important caveats
- Passwords are not exportable. The GET response contains hashes, not plaintext. After restoring users, you'll need to reset their passwords on the target domain.
- PUT is idempotent. Running the restore multiple times is safe — it overwrites existing objects.
- Cross-account works fine. This approach only needs curl/HTTP access to both endpoints. No S3 bucket, no IAM snapshot role, no SigV4 authentication needed.
Bottom line
For config-only promotion across D/Q/P environments, the REST API approach is the right one. The GET output doesn't need conversion — just filter out reserved/system objects and PUT the rest. No snapshots involved.
Related
Based on the available information about OpenSearch snapshots and restore operations, there are a few important points to consider for your configuration backup needs:
When working with snapshots in OpenSearch, you have some control over what gets restored through specific parameters. During a restore operation, you can use the include_global_state parameter to determine whether to restore the cluster state, which includes configuration elements. This gives you the ability to selectively restore configuration without necessarily restoring all the data.
However, the snapshot-restore approach is primarily designed as a comprehensive backup mechanism that captures index data, index metadata, and cluster metadata together. While you can control certain aspects of what gets restored, the snapshot process itself creates a point-in-time backup of the entire state.
For your specific use case of promoting only configuration elements (tenants, roles, etc.) across environments without the data, the snapshot-restore mechanism may not be the most efficient approach since snapshots are inherently tied to capturing both data and configuration together.
The API-based approach you mentioned (using GET to retrieve configuration and POST to recreate it) is actually a valid method for configuration management, though it does require transformation of the data format. This approach gives you more granular control over exactly which configuration elements you want to migrate between environments.
Unfortunately, based on the available documentation, there isn't a built-in "configuration-only" snapshot feature that would allow you to extract just the configuration in a directly restorable format separate from the data. You would need to either work with the full snapshot mechanism or continue using the API-based approach with the necessary data transformation steps.
Sources
1. Building from a snapshot - AWS Prescriptive Guidance
Backing up collections using snapshots - Amazon OpenSearch Service
Thanks Diego.