karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: Role based security for Karaf JMX access
Date Mon, 12 Aug 2013 03:44:25 GMT
Awesome, this fine-grained security is what Karaf want for a long time.
Adding it to the JMX access definitely is a good start, also looking forward to this improvement
on Karaf console command.
+1 for all the input here.
-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋



On 2013-8-6, at 下午6:22, davidb@apache.org wrote:

> Hi all,
> 
> I have started an implementation of Role based security for JMX access into
> Karaf.
> Up until now, remote JMX access was guarded by one role. If you had that
> role you could access everything. With my changes you can define roles
> (ACLs) per MBean, per method or based on arguments to an MBean invocation.
> There are also wildcards that can be used to define general rules for all
> MBeans which provide default behaviour for any MBean which doesn't have a
> specific ACL.
> 
> It works like this.
> The bin/karaf launch script sets -Djavax.management.builder.initial to
> specify a Karaf-provided MBean Server Builder. This builder
> guards/intercepts any MBean invocations and checks the roles of the current
> user for the current invocation. These roles are set through the existing
> Karaf JAAS intergration. If the current user doesn't have the required
> roles an exception is thrown and the invocation does not proceed.
> 
> ACLs for the various MBeans are defined alongside other Karaf configuration
> in the cfg/ directory and read through OSGi ConfigAdmin. The PID/file name
> is based on the MBean Object Name, for example an MBean called
> org.apache.karaf:type=bundles,name=root is mapped to a file
> jmx.acl.org.apache.karaf.bundles.root.cfg. This file can contain an ACL
> like this:
>  list : viewer, manager
>  restart : manager
>  stop(java.lang.String)["0"] : admin # String argument match
>  stop(java.lang.String)[/([1-4])?[0-9]/] : admin # Regexp argument match
>  stop(java.lang.String) : manager # any other arguments match this
> 
> If no rules can be found for the current invocation the system will search
> in a higher level cfg file, with as highest level jmx.acl.cfg which
> contains the following 'catchall' rules.
>  get* : viewer
>  is* : viewer
>  set* : admin
>  * : admin
> Whenever a matching rule is found, that is used and the code doesn't look
> any further. So the most specific definition wins.
> 
> Certain rules need to have broad access, e.g. an admin role. It's not
> practical to have to specify 'admin' as a role with every single access
> control declaration. For this I have introduced groups. While other
> solutions might be possible, groups are widely supported in security
> systems so I used those.
> E.g. to address the 'admin' use-case above you might have a user (joe) who
> needs rights to every MBean in the system. For this you add joe to the
> AdminGroup. The AdminGroup then has every role that is defined in the
> system. It's not magic, because every time you add a new role to the system
> you need to update the AdminGroup, but it's manageable.
> 
> Finally I added a special MBean org.apache.karaf.security that allows you
> to find out whether the current user has the right roles to use a certain
> mbean or invoke a certain invocation. This can be used when building a
> management console/GUI to hide things that map to operations that the
> current user has no right to anyway. It's not 100% watertight in the sense
> that a specific role can be specified for a specific value (e.g. only
> 'admin' can stop bundle 0), so there is still a chance that the attempted
> invocation is rejected, but in general it should be a help to building
> smart consoles. BTW I'm planning to add bulk operations to this one, that's
> still a to-do.
> 
> Couple of notes:
> * It's all very pluggable. You can switch JAAS back-ends, ConfigAdmin
> implementations, or even the whole JMX guard implementation (which is not
> very big) by specifying another MBean Server Builder.
> * You can log into JMX without credentials when using a local JConsole or
> directly in the process. When no credentials are found the JMX guard will
> refuse any operation.
> * I added a bunch of Karaf Console commands to administer JAAS groups.
> * JAAS Groups are not yet supported by all JAAS/Karaf backends. I added it
> to the PropertiesBackingEngine. They can be added gradually.
> * The idea is to also add Role-based Access to the Karaf Console commands
> at some point going forward, but that's a separate piece of work...
> 
> So... the question is: would the Karaf community be interested in this Role
> based JMX security? I would be more than happy to donate it. My current
> implementation can be viewed in here:
> * addition of group support:
> https://github.com/bosschaert/karaf/commit/6598f088c53aa5bce217cdc2e066a96f8f3d5d37
> * role-based access to JMX:
> https://github.com/bosschaert/karaf/commit/bfee2d1b2c736c9b54cbfce8e4b07c8cfadf980f
> 
> Best regards,
> 
> David
> 
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message