Hawtio installation comes with a default
hawtio-rbac ConfigMap configmap-hawtio-rbac.yml, that contains the configuration file used to define the roles allowed for MBean operations.
This ConfigMap is mounted into the Hawtio Online container, and the
HAWTIO_ONLINE_RBAC_ACL environment variable is used to pass the configuration file path to the server.
If that environment variable is not set, RBAC support is disabled, and only users granted the
update verb on the pod resources are authorized to call MBeans operations.
For the time being, only the
admin roles are supported.
Once the current invocation is authenticated, these roles are inferred from the permissions the user impersonating the request is granted for the pod hosting the operation being invoked.
A user that's granted the
update verb on the pod resource is bound to the
admin role, i.e.:
$ oc auth can-i update pods/<pod> --as <user> yes
Else, a user granted the
get verb on the pod resource is bound the
viewer role, i.e.:
$ oc auth can-i get pods/<pod> --as <user> yes
Otherwise the user is not bound any roles, i.e.:
$ oc auth can-i get pods/<pod> --as <user> no
The ACL definition for JMX operations works as follows:
Based on the ObjectName of the JMX MBean, a key composed with the ObjectName domain, optionally followed by the
type attribute, can be declared, using the convention
For example, the
java.lang.Threading key for the MBean with the ObjectName
java.lang:type=Threading can be declared.
A more generic key with the domain only can be declared (e.g.
default top-level key can also be declared.
A key can either be an unordered or ordered map, whose keys can either be string or regexp, and whose values can either be string or array of strings, that represent roles that are allowed to invoke the MBean member.
The default ACL definition can be found in the
hawtio-rbac ConfigMap from the
The system looks for allowed roles using the following process:
The most specific key is tried first. E.g. for the above example, the
java.lang.Threading key is looked up first.
If the most specific key does not exist, the domain-only key is looked up, otherwise, the
default key is looked up.
Using the matching key, the system looks up its map value for:
An exact match for the operation invocation, using the operation signature, and the invocation arguments, e.g.:
uninstall(java.lang.String):  # no roles can perform this operation
A regexp match for the operation invocation, using the operation signature, and the invocation arguments, e.g.:
Note that, if the value is an ordered map, the iteration order is guaranteed, and the first matching regexp key is selected;
An exact match for the operation invocation, using the operation signature, without the invocation arguments, e.g.:
An exact match for the operation invocation, using the operation name, e.g.:
dumpStatsAsXml: admin, viewer
If the key matches the operation invocation, it is used and the process will not look for any other keys. So the most specific key always takes precedence.
Its value is used to match the role that impersonates the request, against the roles that are allowed to invoke the operation.
If the current key does not match, the less specific key is looked up and matched following the steps 1 to 4 above, up until the
Otherwise, the operation invocation is denied.