JBoss Fuse - Securing Jolokia

Following a recent JBoss Fuse project for one of our Red Hat Clients, Principal Consultant Alan Fryer explains how to secure access to the JMX

JBoss Fuse provides a feature-rich console used to manage Fabric Profiles, view logs and monitor the system health. The console is based on HawtIO, and provides access to JMX MBean attributes and operations via an embedded Jolokia agent, which uses a REST like interface using the JSON-over-HTTP protocol.

The default configuration for Jolokia provides full access to the JMX MBeans attributes and operations, so it is important for system admins to lock down access to these in production environments. In this article I’ll cover the basic steps used to secure access to the REST interface used by the Jolokia agent.

Jolokia requests can be set as a HTTP GET, where the parameters are encoded in the URL, or as an HTTP POST, where the request is added to a JSON payload in the HTTP request's body. The response returned is always in a JSON format.  

Jolokia provides access to the JMX MBeans using the following operations:

  • Read: Reading MBean attribute values
  • Write: Setting MBean attribute values
  • Exec: Execute exposed MBean operations
  • Search: Search for MBeans in a Domain
  • List: Lists accessible MBeans along with their supported attributes and operations
  • Version: Returns the version of the Jolokia agent along with the protocol version

Jolokia can be configured with an XML security policy file which allows for fine grained security of the JMX MBeans.  

Access restrictions can be configured for MBean, attributes, operations, source IP addresses and type of Jolokia operation in the Jolokia security policy which are described below:   

IP Based Restrictions

Access can be granted based on the IP address of an HTTP client. These restrictions are specified within a <remote> section, which contains one or more <host> elements. The source can be given either as an IP address, a host name, or a netmask given in CIDR format (e.g. "10.0.0.0/16" for all clients coming from the 10.0 network).

Commands

The <commands> section specifies the Jolokia commands for which access is granted. If the <commands> section is not specified, access to all commands is allowed. For each command in the list, access to MBeans can be further restricted using the <deny> section and each command missing in the list, can be selectively enabled for MBeans using the <allow> section.

Allow and Deny access to certain MBeans

Within an <allow> section, access to MBeans can be granted regardless of the operations specified in the <commands> section. The reverse is true for the <deny> section.

Access can be restricted based on the HTTP method used to send the request to Jolokia with the <http> element. Method allowed (post or get) are specified with the inner element <method>. If the <http> section is not specified, any HTTP method can be used.

The following example defines a file named jolokia-polcy.xml file in the folder $FUSE_HOMEHOME/etc, which applies the following policy: 

  • Access is only allowed for clients coming from localhost
  • Only HTTP Post requests are allowed
  • Only read, list, search and version commands are allowed (not allowed to execute MBean operations)
  • The <allow> section permits exec requests on the MBean operations for:
    • All operations on java.lang:Threading MBean
    • All operations on java.lang:MemoryPool and its child MBeans
    • The gc operation on java.lang:Memory MBean
    • The dumpHeap and getJVMOption operations on com.sun.management:HotSpotDiagnostic MBean
    • All operations on org.apache.activemq:Broker and its child MBeans
<?xml version="1.0" encoding="UTF-8"?>
<restrict>
	<remote>
		<host>127.0.0.1</host>
	</remote>

	<commands>
		<command>read</command>
		<command>list</command>
		<command>search</command>
		<command>version</command>
	</commands>

	<http>
		<method>post</method>
	</http>

	<allow>
		<mbean>
			<name>java.lang:type=Threading</name>
			<operation>*</operation>
		</mbean>
		<mbean>
			<name>java.lang:type=MemoryPool,*</name>
			<operation>*</operation>
		</mbean>
		<mbean>
			<name>java.lang:type=Memory</name>
			<operation>gc</operation>
		</mbean>

		<mbean>
			<name>com.sun.management:type=HotSpotDiagnostic</name>
			<operation>dumpHeap</operation>
		</mbean>

		<mbean>
			<name>com.sun.management:type=HotSpotDiagnostic</name>
			<operation>getVMOption</operation>
		</mbean>
		<mbean>
			<name>com.sun.management:type=DiagnosticCommand</name>
			<operation>*</operation>
		</mbean>

		<mbean>
			<name>org.apache.activemq:type=Broker,*</name>
			<operation>*</operation>
		</mbean>
	</allow>
</restrict>

To add this Jolokia Security Policy to JBoss Fuse, add the following system property to the file $FUSE_HOMEHOME/etc/org.jolokia.osgi.cfg - which specifies the location of the XML security policy file.

New Line 
org.jolokia.authMode = jaas
org.jolokia.realm = karaf
org.jolokia.user = karaf
org.jolokia.policyLocation = file:etc/jolokia-policy.xml

With this configuration I have demonstrated the basic techniques to secure the Jolokia REST API, restricting access at three different levels:

  • Network level - restricting access to clients from specific IP Address/Hostnames
  • Command level - restricting access to read, write, execute
  • At an MBean level

This allows system admins to easily secure JBoss Fuse environments rolled out into production. environments.