Bug 1041560

Description of problem:

Packstack installs iptables rules for several API services with the source address set to "anywhere" (i.e. nova-api, horizon, ceilometer-api, swift-proxy).

These rules appear to allow those services to be callable from anywhere.

But in order for clients to actually interact with any of those services, they would have to go to keystone first to get a token.

And therein lies the problem ... the iptables rule installed for keystone is source-constrained to just the allinone host (or to the compute nodes, if additional nodes are added, IIUC).

Hence the firewall rules for the API services are confusingly "half open". They appear to allow those service be invoked from outside the controller host, as the service ports are open to traffic originating from anywhere. But since the keystone port is not open to the same extent, in practical terms the iptables rules for the API services do not have the effect intended/implied. 

So external clients can only invoke on the API services if they already have a cached token, but not otherwise, and the failure mode isn't obvious to someone new to openstack.


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

openstack-packstack-2013.2.1-0.18.dev934.el6ost


How reproducible:

100%


Steps to Reproduce:

1. Install packstack --allinone in the usual way

2. Install the CLI for any on the services mentioned above (nova, ceilometer, swift) onto another host

3. Source the keystonerc_admin generated by packstack on the second host

4. Attempt a basic CLI command:

   $ nova --debug flavor-list
   $ ceilometer --debug meter-list

   ... etc


Actual results:

The CLI invocation on the "open" service fails, e.g:

  $ nova flavor-list
  ERROR: [Errno 113] No route to host
  $ ceilometer meter-list
  Authorization Failed: Unable to establish connection to http://192.168.122.130:35357/v2.0/tokens


Expected results:

The CLI invocation on the "open" service should succeed.


Additional info:

N/A