Thanks for Chmouel's mention , much flexible with swift-client Brain , please have a look with following reply....
2013/1/19 Brian Ipsen <brian.ip...@ryesgade47c.dk> > 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. > [Reply] In your case , to put a NAT server front of swift ecosystem . The keystone could be located in private network without any problem . But in this scenario , there's some more work you have to do . 1) set NAT for keystone too , whatever a DNAT or redirect port in your firewall for keystone. Remember that , if you want to use username/password authentication method for swift . The easiest way is using keystone/tempauth . In these method , they provide token-auth mechanism to determine if the user is accessible currently. While you want to access swift , you must have a "TOKEN". And the "TOKEN" is managing by keystone . As default , the token will be expired in a period. 24hrs in my memory . The client user have to get the token from keystone first. > 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 J > [Reply] Yes , that's the keypoint. You must understand the workflow. My assumption is your proxy pipline is using tokenauth and keystone even swift-auth . The full request workflow is : client send username/password --> keystone verify it --> return token and service(swift) url to client --> client use returned url and token to swift-proxy --> proxy verify the token by asking keystone immediately ---> keystone confirmed it with several information includes role etc. --> the request pass the token-auth filter --> check the role with swift-auth middleware --> do the operation for user --> returned the result(status) **** > > ** ** > > 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. > [Reply] As the description in previous section , user authentication is done by keystone . And token authentication is done by proxy . If you want to send username/password to swift directly , yes you can , but need to write another middleware for it. And would be a little complicated. Keystone should be accessed by client & proxy in original design. > > **** > > ** ** > > 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). > [Reply] Anywhere could be possible > **** > > ** ** > > 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 J > Sure , also official documents . 1) play with it 2) IRC 3) mailing list > **** > > ** ** > > Regards**** > > Brian > Hope it helps Cheers Hugo Kuo > **** > > ** ** > > ** ** > > *From:* Kuo Hugo [mailto:tonyt...@gmail.com] > *Sent:* 19. januar 2013 09:58 > *To:* Brian Ipsen > *Cc:* openstack@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' --adminurl ' > http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s ' --internalurl ' > http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s '**** > > ** ** > > 2013/1/19 Brian Ipsen <brian.ip...@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' --adminurl ' > http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s ' --internalurl ' > http://x.x.x.x:8080/v1/AUTH_\$(tenant_id)s '**** > > **** > > Regards**** > > Brian**** > > **** > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp**** > > > > **** > > ** ** > > -- **** > > +Hugo Kuo+**** > > tonyt...@gmail.com > **** > > + <tonyt...@gmail.com>886 935004793**** > -- +Hugo Kuo+ tonyt...@gmail.com + <tonyt...@gmail.com>886 935004793
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
