Re: [Openstack-operators] keystone authentication on public interface

[Van Leeuwen, Robert]

>
>Hello folks,
>
>I was wondering if you let me know if enabling keystone to listen on public 
>interface for ports 5000 and 35357 is considered as a normal practice. Example 
>if a customer wants to authenticate not via horizon or some other proxy but 
>setting up OS_AUTH_URL=http://blah  variable to be able to run OpenStack 
>commands in cli.

I think this depends a bit on your user base.
Personally I see horizon more of a getting-started thing for people who are not 
extremely technical and maybe want one or two instances which never change.

You really need the API’s if you want to automate deployments (e.g. Using 
Terraform).
If you have e.g. OPS teams using it they will probably want APIs

Depending on your user base (private/public cloud) you choose to expose the 
APIs on private/public IP space.
Since there are some pretty big OpenStack clouds facing the internet, eg 
backspace, I think the APIs are battle-tested.

Regarding how & ports:
I would terminate everything on port 443 (so people do not have to mess with 
firewalls) and offload SSL to a load-balancer.
You can do host-header inspection on the loadbalancer so e.g. 
keystone.example.com goes to your keystone server on port 5000 and 
keystone-admin.example.com goes to port 35357 (if you chose to expose it)

Cheers,
Robert van Leeuwen
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] keystone authentication on public interface

[Dan Sneddon]

On 04/13/2016 07:46 PM, Serguei Bezverkhi (sbezverk) wrote:
> Hello folks,
> 
> I was wondering if you let me know if enabling keystone to listen on public 
> interface for ports 5000 and 35357 is considered as a normal practice. 
> Example if a customer wants to authenticate not via horizon or some other 
> proxy but setting up OS_AUTH_URL=http://blah  variable to be able to run 
> OpenStack commands in cli.
> 
> Thank you in advance
> 
> Serguei  
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

That's a normal practice. I guess you might be surprised to learn that
we already host ports 5000 and 35357 on the Public API address? All
that is needed is to point to http://:5000/ (or HTTPS if
using SSL).

In general, you want to use port 5000 for all remote Keystone
connections, with the exception that if you want to use the API for
creating users or tenants you need to use the admin API. The only
difference between the two is that 35357 can perform admin functions on
the user database.

-- 
Dan Sneddon |  Principal OpenStack Engineer
dsned...@redhat.com |  redhat.com/openstack
650.254.4025|  dsneddon:irc   @dxs:twitter

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] keystone authentication on public interface

[Edgar Magana]

Serguei,

You should check with your security team. Normally, they will have a strong 
opinion on this configuration. In many cases, the public interfaces is the one 
enabled SSL and the internal one is not and indeed is a common practice.

Edgar




On 4/13/16, 7:46 PM, "Serguei Bezverkhi (sbezverk)"  wrote:

>Hello folks,
>
>I was wondering if you let me know if enabling keystone to listen on public 
>interface for ports 5000 and 35357 is considered as a normal practice. Example 
>if a customer wants to authenticate not via horizon or some other proxy but 
>setting up OS_AUTH_URL=http://blah  variable to be able to run OpenStack 
>commands in cli.
>
>Thank you in advance
>
>Serguei  
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators