Managing Roles and Permissions in Amazon OpenSearch with AWS SSO

Amazon OpenSearch is a powerful search and analytics engine used across organizations for log analytics, monitoring, and full text search use cases. While internal users and static credentials are sufficient for test environments, enterprise grade security requires fine-grained access control.

After integrating AWS Single Sign-On (SSO) with OpenSearch Dashboards, the next goal is to make sure users get only the access they need. Not everyone should have the power to create or delete data or manage snapshots and security settings. That’s where roles and permissions come in.

This blog will guide you through how to create roles in OpenSearch, what kind of access they provide, and how to map those roles to users or groups from AWS SSO (IAM Identity Center).

With this setup:

• Developers can work freely in dev and staging
• Business users can view production data safely
• Admins can manage and troubleshoot without risking data

---

Role Scope: Index Level vs Admin Permissions

Roles in OpenSearch are built to control access at many levels:

• Index/Data level: Used by most developers and viewers. Controls access to specific indices, like whether someone can read or write documents
• Admin level: Reserved for system-level operations. This includes snapshot and restore access, changing security settings, and managing dashboards and tenants.
• Cluster level: Enables permissions related to cluster operations, such as monitoring or node management.,
• Dashboard level: Governs access to visualizations and dashboards (Ex, Kibana or OpenSearch Dashboards)

We typically assign index level roles to developers or analysts working on particular data sets. Admin roles are assigned only to trusted users who manage infrastructure, backups, or OpenSearch configuration.

---

Understanding Roles in OpenSearch

The OpenSearch security plugin uses roles to decide what actions a user can take. This includes reading documents, writing to indices, managing dashboards, or running queries. When combined with AWS SSO, roles are assigned to IAM groups or users, creating a secure and scalable access model.

We can either define roles through the OpenSearch Dashboards UI or by using the OpenSearch REST API. Once created, roles must be linked to users or IAM Identity Center groups using role mappings.

Common Role Types

Here are three widely used role types in OpenSearch, each serving a distinct purpose based on access needs. When creating custom roles, it's a good practice to use a role prefix (like OrgName) to avoid naming conflicts with default system roles. In the following examples, replace <prefix> and <index_name> with your preferred values.

You can also adjust the tenant_patterns field depending on whether the role should have access to all tenants or be restricted to a specific one, especially useful in multi-tenant environments.

Read-Only Role

This role is for users who only need to view data or dashboards. They can't make changes, making it safe for environments like production. Assigned to business teams, auditors, or any role that requires visibility but not edit access.

PUT _plugins/security/api/roles/<prefix>_<indexName>_read_only_role
{
  "cluster_permissions": ["cluster_monitor"],
  "index_permissions": [
    {
      "index_patterns": ["<index name>"],
      "allowed_actions": ["read"]
    }
  ],
  "tenant_permissions": [
    {
      "tenant_patterns": ["*"],
      "allowed_actions": ["kibana_all_read"]
    }
  ]
}

If we need more control, we can replace "read" (permission group) with individual actions like "indices:data/read/search".

Read/Write Role

This role allows users to read and modify data. It’s perfect for dev and QA environments where testing and iteration are common. Assign it to developers or integration environments where new data is created or updated, but deleting entire indices is not allowed.

PUT _plugins/_security/api/roles/<prefix>_read_write_role
{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [
    {
      "index_patterns": ["*"],
      "allowed_actions": [
        "crud",
        "indices:admin/get",
        "indices:admin/get/*",
        "indices:admin/create"
      ]
    }
  ],
  "tenant_permissions": [
    {
      "tenant_patterns": ["*"],
      "allowed_actions": ["kibana_all_read", "kibana_all_write"]
    }
  ]
}

Admin Role

This is a powerful role that gives users full access, including the ability to manage indices, delete data, configure snapshots, change security settings, and control dashboards. Assign this role only to core DevOps engineers or platform administrators with approval based access.

PUT _plugins/_security/api/roles/<prefix>_admin_role
{
  "cluster_permissions": [
    "cluster_composite_ops",
    "cluster_monitor"
  ],
  "index_permissions": [
    {
      "index_patterns": ["*"],
      "allowed_actions": [
        "crud",
        "indices:admin/get",
        "indices:admin/get/*",
        "indices:admin/create",
        "indices:admin/delete"
      ]
    }
  ],
  "tenant_permissions": [
    {
      "tenant_patterns": ["*"],
      "allowed_actions": ["kibana_all_read", "kibana_all_write"]
    }
  ]
}

Mapping Roles to Users or Groups

A role alone doesn’t do anything unless it’s mapped to users or groups. This step links IAM Identity Center groups or specific users to the roles you created.

You can map roles either from the OpenSearch UI or through the API. Use backend_roles to map IAM groups, and users to map individuals or Lambda IAM role ARNs.

PUT _plugins/_security/api/rolesmapping/<prefix>_<indexName>_read_only_role
{
  "backend_roles": ["Business Users"],
  "users": ["user@example.com"]
}

Note: The PUT method overwrites all existing role mappings. To avoid accidentally removing current mappings, either use the PATCH method to update only the necessary fields or include all existing mappings along with new additions in the PUT request.

Important

Make sure to remove the wildcard (*) from the default role's user mapping. If left as is, all users who log in via SSO may unintentionally get admin access.

Programmatic Access for Applications

For applications like AWS Lambda that need to interact with OpenSearch:

• Use IAM role-based access
• Sign HTTP requests using AWS SigV4
• Add the Lambda’s IAM role ARN to the relevant OpenSearch role mapping

This allows applications to securely access OpenSearch without using static credentials.

Setting Role Access by Environment

Different environments need different access policies. For example, Developers may need full access in dev, but read-only access in staging or production. We can define rules for each environment to ensure teams have the correct level of access at each stage of deployment.

Example:

Environment	Role Type	Permissions
Dev	Read/Write	Modify documents, create indices, not delete index
Staging	Read/Write	Modify documents, not delete the index
Production	Read-Only	View data, no edits
Production	Admin	Full access with approval only

Summary

Setting up roles and permissions in OpenSearch is critical after SSO integration. Most users only need access to specific indices or data, while only a few should have admin privileges.

By designing roles carefully and mapping them to IAM groups or users, we keep our system secure, organized, and easy to manage, no matter how many users or environments we are working with.