Bug 1040404 - ceilometer-api iptables rule constrains the source address to the host on which the service is running
Summary: ceilometer-api iptables rule constrains the source address to the host on whi...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: 4.0
Assignee: Martin Magr
QA Contact: Lon Hohberger
URL:
Whiteboard:
Depends On:
Blocks: 1040610
TreeView+ depends on / blocked
 
Reported: 2013-12-11 11:23 UTC by Eoghan Glynn
Modified: 2016-04-26 16:12 UTC (History)
9 users (show)

Fixed In Version: openstack-packstack-2013.2.1-0.17.dev930.el6ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1040610 (view as bug list)
Environment:
Last Closed: 2013-12-20 00:44:08 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 61395 0 None None None Never
Red Hat Product Errata RHEA-2013:1859 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2013-12-21 00:01:48 UTC

Description Eoghan Glynn 2013-12-11 11:23:48 UTC
Description of problem:

The firewall rule installed by packstack for the ceilometer-api service seems to constrain the incoming connections to those originating on the *same* host as the service runs on, e.g.

ACCEPT     tcp  --  192.168.122.158      anywhere            multiport dports 8777 /* 001 ceilometer-api incoming 192.168.122.158 */

when packstack --allinone is run on 192.168.122.158.

The result is that attempts to access the ceilometer API from outside the host on which it was installed fail with EHOSTUNREACH (No route to host).

Whereas the ceilometer-api service needs to be accessible from outside that single host, so that clients running elsewhere can access metering data.

A specific usecase would be partitioned alarm evaluation, where evaluators are deployed to multiple hosts and need to all access the ceilometer-api service in order to retrieve aggregated statistics.

By contrast, note the source address is unconstrained for the nova-api rule:

  ACCEPT     tcp  --  anywhere             anywhere            multiport dports 8773,8774,8775 /* 001 novaapi incoming */


Version-Release number of selected component (if applicable):

openstack-packstack-2013.2.1-0.13.dev876.el6ost


How reproducible:

100%


Steps to Reproduce:
1. Run a packstack --allinone in the usual way with --os-ceilometer-install=y

2. Check the installed ipstables rules:

   sudo iptables -L | gre[ ceilometer

3. Add an additional compute node and try invoking the python-ceilometer CLI from there (fails with host unreachable):

   http://openstack.redhat.com/Adding_a_compute_node
   ceilometer meter-list

4. Note that the same host is accessible from the compute node via the nova-api:

   nova flavor-list 


Actual results:

Attempts to access the ceilometer-api service from outside the host on which it's installed fail with EHOSTUNREACH (No route to host).


Expected results:

The ceilometer-api service should be accessible from outside the host on which it's installed.


Additional info:

N/A

Comment 1 Eoghan Glynn 2013-12-11 11:25:42 UTC
A suggested fix is:

  s/config['FIREWALL_ALLOWED'] = "'%s'" % hosts/
    config['FIREWALL_ALLOWED'] = "anywhere"/

... in https://github.com/stackforge/packstack/blob/master/packstack/plugins/ceilometer_800.py#L98

However I'll defer to the domain experts as to whether this makes sense as the best may to create an "anywhere"-source iptables rule in packstack.

Comment 2 Martin Magr 2013-12-11 11:32:57 UTC
Yup, IMHO we should have all API services publicly accessible.

Comment 4 Lon Hohberger 2013-12-11 21:29:29 UTC
[root@localhost ~]# iptables -L | grep 8777
ACCEPT     tcp  --  anywhere             anywhere            multiport dports 8777 /* 001 ceilometer-api incoming ALL */ 
[root@localhost ~]# rpm -q openstack-packstack
openstack-packstack-2013.2.1-0.18.dev934.el6ost.noarch

Comment 7 errata-xmlrpc 2013-12-20 00:44:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2013-1859.html


Note You need to log in before you can comment on or make changes to this bug.