In a previous post, we saw a new Karaf feature: support of user groups and Role-Based Access Controle (RBAC) for the JMX layer.
We extended the RBAC support to the OSGi services, and by side effect to the console commands (as a console command is also an OSGi service).
RBAC for OSGi services
The JMX RBAC support uses a
KarafMBeanServerBuilder “intercepts” the call to the MBeans, checks the definition (defined in
etc/jmx.acl.*.cfg configuration files) and defines if the call can be performed or not.
Regarding the RBAC support for OSGi services, we use a similar mechanism.
The Karaf Service Guard provides a service listener which intercepts the service calls, and check if the call to the service can be performed or not.
The list of “secured” OSGi service is defined in the
karaf.secured.services property in the
etc/system.properties (using a LDAP syntax filter).
By default, we only “intercept” (and so secure) the command OSGi services:
karaf.secured.services = (&(osgi.command.scope=*)(osgi.command.function=*))
The RBAC definition itself are stored in
etc/org.apache.karaf.service.acl.*.cfg configuration files, similar to the
etc/jmx.acl*.cfg configuration files used for JMX. The syntax in this file is the same.
RBAC for console commands
As the console commands are actually OSGi services, the direct application of the OSGi services RBAC support is to secure the console commands.
By default, we secure only the OSGi services associated to the console commands (as explained early in the
The RBAC definition on the console commands are defined in the
etc/org.apache.karaf.commands.acl.*.cfg configuration files.
You can define one configuration file by command scope. For instance, the
etc/org.apache.karaf.commands.acl.bundle.cfg configuration file defines the RBAC for the
For instance, in the
etc/org.apache.karaf.commands.acl.bundle.cfg configuration file, we can define:
install = admin refresh[/.*[-][f].*/] = admin refresh = manager restart[/.*[-][f].*/] = admin restart = manager start[/.*[-][f].*/] = admin start = manager stop[/.*[-][f].*/] = admin stop = manager uninstall[/.*[-][f].*/] = admin uninstall = manager update[/.*[-][f].*/] = admin update = manager watch = admin
The format is
For instance, in this file we:
bundle:watchcommands only for the users with the
bundle:updatecommands with the
-foption (meaning executing these commands for “system” bundles) only for the users with the
- all other commands (not matching the two previously defined rules) can be executed by the users with the
By default, we define RBAC for:
bundle:*commands (in the
config:*commands (in the
feature:*commands (in the
jaas:*commands (in the
kar:*commands (in the
shell:*commands (in the
system:*commands (in the
This RBAC rules apply on both “local” console and remote SSH console.
As you don’t really logon the “local” console, we have to define the “roles” that we can use in the “local” console.
These “local” roles are defined in the
karaf.local.roles in the
etc/system.properties configuration file:
karaf.local.roles = admin,manager,viewer
We can see that, when we use the “local” console, the “implicit local user” will have the admin, manager, and viewer roles.