[openstack-dev] [Sahara] Questions about how Sahara use trust ?

Li, Chen chen.li at intel.com
Tue Jul 14 01:40:34 UTC 2015


Hi mike,

Thanks, this is very helpful.

Summary:

1. The purpose of admin user & proxy user are the same =>  to work without user's own username & password.
2. For transient cluster, what sahara need is to be able to operate.
3. For swift access , using user's own credentials is not safe.  Because the credentials  is not used by sahara only, it will appear in "user space" (on the cluster nodes) at end. 
    Using admin user is silly, doesn't gain any benefit, but create a more huge risk.

=>  proxy user must(better to) use proxy user, for security reason.
=>  transient cluster can work both way, but proxy user introduce extra effect which is not nessary, so admin user is enough.


Thanks.
-chen


-----Original Message-----
From: michael mccune [mailto:msm at redhat.com] 
Sent: Tuesday, July 14, 2015 5:25 AM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ?

On 07/12/2015 09:45 PM, Li, Chen wrote:
> Hi Andrew,
>
> Thanks for the reply.
>
> Are you mean :
>
> 1.       admin user is used by transient cluster is mainly to make it work.
>
> 2.       The proxy user is the more secure  way to do the same thing.
>
> Should we use proxy user at all situation then ? Should this be a bp or just a bug ?
>
>
> Thanks.
> -chen

hi chen,

i think the trusts for the transient clusters serve a different purpose than those for the swift access.

in the case of the swift proxy users, this is a security enhancement for us because in order for hadoop jobs to access swift they must use a set of credentials that are written to the workflow properties for the job.

for example, for hadoop-swift.jar to access swift it must have values for:

fs.swift.service.sahara.username
and
fs.swift.service.sahara.password

we wanted to avoid having the user enter their name and password into the data source dialog, storing those values in our database, and then having those values written out to a file on the nodes. to get around this, we created the proxy user whose permissions are limited to the trust and their accounts will expire when the job is finished. in this manner, we limit the vulnerable information that is stored on the nodes.

i hope that makes sense, but please ask more if it does not =)

mike

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



More information about the OpenStack-dev mailing list