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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
