Allow extensions to register roles

[cwperks]

Plugins can register roles by adding new roles to roles.yml. The roles are added to the cluster on bootstrap of a fresh cluster installation, by running securityadmin.sh or by using the API to create the roles.

Extensions need a way to register roles with a list of actions and have the roles sourced to the opensearch security index on extension installation.

An example of this for the HelloWorld extension could look like:

# Roles for Hello World extension, roles that extensions would like to add should be ultimately be defined by the extension
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'

Inside of extensions/extensions.yml there should be a setting for a cluster admin to configure to allow the registration of roles.

i.e.

extensions:
  - name: hello-world
    uniqueId: hw
    hostAddress: '127.0.0.1'
    port: '4532'
    version: '1.0'
    opensearchVersion: '3.0.0'
    minimumCompatibleVersion: '3.0.0'
    roles:
      - 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'

[stephen-crawford]

[Triage] This is part of the Extensions project.

[peternied]

By putting roles into the extension configuring this tightly couples the security plugin's permissions model to extensions. This seems like it will have significant drawbacks for compatibility going forward. We should be careful what goes into the extension configuration from an administrators perspective. I'd recommend index high on intuitive and self-explanatory.

I suggest we do not engage on this work until its needed, as much as it isn't ideal living with the roles being hardcoded into the security plugin has worked to date. We will need to figure out how to engage with permissions especially in a way that allows non-security plugins to function with extensions ecosystem. This is outside the critical path of the work that needs to be delivered for extensions

[davidlago]

+1

Based on a few open issues and PRs it seems like we're getting to the part of the Extensions project where some of these abstractions start to leak in favor of backwards compatibility. Though necessary to support the current plugin model, I agree with @peternied that we should defer these decisions as much as possible if they are not on the critical path to having an extension working end to end leveraging the security plugin constructs. This will feel awkward for sure, but it is a temporary state... we'll pounce at the 3.0 opportunity :)

[cwperks]

@peternied I'm ok with deprioritizing, but the current model of accepting a PR for every plugin/extension that wants to define roles to map to a user is unsustainable imagining a future with many extensions in a catalog. I believe its possible to create a generic hook where an IdentityPlugin can extend the settings inside extensions/extensions.yml to define settings that it needs and then hook into the extension bootstrap process to react to the settings being read in extensions.yml and act accordingly. In the case of the security plugin that would mean sourcing reserved roles that do not yet exist into the roles section of the security index.

[stephen-crawford]

@davidlago, what do you think about moving back to Backlog (Extensions)? I have a couple concerns about the registration process for new extensions that I think this issue would help address. @cwperks mentioned it above, but to restate: I am not sure how well the current model will scale.

It will work for the immediate future, but once we get more and more custom extensions (the goal), the process of registering the new roles with a PR to the Security repo will quickly become untenable. I could also see some concerns arising around a custom configuration where someone adds roles to the Security plugin and then uninstalls the extension but the roles still remain.

Because we cannot guarantee that a custom role will not have generic privileges, you could end up having "ghost roles" where a user continues to have escalated generic permissions even if a given extension no longer exists. By adding the feature Craig mentions here, we can avoid this since the bootstrap process would dynamically add the roles each spin-up.

I don't think this feature is P0 for Extensions but I do think it is something required P1-P2.

I also think that Sam and Maciej would do an excellent job tackling this should either decide to take it on.