🚀 rbac: Ability to add plugin(s) with permissions to the plugins configuration for the rbac-backend via the UI or API

[mcintoac-aws]

Plugin Name

rbac

🔖 Feature description

The ability to add plugin(s with permissions to the RBAC plugin's configuration via the RBAC UI and/or an API endpoint.

🎤 Context

Currently, plugins with permissions are added to the RBAC plugin's configuration via the app-config.yaml file, specifically the pluginsWithPermissions field which expects an array. On deploy, the RBAC plugin with search the listed plugins for all permissions, and there will be populated into the backend database. They can then be assigned via the UI, or seen via the API endpoint /api/permission/plugins/policies. See docs for examples.

For some Backstage customers, plugins will be added to their deployment dynamically. In this case, it would be necessary to retrieve the permissions from those dynamically added plugins after the initial deploy, so those permissions can be assigned to permission policies. Currently, this is not possible, and would require redeploying the Backstage instance with an updated app-config.yaml.

✌️ Possible Implementation

At minimum, implement an API endpoint to add a plugin or individual plugin permissions to the permissions storage.

Ideally, this would also be available via the RBAC UI.

👀 Have you spent some time to check if this feature request has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

Are you willing to submit PR?

Yes I am willing to submit a PR!

[PatAKnight]

Hello! and thank you for opening up a feature request for the RBAC backend plugin

Yep, this makes sense to me. And I don't believe this would be too difficult. However, we would need to get our frontend team involved since there would be changes to the frontend as well.

Another alternative or potential complementary solution would be to also handle the changes that are made to the app-config. I believe (need to double check) that the config api grabs the latest version of the app-config. We could then use that to ensure that the plugin permissions that are returned is up to date.

At this time, I will pass this feature request on over to our PM for review.

[mcintoac-aws]

Thanks for the response @PatAKnight .

Could you elaborate what you mean by "the config api grabs the latest version of the app-config."? I was under the impression the config was only used at deploy time, and once deployed, the configuration for the Backstage deployment is set. The config API can be used to get config values from the app-config file, that is correct, but I'm not exactly sure how or why that could be utilized to ensure plugin permissions are up to date. Can you elaborate more on the use case?

Regarding what you said for getting the front-end team involved. I think that is a good point, however I would personally say the front-end feature is a "nice-to-have" and secondary to an API endpoint that allows for updating the plugin permission list. Currently the API has a "GET" method for the plugin policies, but simply an API endpoint to add a new plugin and perform a discovery of the permissions for that plugin would be enough to satisfy this requirement. Integrating that API endpoint into a Backstage instance can be done via a bespoke front-end implementation, or many other methods for trigger the API (scheduled discovery, manually triggering the API, etc.).

I'd personally advocate for first focusing on an API endpoint that at least makes adding a new plugin to the deployment possible, before focusing on front-end, combining it with app-config discovery, etc. What are your thoughts, and how large of a lift do you think the described API endpoint would be?

[PatAKnight]

Yeah, so from my understanding the app-config files are watched by default. So any changes to the config files are automatically updated and can be consumed by plugins. At the moment, this feature isn't utilized within the RBAC backend plugin.

As for a potential use case, instead of needing to call the RBAC API to include the new plugin, you could just update it using the following:

permission:
  enabled: true
  rbac:
    pluginsWithPermission:
      - kubernetes
      - jenkins
      - <SOME_PLUGIN_ID>

This would ensure that the plugin list is updated to reflect the new plugin.

And yep, I just defaulted to API needs UI and never went back after reading it 😄. But I agree that this could easily start as an API endpoint and then we could review to see if there is a demand for a UI component as well.

As for implementation, I believe that we just need to ensure that the list of plugin ids is updated. It looks like we just set and forget. Then instead of setting it the one time in the constructor, we could query the list whenever we go to retrieve the metadata.

@AndrienkoAleksandr what do you think?

[mcintoac-aws]

Yeah, so from my understanding the app-config files are watched by default. So any changes to the config files are automatically updated and can be consumed by plugins.

So this sounds similar to the concept of the policyFileReload setting. One thing I'm not really sure of is how, if at all, this applies to our use case. In our case, once deployed, the app-config file can not be updated. We perform a deploy via Docker Image using an ECS container, so the config files are not easily updatable at that point without redeploying the container/instance.

Am curious to here @AndrienkoAleksandr thoughts on how easy of an addition this would be via API given your links and suggested implementation.