openstack team mailing list archive

[Kuo Hugo <tonytkdk@xxxxxxxxx>]

Thanks for Chmouel's mention  , much flexible with swift-client

Brain  , please have a look with following reply....

2013/1/19 Brian Ipsen <brian.ipsen@xxxxxxxxxxxxxx>

>  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:tonytkdk@xxxxxxxxx]
> *Sent:* 19. januar 2013 09:58
> *To:* Brian Ipsen
> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx
> *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.ipsen@xxxxxxxxxxxxxx>****
>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> +Hugo Kuo+****
>
> tonytkdk@xxxxxxxxx
> ****
>
> + <tonytkdk@xxxxxxxxx>886 935004793****
>



-- 
+Hugo Kuo+
tonytkdk@xxxxxxxxx
+ <tonytkdk@xxxxxxxxx>886 935004793