Re: [Openstack] Network setup - Swift / keystone location and configuraton?
Exactly 從我的 iPhone 傳送 Brian Ipsen 於 2013/1/21 下午4:55 寫道： > Hi, > > Just to clear things up: > > 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) > > So the client contacts the keystone server first(directly) - on the URL it is > listening on (NAT'ed from public network)? Keystone returns tokenand service > URL - and then the client connects to the proxy using the token ? > > 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
Re: [Openstack] Network setup - Swift / keystone location and configuraton?
Hi, Just to clear things up: 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 :) [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) So the client contacts the keystone server first(directly) - on the URL it is listening on (NAT'ed from public network)? Keystone returns tokenand service URL - and then the client connects to the proxy using the token ? 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
Re: [Openstack] Network setup - Swift / keystone location and configuraton?
Thanks for Chmouel's mention , much flexible with swift-client Brain , please have a look with following reply 2013/1/19 Brian Ipsen > 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
Re: [Openstack] Network setup - Swift / keystone location and configuraton?
On Sat, Jan 19, 2013 at 9:57 AM, Kuo Hugo wrote: > The swift-client is using --publicurl as I know . FYI: You can change that behavior with the --os-endpoint-type switch Chmouel. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Network setup - Swift / keystone location and configuraton?
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: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<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 mailto: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 -
Re: [Openstack] Network setup - Swift / keystone location and configuraton?
Would you mind to have a network diagram of your environment ? Hugo 2013/1/19 Brian Ipsen > 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 + 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
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 > 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 + 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
[Openstack] Network setup - Swift / keystone location and configuraton?
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
