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

Authorize Requests bound for extensions in the REST-Layer #2601

Closed
wants to merge 30 commits into from

Conversation

cwperks
Copy link
Member

@cwperks cwperks commented Mar 29, 2023

Description

This PR relies on an earlier PR to setup extension TLS and handshake with security plugin: #2599

This PR has companion PRs in Core and SDK repo:

Core - opensearch-project/OpenSearch#6870
SDK - opensearch-project/opensearch-sdk-java#622

Isolated changes for this PR can be viewed with the compare tool: cwperks/security@extension-tls...extension-role

This PR creates a RestLayerPrivilegesEvaluator and adds a new area of the role definition called extension_permissions that act the same as cluster permissions, but are evaluated on the REST-layer for requests bound for extensions.

See an example role with extension permissions:

# Roles for Hello World extension, roles that extensions would like to add should be ultimately be defined elsewhere
extension_hw_greet:
  reserved: true
  extension_permissions:
    - 'extension:hw/greet'

extension_hw_full:
  reserved: true
  extension_permissions:
    - 'extension:hw/greet'
    - 'extension:hw/greet_with_adjective'
    - 'extension:hw/great_with_name'
    - 'extension:hw/goodbye'

I added these roles here, but roles like this should be requests by the extension to add to a cluster and if granted by the cluster admin, added to the full roles list.

  • Category (Enhancement, New feature, Bug fix, Test fix, Refactoring, Maintenance, Documentation)

New Feature

Issues Resolved

Testing

Tested by assigning users the roles created in this PR and verified that they are permitted or blocked based on what has been granted. Automated tests to follow, I wanted to get a draft out to determine if this is the right direction to head in.

Check List

  • New functionality includes testing
  • New functionality has been documented
  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@cwperks cwperks changed the title Extension role Authorize Requests bound for extensions in the REST-Layer, add extension_permissions section to roles Mar 29, 2023
Signed-off-by: Craig Perkins <[email protected]>
Copy link
Contributor

@stephen-crawford stephen-crawford left a comment

Choose a reason for hiding this comment

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

Hi Craig, great work with this. I know you are still in a draft but I wanted to give you feedback early to help. Overall I think this looks good, I just had a few comments but nothing major outside of eventually hoping for tests once you get the PR further along. Looks good!

@@ -326,3 +326,17 @@ security_analytics_ack_alerts:
reserved: true
cluster_permissions:
- 'cluster:admin/opensearch/securityanalytics/alerts/*'

# Roles for Hello World extension, roles that extensions would like to add should be ultimately be defined elsewhere
extension_hw_greet:
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it possible to parse this from the Hello World config? I know you have made changes in the SDK, I am not sure what would be required to read in these roles as part of the registration/installation process.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that is ultimately where these should go! I wanted to open up a PR to show REST-layer authz in action with an example role. This issue is about letting an extension pre-define roles and sourcing them into the security configuration.

return configModel !=null && configModel.getSecurityRoles() != null && dcm != null;
}

public PrivilegesEvaluatorResponse evaluate(final User user, String action0) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This may be hit further up in the call chain. For instance the plugin itself probably cannot get the request to this point if security is not initialized.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's exactly how this would work. This evaluator is used in the REST handler wrapper which means this is executed before the original handler is called. If the request is not authorized, the original handler will never be called.

Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think it makes more sense to have this as a separate file or as part of the existing privileges evaluator logic? It may be possible to add this as a subroutine of the existing code if you were so inclined.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it makes sense as a separate file since it takes different parameters to instantiate this evaluator. This is a fresh slate to work with and much smaller in size that the transport layer PrivilegesEvaluator.

This PR doesn't cover how index permissions from plugins will be converted to extensions. i.e.

cross_cluster_replication_leader_full_access:
  reserved: true
  index_permissions:
    - index_patterns:
        - '*'
      allowed_actions:
        - "indices:admin/plugins/replication/index/setup/validate"
        - "indices:data/read/plugins/replication/changes"
        - "indices:data/read/plugins/replication/file_chunk"

will not be able to be ported with this PR alone. There will need to be work done to authorize requests that take in resource names like index patterns.

This PR will work for all plugin cluster_permissions.

Copy link
Contributor

Choose a reason for hiding this comment

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

Sounds good to me!

.findFirst();
if (handler.isPresent() && handler.get() instanceof ProtectedRoute) {
String action = ((ProtectedRoute)handler.get()).name();
PrivilegesEvaluatorResponse pres = evaluator.evaluate(user, action);
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this is a draft so maybe you have not gotten there yet, but I thought that the evaluator only operates based on role resolution. If this is the case, what is your plan for hosting the REST routes in this mechanism? Are you making each extension add a role with the route as a permission string or are we going to add a new role used to hold these routes or something else?

@@ -20,6 +20,8 @@ all_access:
- "*"
allowed_actions:
- "kibana_all_write"
extension_permissions:
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we going to be adding a new field to all roles designated as extension permissions?

Copy link
Member

@peternied peternied left a comment

Choose a reason for hiding this comment

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

This design tightly couples extensions to the security plugin's roles and permissions. As extensions are new, we should use the simplest concepts to provide permissions and access.

The features to govern extension capabilities are being developed within OpenSearch core. Lets wait on that work to come together before spending more cycles here.

@cwperks
Copy link
Member Author

cwperks commented May 8, 2023

@peternied We need guidance on how to proceed then. This introduces an entirely new section in a roles definition to make it clear that these are permissions associated with an extension action, provide flexibility for the future if extension permissions can include resource names like index patterns and will allow for backward compatibility between the plugin version of an extension and an extension.

@cwperks
Copy link
Member Author

cwperks commented May 8, 2023

@peternied This PR creates an analog to roles that plugins add to the security plugin's roles.yml. These roles give access to users to use different REST actions registered by an extension the same way that an admin would for plugins. Can you please list out the design concerns you have specifically so they can be addressed? This PR has been open for over a month for review. Please be specific.

@cwperks
Copy link
Member Author

cwperks commented May 8, 2023

As extensions are new, we should use the simplest concepts to provide permissions and access.

@peternied This doesn't meet the objective of being a replacement for an existing plugin like AD. Without any guidance more specific I am planning to continue working on the design as-is. Please comment on the design with any specific concerns so they can be addressed. This PR has been open for more than a month and there is ample comments on multiple issues about the design.

Signed-off-by: Craig Perkins <[email protected]>
@cwperks
Copy link
Member Author

cwperks commented May 8, 2023

@peternied This now gets rid of the extensions_permission section and instead utilizes existing cluster_permissions. The roles for the HelloWorld Extension are now defined as:

extension_hw_greet:
  reserved: true
  cluster_permissions:
    - 'hw:greet'

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

Signed-off-by: Craig Perkins <[email protected]>
@DarshitChanpura DarshitChanpura mentioned this pull request May 9, 2023
3 tasks
@cwperks cwperks changed the title Authorize Requests bound for extensions in the REST-Layer, add extension_permissions section to roles Authorize Requests bound for extensions in the REST-Layer May 15, 2023
@DarshitChanpura
Copy link
Member

@cwperks Would you want to close this in lieu of #2753. I'm fine either way, but wanted to know your thoughts

@cwperks
Copy link
Member Author

cwperks commented May 16, 2023

@DarshitChanpura I will close this one, it looks like your branch is a bit further along. I will also synchronize the PRs in core and the SDK today and try to chase the maintainers for a review of those PRs as they have been open for a while.

@cwperks
Copy link
Member Author

cwperks commented May 22, 2023

Closing in favor of: #2753

@cwperks cwperks closed this May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants