Create new endpoints on the api-server to execute specific jolokia operations instead of relying on execBrokerOperations

[lavocatt]

At the moment the api-server exposes 3 kind of operations:

• list a component (addresses, queues)
• list all the broker operations that can be performed on a component
• execute a broker operation

ATM we have to use the execBrokerOperations to fetch details on components, such as number of messages for a queue or to change aspects of the broker. The execBrokerOperations is a very powerful call, it allows to change & update every aspects of the broker.

For me exeBrokerOperations pose a few issues:

• being able to execute it in the front-end can allow a user to bypass the UI and do what they want on the broker
• the operation details are fetched at runtime, that means we can't rely on code generation and Typescript types to make calls to these endpoints
• the parameter syntax needs custom parsing.

What if instead we would rely on specific endpoints to perform theses tasks and avoid exposing such a powerfull call into the frontend?

For an example, let's take a task that would involve listing the number of messages exchanged on an address.

We could add a new endpoint /addresses/messagesCount that would return a json object containing stats about the in flight messages:

{
 messages_in: 1000,
 messages_out: 80,
}

The api-server would take care of 'knowing' all the details necessary to perform the underlying jolokia requests. This would:

• allow the code generation to create the code ready to use for the frontend
• hide the details about execBrokerOperations from the user
• make us worry less about parsing in the frontend, and reducing bug exposure

Another advantage of having specific endpoints is that we will be able to unit test them using the test suite @howardgao designed.

What's your opinion on this?

[RoddieKieley]

@lavocatt This sounds like a good idea, for the three reasons that you listed specifically. Of those the first
"being able to execute it in the front-end can allow a user to bypass the UI and do what they want on the broker"
is quite important and has been the focus of a number of simplification efforts within the broker itself leading to the introduction of a new rbac model based on just view/update type permissions.

We should also be cognizant of that split and take it into account. @gtully Do you have a reference to your recent work in this area?

[gtully]

The use of VIEW/EDIT roles for JMX rbac is exercised in this test: https://github.com/artemiscloud/activemq-artemis-operator/blob/10d916aa1f3e7503d7ea2a09365c11025b5ed35f/controllers/activemqartemissecurity_broker_properties_test.go#L115

it is a simplification, that makes use of the existing broker security settings. It means that all jolokia access that delegates to jmx will need an authenticated subject.

In terms of the api-server, I agree. I think it needs to be task driven, 70% of the broker management api will not be relevant, especially with a move to the CR being the source of truth for config, and metrics being the way to monitor (we have work to do there). The UI can be the answer when there is a fix that requires specific intervention, or a task that requires specific answers that can be input onto a defined process that gets us to a problem solution.
Find the queue that has more than 10K pending large messages and purge it! We don't want to list all the queues page by page to get this sort of info. It may need a new broker side api to achieve this task efficiently, without impacting current users.
lots of the existing jmx apis do not really support paging or efficient search so will break at scale. A task focus will allow us to develop new apis that are fit for purpose.

[lavocatt]

We are already starting to implement part of this idea in the following PRs:

• [#141] Adding new api /readAddressAttributes #142
• [Addresses page]: Integrate API for address data #140

In these PRs we are updating the endpoints so that they are returning a comprehensive json object documented in the openapi.yaml file. The codegen creates as a result all the typesript types we need for the frontend.

This results in less manual parsing on the frontend side.

[lavocatt]

@howardgao has created a related issue #146

[gaohoward]

I think we should separate the concerns with regard to the access control into 3 parts

1. The front-end openshift console. When user login to the console to access the plugin, it has a role (e.g. admin/developer). The plugin may choose to present different components to show depending on the log in roles

2. The back-end management access control. (i.e. the management.xml) It can console access to the apis based on login roles
   (this is what Gary is talking about)

3. the api-server. Currently it doesn't have its own access control. It is like a proxy and uses broker credentials to access jolokia endpoints. The broker credentials is supplied from the plugin frontend. So it subjects to the backend broker authentication/authorization. Note currently the api-server only have a limit set of apis to access a jolokia endpoint. More are expected to be added to the api-server to satisfy the frantend dev needs.

We can evaluate what need to do on the api-server end that aren't covered by the other two.