[
https://issues.apache.org/jira/browse/ARTEMIS-4582?focusedWorklogId=908716&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-908716
]
ASF GitHub Bot logged work on ARTEMIS-4582:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 07/Mar/24 11:03
Start Date: 07/Mar/24 11:03
Worklog Time Spent: 10m
Work Description: gemmellr commented on code in PR #4820:
URL: https://github.com/apache/activemq-artemis/pull/4820#discussion_r1515899178
##########
docs/user-manual/management.adoc:
##########
@@ -362,6 +366,63 @@ The `*` access is the catch all for everything other
method that isn't specifica
The `default-access` element is basically the catch all for every method call
that isn't handled via the `role-access` configuration.
This has the same semantics as a `match` element.
+
+==== JMX authorisation in broker.xml
+The existing
xref:security.adoc#role-based-security-for-addresses[security-settings] can be
used for JMX RBAC.
+
+Using the `view` and `update` permissions on matches in security-settings
provides an alternative to the authorization section in management.xml.
+Using a single security model based on addresses, with reloadable
configuration, simplifies operation.
+
+An xref:management.adoc#artemis_rbac_mbean_server_guard[MBeanServer
interceptor] that delegates to the broker security manager must be configured
with a JVM system property that allows it to be added to all MBeanServers in
the JVM.
+
+This is configured via a system property as follows:
+
+[,sh]
+----
+ java
-Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder
+----
+NOTE: When this property is provided, the authorization section of
management.xml should be omitted as that depends on an alternative MBeanServer
interceptor.
Review Comment:
I wonder if this should go with WARNING or IMPORTANT to make it more
prominent, given its essential to using this rather than just nice to know info.
I also wonder if the broker code should try detecting and enforcing that a
mixture wont work..cant say I recall seeing anything around that?
##########
docs/user-manual/security.adoc:
##########
@@ -68,6 +68,14 @@ This permission allows the user to browse a queue bound to
the matching address.
manage::
This permission allows the user to invoke management operations by sending
management messages to the management address.
+The following two permissions pertain to operations on the management apis of
the broker. They split management operations into two sets, read only for
`view`, and `update` for mutating operations. The split is controlled by a
regular expression. Methods that match will require the `view` permission, all
others require `update`. The regular expression can be modified through the
configuration attribute `view-permission-method-match-pattern`. These
permissions are applicable using a suffix on the management address, and with a
`jmx.` prefix for MBean access.
+
+view::
+This permission allows access to a read-only subset of management operations.
+
+update::
+This permission allows access to the mutating management operations, any
operation not in the `view` set.
+
Review Comment:
This isnt clear that these only apply when using the optional alternative
broker.xml management security + alternative mbean guard that most wont
actually be using yet when reading this, given management.xml security is the
default. Add sentence with mention + link to it?
##########
docs/user-manual/management.adoc:
##########
@@ -585,7 +656,32 @@ This is also configured in broker.xml:
</security-setting>
----
-=== Example
+==== Fine grained RBAC on management messages
+There is optional RBAC on the content of the management messages sent to the
management address.
+
+RBAC is enabled by providing a value for the attribute
xref:configuration-index.adoc#management_rbac_suffix[management-rbac-suffix].
+With a `management-rbac-suffix` of `.control.` more fine-grained permissions
on the management address can be configured using that suffix appended to the
management address.
Review Comment:
It isnt made clear this only applies if using the broker.xml based
management security and alternative mbean guard, which if not doing that (the
default) seems like it would limit its effectiveness? What will this do
otherwise, anything? (Back to earlier comment about detection/enforcement for
such config mismatch)
Also isnt clear if the "manage" role is still needed on
"activemq.management" per the earlier config, i.e if the examples below are
additional or instead of the earlier covered config. A note either way could
resolve that (or adding it to the example if its still needed).
##########
docs/user-manual/management.adoc:
##########
@@ -250,8 +251,11 @@ It can be disabled by setting `jmx-management-enabled` to
`false` in `broker.xml
==== Role Based Authorisation for JMX
-Although by default Artemis uses the Java Virtual Machine's `Platform
MBeanServer` this is guarded using role based authorisation that leverages the
broker's JAAS plugin support.
-This is configured via the `authorisation` element in the `management.xml`
configuration file and can be used to restrict access to attributes and methods
on MBeans.
+Artemis uses the Java Virtual Machine's `Platform MBeanServer` by default.
This is guarded using role based authorisation that leverages the broker's JAAS
plugin support.
+
+The RBAC used to restrict access to Mbeans and their operations can be
configured in two ways, via security-settings in broker.xml, described in
xref:management.adoc#jmx-authorisation-in-broker-xml[JMX authorisation in
broker.xml], or via the `authorisation` element in the `management.xml` that is
described below.
+
Review Comment:
Given the management.xml one is the long standing one and the default out
the box, feels like it should be mentioned first. The mutually-exclusive nature
of the two could also be made clearer here, maybe using "one of two ways", or
adding "alternatively" or such similar to the new section itself further down.
##########
docs/user-manual/security.adoc:
##########
@@ -153,9 +161,22 @@ You can do this using the fully qualified queue name (i.e.
FQQN) in the `match`
</security-setting>
----
-NOTE: Wildcard matching doesn't work in conjuction with FQQN.
+NOTE: Wildcard matching doesn't work in conjunction with FQQN.
The explicit goal of using FQQN here is to be _exact_.
+=== Applying view and update permissions
Review Comment:
Applying _management_ view and update permissions?
##########
docs/user-manual/management.adoc:
##########
@@ -362,6 +366,63 @@ The `*` access is the catch all for everything other
method that isn't specifica
The `default-access` element is basically the catch all for every method call
that isn't handled via the `role-access` configuration.
This has the same semantics as a `match` element.
+
+==== JMX authorisation in broker.xml
+The existing
xref:security.adoc#role-based-security-for-addresses[security-settings] can be
used for JMX RBAC.
+
+Using the `view` and `update` permissions on matches in security-settings
provides an alternative to the authorization section in management.xml.
+Using a single security model based on addresses, with reloadable
configuration, simplifies operation.
+
+An xref:management.adoc#artemis_rbac_mbean_server_guard[MBeanServer
interceptor] that delegates to the broker security manager must be configured
with a JVM system property that allows it to be added to all MBeanServers in
the JVM.
+
+This is configured via a system property as follows:
+
+[,sh]
+----
+ java
-Djavax.management.builder.initial=org.apache.activemq.artemis.core.server.management.ArtemisRbacMBeanServerBuilder
+----
+NOTE: When this property is provided, the authorization section of
management.xml should be omitted as that depends on an alternative MBeanServer
interceptor.
+
+The addresses used for JMX RBAC use the `jmx.` prefix. This allows independent
RBAC between messaging operations and JMX operations.
+
+The MBeanServer guard maps JMX MBean ObjectNames to a hierarchical address of
the general form:
+
+ jmx.<.jmx domain><.type><.component><.name>[.operation]
+
+NOTE: for the broker domain, the domain is omitted.
+
+
+For example, to give the `admin` role `view` and `update` permissions on all
MBeans, use the following security-setting:
+
+[,xml]
+----
+<security-setting match="jmx.#">
+ <permission type="view" roles="admin"/>
+ <permission type="update" roles="admin"/>
+</security-setting>
+----
+
+To grant the `managerRole` role `view` permission to just the
`activemq.management` address, target the `address` component with name
`activemq.management` and with `.*` to include all operations.
+
+[,xml]
+----
+<security-setting match="jmx.address.activemq.management.*">
+ <permission type="view" roles="managerRole"/>
+</security-setting>
+----
+
+
+To ensure no user has permission to xref:management.adoc#force_failover[force
a failover] using the broker (server control) MBean, use the following that
defines the empty roles set for a particular mutating operation on the `broker`
component:
+[,xml]
+----
+<security-setting match="jmx.broker.forceFailover">
+ <permission type="update" roles=""/>
+</security-setting>
+----
+
+NOTE: all attribute access `get|is[attribute]` maps to a method named
getAttribute for RBAC purposes. All other operations require a literal match.
Review Comment:
Its not 100% clear this note is saying that e.g getFoo/isFoo and
getBar/isBar all map to only getAttribute, as opposed to just the isFoo/getFoo
being rationalised to getFoo. Adding similar foo/bar differentiated-attributes
example might make it clearer if so.
Its also not clear whether it rules out still using a literal match or not.
Issue Time Tracking
-------------------
Worklog Id: (was: 908716)
Time Spent: 1.5h (was: 1h 20m)
> add view and update permissions to augment the manage rbac for control
> resources
> --------------------------------------------------------------------------------
>
> Key: ARTEMIS-4582
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4582
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker, Configuration, JMX, Web Console
> Affects Versions: 2.31.0
> Reporter: Gary Tully
> Assignee: Gary Tully
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> we have the manage permission that allows sending to the management address,
> to access any control resource. We don't however distinguish what a user can
> do.
> We should segment control operations into categories: CRUD provides a basis
> view for get/is (Read)
> update for set or operations that mutate or modify.
> We allow this sort of configuration via management.xml for jmx mbean access
> but using a different model based on object name.
> All of the mbeans delegate to the control resources.
> If we add these two additional permissions then we can have a single rbac
> model (that supports config reload) and more granularity on control resource
> access from the management address.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
