Thanks. This is very helpful.

A little more questions about how to config:

1.  What should be set in [keystone_authtoken] in sahara.conf ?
      As code at 
https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L165.
      Looks like admin_user & admin_password & admin_tenant_name" must be set, 
and the proxy_domin must be created by the admin_user.
      But after a clean devstack installation, my sahara.conf only has:
                [keystone_authtoken]
                signing_dir = /var/cache/sahara
                cafile = /opt/stack/data/ca-bundle.pem
                auth_uri = http://192.168.6.91:5000
                project_domain_id = default
                project_name = service
                user_domain_id = default
                password = 123456
                username = sahara
                auth_url = http://192.168.6.91:35357
                auth_plugin = password

      I'm really confused, these configurations all looks very similar.

2. More other configurations must be set ?
    Such as: 
                [DEFAULT]
               use_identity_api_v3= True


Thanks.
-chen


-----Original Message-----
From: michael mccune [mailto:m...@redhat.com] 
Sent: Friday, June 26, 2015 8:55 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Sahara] Why Sahara request user to give 
username/password for accessing the job binary in Swift ?

On 06/25/2015 09:54 PM, Li, Chen wrote:
> Thanks for the reply.
>
> My puzzle here is :
>       I create containers & objects by my own, why other users can access 
> them ?
>
> As mentioned in your article[1], the domain " sahara_proxy" is created by 
> user "admin" in project "openstack".
> But I'm working under user "demo" in project "demo", and other people are in 
> other project with other users.

those are good questions Chen.

to address your puzzle, if you create containers/objects in your own project 
then others cannot access them without your credentials. but keep in mind that 
any user in your project can also view those objects.

there are 2 main reasons we created the proxy domain feature

1. increase security. by using proxy domains, sahara is not responsible for 
storing a user's credentials in its database, or distributing them to the nodes 
of the cluster.

2. convenience. when creating several job binaries and data sources you will 
need to enter credentials for each one. this is not necessary with the proxy 
domain usage.


with that being said, it may not be a feature that fits well with your usage 
pattern.

as to the question about "admin" project versus "demo" project, the domain is 
an extra layer of scoping that can be applied to tokens. it does not map 1:1 
with projects as it is at a different layer than the project scoping. so, it is 
possible to have users from different domains accessing the same project, in 
this case by using trusts.

on the security issue, using proxy users also helps to create another layer of 
separation in the event that an intruder were able to gain the credentials 
stored in sahara or on the cluster nodes.

for example, if not using proxy domains, a user will store their credentials in 
sahara's database to access their objects. if an intruder learns this 
information they will have access to everything that the user does. but, if 
using proxy domains then the only credentials to be gained are those of the 
proxy user which has its permissions limited by the trust. additionally the 
trust will be removed when the job is complete.

i hope this clears things up =)

regards,
mike

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to