Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added documentation for FGAC for Flow Framework #8076

Merged
merged 10 commits into from
Aug 28, 2024
89 changes: 89 additions & 0 deletions _automating-configurations/security.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
---
layout: default
title: Workflow security
nav_order: 25
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the navigation looks good @kolchfa-aws ?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved this topic down so it's the last in the left nav.

---

# Flow Framework Security

Check failure on line 7 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.HeadingCapitalization] 'Flow Framework Security' is a heading and should be in sentence case. Raw Output: {"message": "[OpenSearch.HeadingCapitalization] 'Flow Framework Security' is a heading and should be in sentence case.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 7, "column": 3}}}, "severity": "ERROR"}

You can use the Security plugin with the Flow Framework plugin in OpenSearch 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 view workflows.

All Flow Framework indices are protected as system indices. Only a super admin user or an admin user with a TLS certificate can access system indices. For more information, see [System indices]({{site.url}}{{site.baseurl}}/security/configuration/system-indices/).

Check failure on line 11 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'. Raw Output: {"message": "[OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 11, "column": 20}}}, "severity": "ERROR"}

Check failure on line 11 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'. Raw Output: {"message": "[OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 11, "column": 52}}}, "severity": "ERROR"}

Check failure on line 11 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'. Raw Output: {"message": "[OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 11, "column": 143}}}, "severity": "ERROR"}

Check failure on line 11 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'. Raw Output: {"message": "[OpenSearch.SubstitutionsError] Use 'indexes' instead of 'indices'.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 11, "column": 186}}}, "severity": "ERROR"}

owaiskazi19 marked this conversation as resolved.
Show resolved Hide resolved
Security for Flow Framework works the same as [security for anomaly detection]({{site.url}}{{site.baseurl}}/monitoring-plugins/ad/security/).

## Basic permissions

As an admin user, you can use the Security plugin to assign specific permissions to users based on which APIs they need access to. For a list of supported APIs, see [Flow Framework API]({{site.url}}{{site.baseurl}}/automating-configurations/api/index/).

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]({{site.url}}{{site.baseurl}}/security/access-control/users-roles#predefined-roles).

If these roles don't meet your needs, mix and match individual Flow Framework [permissions]({{site.url}}{{site.baseurl}}/security/access-control/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.

Check failure on line 21 in _automating-configurations/security.md

View workflow job for this annotation

GitHub Actions / style-job

[vale] reported by reviewdog 🐶 [OpenSearch.Spelling] Error: _framework. If you are referencing a setting, variable, format, function, or repository, surround it with tic marks. Raw Output: {"message": "[OpenSearch.Spelling] Error: _framework. If you are referencing a setting, variable, format, function, or repository, surround it with tic marks.", "location": {"path": "_automating-configurations/security.md", "range": {"start": {"line": 21, "column": 288}}}, "severity": "ERROR"}

### A note fine-grained access control

To reduce the chances of unintended users viewing metadata that could describe an index, we recommend that administrators enable role-based access control and keep these kinds of design elements in mind when assigning permissions to the intended group of users. See [Limit access by backend role](#advanced-limit-access-by-backend-role) for details.

## (Advanced) Limit access by backend role

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

First, make sure your users have the appropriate [backend roles]({{site.url}}{{site.baseurl}}/security/access-control/index/). Backend roles usually come from an [LDAP server]({{site.url}}{{site.baseurl}}/security/configuration/ldap/) or [SAML provider]({{site.url}}{{site.baseurl}}/security/configuration/saml/), but if you use the internal user database, you can use the REST API to [add them manually]({{site.url}}{{site.baseurl}}/security/access-control/api#create-user).

Next, enable the following setting:

```json
PUT _cluster/settings
{
"transient": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be transient or persistent? This seems appropriate as an example but not sure we want it in the "how to" section without specifying why one or the other.

Reading further this all seems like an example and should have its own "sample" or "example" header.

Copy link
Member Author

@owaiskazi19 owaiskazi19 Aug 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section explains the overall flow with the settings that needs be enabled. Not sure if "example" would the right header here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’ll let the doc review address that.

"plugins.flow_framework.filter_by_backend_roles": "true"
}
}
```

Now when users view Flow Framework 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:

```json
PUT _plugins/_security/api/internalusers/alice
{
"password": "alice",
"backend_roles": [
"analyst"
],
"attributes": {}
}
```

`bob` has a human-resources backend role:

```json
PUT _plugins/_security/api/internalusers/bob
{
"password": "bob",
"backend_roles": [
"human-resources"
],
"attributes": {}
}
```

Both `alice` and `bob` have full access to Flow Framework:

```json
PUT _plugins/_security/api/rolesmapping/flow_framework_full_access
{
"backend_roles": [],
"hosts": [],
"users": [
"alice",
"bob"
]
}
```

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

If users do not have backend roles, they still can view other users' Flow Framework results as long as they have `flow_framework_read_access`. This is the same for users who have `flow_framework_full_access`, as it includes all of the permissions as `flow_framework_read_access`. Administrators should inform users that having `flow_framework_read_access` allows for viewing of the results from any workflow in the cluster, including data not directly accessible to them. To limit access to the workflows results, administrators should use backend role filters at the time the workflow is created. This ensures only users with matching backend roles can access results from those particular workflows.
Loading