Workflow template security

In OpenSearch, automated workflow configurations are provided by the Flow Framework plugin. You can use the Security plugin together with the Flow Framework plugin to limit non-admin users to specific actions. For example, you might want some users to only be able to create, update, or delete workflows, while others may only be able to view workflows.

All Flow Framework indexes are protected as system indexes. Only a superadmin user or an admin user with a TLS certificate can access system indexes. For more information, see System indexes.

Security for Flow Framework is set up similarly to security for anomaly detection.

Basic permissions

As an admin user, you can use the Security plugin to assign specific permissions to users based on the APIs they need to access. For a list of supported Flow Framework APIs, see Workflow APIs.

The Security plugin has two built-in roles that cover most Flow Framework use cases: flow_framework_full_access and flow_framework_read_access. For descriptions of each, see Predefined roles.

If these roles don’t meet your needs, you can assign users individual Flow Framework permissions to suit your use case. Each action corresponds to an operation in the REST API. For example, the cluster:admin/opensearch/flow_framework/workflow/search permission lets you search workflows.

Fine-grained access control

To reduce the chances of unintended users viewing metadata that describes an index, we recommend that administrators enable role-based access control when assigning permissions to the intended user group. For more information, see Limit access by backend role.

(Advanced) Limit access by backend role

Use backend roles to configure fine-grained access to individual workflows based on roles. For example, users in different departments of an organization can view workflows owned by their own department.

First, make sure your users have the appropriate backend roles. Backend roles usually come from an LDAP server or SAML provider, but if you use an internal user database, you can create users manually using the API.

Next, enable the following setting:

  1. PUT _cluster/settings
  2. {
  3.   "transient": {
  4.     "plugins.flow_framework.filter_by_backend_roles": "true"
  5.   }
  6. }

copy

Now when users view workflow resources in OpenSearch Dashboards (or make REST API calls), they only see workflows created by users who share at least one backend role.

For example, consider two users: alice and bob.

alice has an analyst backend role:

  1. PUT _plugins/_security/api/internalusers/alice
  2. {
  3.   "password": "alice",
  4.   "backend_roles": [
  5.     "analyst"
  6.   ],
  7.   "attributes": {}
  8. }

bob has a human-resources backend role:

  1. PUT _plugins/_security/api/internalusers/bob
  2. {
  3.   "password": "bob",
  4.   "backend_roles": [
  5.     "human-resources"
  6.   ],
  7.   "attributes": {}
  8. }

Both alice and bob have full access to the Flow Framework APIs:

  1. PUT _plugins/_security/api/rolesmapping/flow_framework_full_access
  2. {
  3.   "backend_roles": [],
  4.   "hosts": [],
  5.   "users": [
  6.     "alice",
  7.     "bob"
  8.   ]
  9. }

Because they have different backend roles, alice and bob cannot view each other’s workflows or their results.

Users without backend roles can still view other users’ workflow results if they have flow_framework_read_access. This also applies to users who have flow_framework_full_access because this permission includes all of the permissions of flow_framework_read_access.

Administrators should inform users that the flow_framework_read_access permission allows them to view the results of any workflow in a cluster, including data not directly accessible to them. To limit access to the results of a specific workflow, administrators should apply backend role filters when creating the workflow. This ensures that only users with matching backend roles can access that workflow’s results.