[Openstack] Network setup - Swift / keystone location and configuraton?

Brian Ipsen brian.ipsen at ryesgade47c.dk
Sat Jan 19 11:40:16 UTC 2013


Hi

As for the network diagram the one on the referred page (http://docs.openstack.org/trunk/openstack-object-storage/admin/content/figures/swift_install_arch.png) more or less looks what I plan on doing. I would just put a NAT'ing firewall between the public switch and the internet. For security reasons, I think it would make more sense to have the Auth node (keystone service) located on the private switch - but I am not sure whether it is possible.

I am still trying to figure out how the different components interact, and exactly what the different parameters on the keystone command does. Once I get that understanding, things will probably be much easier :)

Regarding the location of the keystone server - and please correct me, if I'm wrong; user authentication is done via the proxy. When a user authenticates, I assume that the proxy asks the keystone/auth server - instead of the client asks the auth/keystone server directly? If it is the proxy that handles the authentication request towards the keystone server - then the keystone might as well be located on the private switch on the drawing (for enhanced security). Of course, if the keystone service is located on the private switch, the IP addresses in the URL's for the endpoint creation will need to match the IP address of the server in this network.

Clients will be located on the internet side on the drawing (again - I want to put a NAT'ing firewall between the public switch and what is referred to as "internet" on the drawing).

Maybe I should start digging into the book "OpenStack Cloud Computing Cookbook" by Kevin Jackson to see if this can make things clearer for me :)

Regards
Brian


From: Kuo Hugo [mailto:tonytkdk at gmail.com]
Sent: 19. januar 2013 09:58
To: Brian Ipsen
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] Network setup - Swift / keystone location and configuraton?

The answer is depends on your service plan .

Generally , the IP for keystone is the network which could be accessed from client .
Also , the publicurl / adminurl / internal could be different .

Keystone is the auth agent for swift(and all other services) , while you produce a request to ask for "services URLs / role / token" with your username/password . It will return a bunch of of information .
In keystone v1.0 legacy auth method , it presents as several x-headers .
In keystone v2.0 , it returns a pack of json which includes more information . Such as service urls , in your case the service type is object-storage(aka. swift) .

The client could parse the needed url for using.
The swift-client is using --publicurl as I know .

[Q]Could I have a question ?
Which network will the client located ?

For x.x.x.x , you can just fill in the IP which accessible from client . If there's a NAT of LB , you need to point to NAT entry point of LB IP and redirect to the service port or internal IP .

keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID --publicurl 'http://x.x.x.x5000/v2.0' --adminurl 'http://x.x.x.x:35357/v2.0' --internalurl 'http://x.x.x.x:5000/v2.0'
keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl 'http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s>' --adminurl 'http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s> ' --internalurl ' http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s> '

2013/1/19 Brian Ipsen <brian.ipsen at ryesgade47c.dk<mailto:brian.ipsen at ryesgade47c.dk>>
Hi

I am trying to figure out how to build a swift setup with Keystone identity management - and have the environment secured by a firewall.

I expect, that a number of proxy nodes are accessible through the firewall (traffic will be NAT'ed). The proxy nodes are connected to a private "storage network" (not accessible from the outside) on a second network interface. Will the keystone have to be on the "public" side of the proxy nodes - or can it be on the "private" side (see http://docs.openstack.org/trunk/openstack-object-storage/admin/content/example-object-storage-installation-architecture.html - here it is on the "public" side)

But I am not quite sure about the configuration of the different service when it comes to specifying the different URL's...
For example, for the Keystone service:

Assuming, that storage/swift nodes are located in the range 172.21.100.20-172.21.100.80, the keystone server on 172.21.100.10 - and the proxies on 172.21.100.100-172.21.100.120 (and external 10.32.30.10-10.32.30.30). What would be the correct IP's to use on this command ?
keystone service-create --name keystone --type=identity --description "Keystone Identity Service"
keystone endpoint-create --region RegionOne --service-id $KEYSVC_ID --publicurl 'http://x.x.x.x5000/v2.0' --adminurl 'http://x.x.x.x:35357/v2.0' --internalurl 'http://x.x.x.x:5000/v2.0'

And for swift:
keystone service-create --name keystone --type=identity --description "Swift Storage Service"
keystone endpoint-create --service-id $SWIFTSVC_ID --publicurl 'http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s>' --adminurl ' http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s> ' --internalurl ' http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s<http://x.x.x.x:8080/v1/AUTH_%5C$(tenant_id)s> '

Regards
Brian


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



--
+Hugo Kuo+
tonytkdk at gmail.com
<mailto:tonytkdk at gmail.com>
+<mailto:tonytkdk at gmail.com>886 935004793
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20130119/3f0c2c2a/attachment.html>


More information about the Openstack mailing list