Skip to content

Commit

Permalink
Merge branch 'main' into feature/extensions
Browse files Browse the repository at this point in the history
  • Loading branch information
RyanL1997 committed Jul 13, 2023
2 parents 88f32e9 + 0e6608d commit 67515bc
Show file tree
Hide file tree
Showing 40 changed files with 1,392 additions and 218 deletions.
8 changes: 8 additions & 0 deletions .github/dependabot.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
version: 2
updates:
- package-ecosystem: "gradle"
directory: "/"
schedule:
interval: "weekly"
commit-message:
prefix: "dependabot:"
51 changes: 51 additions & 0 deletions DEVELOPER_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,7 @@ So you want to contribute code to OpenSearch Security? Excellent! We're glad you
- [Running integration tests](#running-integration-tests)
- [Bulk test runs](#bulk-test-runs)
- [Checkstyle Violations](#checkstyle-violations)
- [Authorization in REST Layer](#authorization-in-rest-layer)
- [Submitting Changes](#submitting-changes)
- [Backports](#backports)

Expand Down Expand Up @@ -78,6 +79,51 @@ mv config/* $OPENSEARCH_HOME/config/opensearch-security/
rm -rf config/
```

### Installing demo extension users and roles

If you are working with an extension and want to set up demo users for the Hello-World extension, append following items to files inside `$OPENSEARCH_HOME/config/opensearch-security/`:
1. In **internal_users.yml**
```yaml
hw-user:
hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG"
reserved: true
description: "Demo user for ext-test"
```
2. In **roles.yml**
```yaml
extension_hw_greet:
reserved: true
cluster_permissions:
- 'hw:greet'

extension_hw_full:
reserved: true
cluster_permissions:
- 'hw:goodbye'
- 'hw:greet'
- 'hw:greet_with_adjective'
- 'hw:greet_with_name'

legacy_hw_greet_with_name:
reserved: true
cluster_permissions:
- 'cluster:admin/opensearch/hw/greet_with_name'
```
3. In **roles_mapping.yml**
```yaml
legacy_hw_greet_with_name:
reserved: true
users:
- "hw-user"

extension_hw_greet:
reserved: true
users:
- "hw-user"
```
To install the demo certificates and default configuration, answer `y` to the first two questions and `n` to the last one. The log should look like below:

```bash
Expand Down Expand Up @@ -188,6 +234,11 @@ Checkstyle enforces several rules within this codebase. Sometimes it will be nec
// CS-ENFORCE-ALL
```
## Authorization in REST Layer
See [REST_AUTHZ_FOR_PLUGINS](REST_AUTHZ_FOR_PLUGINS.md).
## Submitting Changes
See [CONTRIBUTING](CONTRIBUTING.md).
Expand Down
136 changes: 136 additions & 0 deletions REST_AUTHZ_FOR_PLUGINS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,136 @@
# Authorization at REST Layer for plugins

This feature is introduced as an added layer of security on top of existing TransportLayer authorization framework. In order to leverage these feature some core changes need to be made at Route registration level. This document talks about how you can achieve this.

**NOTE:** This doesn't replace Transport Layer Authorization. Plugin developers may choose to skip creating transport actions for APIs that do not need interaction with the Transport Layer.

## Pre-requisites

The security plugin must be installed and operational in your OpenSearch cluster for this feature to work.

### How does NamedRoute authorization work?

Once the routes are defined as NamedRoute, they, along-with their handlers, will be registered the same way as Route objects. When a request comes in, `SecurityRestFilter.java` applies an authorization check which extracts information about the NamedRoute.
Next we get the unique name and actionNames associated with that route and evaluate these against existing `cluster_permissions` across all roles of the requesting user. If the authorization check succeeds, the request chain proceeds as normal. If it fails, a 401 response is returned to the user.

NOTE:
1. The action names defined in roles must exactly match the names of registered routes, or else, the request would be deemed unauthorized.
2. This check will not be implemented for plugins who do not use NamedRoutes.



### How to translate an existing Route to be a NamedRoute?

Here is a sample of an existing route converted to a named route:
Before:
```
public List<Route> routes() {
return ImmutableList.of(
new Route(GET, "/uri")
);
}
```
With new scheme:
```
public List<NamedRoute> routes() {
return ImmutableList.of(
new NamedRoute.Builder().method(GET).path("/uri").uniqueName("plugin:uri").actionNames(Set.of("cluster:admin/opensearch/plugin/uri")).build()
);
}
```

`actionNames()` are optional. They correspond to any current actions defined as permissions in roles.
Ensure that these name-to-route mappings are easily accessible to the cluster admins to allow granting access to these APIs.

### How does authorization in the REST Layer work?

We will continue on the above example of translating `/uri` from Route to NamedRoute.

Consider these roles are defined in the cluster:
```yaml
plugin_role:
reserved: true
cluster_permissions:
- 'plugin:uri'

plugin_role_legacy:
reserved: true
cluster_permissions:
- 'cluster:admin/opensearch/plugin/uri'
```
Successful authz scenarios for a user:
1. The user is mapped either to `plugin_role` OR `plugin_role_legacy`.
2. The user is mapped to both of these roles.
3. The user is mapped to `plugin_role` even if no `actionNames()` were registered for this route.

Unsuccessful authz scenarios for a user:
1. The user is not mapped any roles.
2. The user is mapped to a different role which doesn't grant the cluster permissions: `plugin:uri` OR `cluster:admin/opensearch/plugin/uri`/
3. The user is mapped to a role `plugin_role_other` which has a typo in action name, i.e.`plugin:uuri`.


### Sample API in Security Plugin

As part of this effort a new uri `GET /whoamiprotected` was introduced as a NamedRoute version of `GET /whoami`. Here is how you can test it:

#### roles.yml
```yaml
who_am_i_role:
reserved: true
cluster_permissions:
- 'security:whoamiprotected'
who_am_i_role_legacy:
reserved: true
cluster_permissions:
- 'cluster:admin/opendistro_security/whoamiprotected'
who_am_i_role_no_perm:
reserved: true
cluster_permissions:
- 'some_invalid_perm'
```

#### internal_users.yml
```yaml
who_am_i-user:
hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG" #admin
reserved: true
description: "Demo user for ext-test"
who_am_i_legacy-user:
hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG"
reserved: true
description: "Demo user for ext-test"
who_am_i_no_perm-user:
hash: "$2a$12$VcCDgh2NDk07JGN0rjGbM.Ad41qVR/YFJcgHp0UGns5JDymv..TOG"
reserved: true
description: "Demo user for ext-test"
```

#### roles_mapping.yml
```yaml
who_am_i_role:
reserved: true
users:
- "who_am_i-user"
who_am_i_role_legacy:
reserved: true
users:
- "who_am_i_legacy-user"
who_am_i_role_no_perm:
reserved: true
users:
- "who_am_i_no_perm-user"
```

Follow [DEVELOPER_GUIDE](DEVELOPER_GUIDE.md) to setup OpenSearch cluster and initialize security plugin. Once you have verified that security plugin is installed correctly and OpenSearch is running, execute following curl requests:
1. `curl -XGET https://who_am_i-user:admin@localhost:9200/_plugins/_security/whoami --insecure` should succeed.
2. `curl -XGET https://who_am_i_legacy-user:admin@localhost:9200/_plugins/_security/whoami --insecure` should succeed.
3. `curl -XGET https://who_am_i_no-perm-user:admin@localhost:9200/_plugins/_security/whoami --insecure` should fail.
4. `curl -XPOST ` to `/whoami` with all 3 users should succeed. This is because POST route is not a NamedRoute and hence no authorization check was made.
Loading

0 comments on commit 67515bc

Please sign in to comment.