Open Stack

We have to configure the Apache layer to set the component we want as the
REMOTE_USER, but other than that I believe that's pretty much all it takes
on the Keystone side. Changes were necessary to some of the Python clients
and service code, mainly to get them to pass certificates along.  Not all
these changes have been proposed upstream yet, although we plan to.

Thanks,

Nate
On Apr 23, 2014 8:33 AM, "Adam Young" <ayoung at redhat.com> wrote:

>  On 04/23/2014 08:29 AM, Nathanael Burton wrote:
>
> We do this today with X509 certificates using the external auth plugin for
> Keystone. Services and users auth directly with X509 certificates to get
> tokens.
>
>
> Have you modified it at all?  I have yet to try, but I though with mod_ssl
> and external, REMOTE_USER was not set.  It was my understanding that the
> following vars were set in its place:
>
> http://www.freeipa.org/page/Environment_Variables#X.509_Authentication
>
>  Nate
> On Apr 23, 2014 12:23 AM, "Adam Young" <ayoung at redhat.com> wrote:
>
>>  On 04/22/2014 11:29 AM, Clark, Robert Graham wrote:
>>
>>  As Bryan mentioned already, a user with access to production systems,
>> particularly one with sudo/root access – is in an incredibly privileged
>> position. On its own this is an auditing issue but it’s a recognised one.
>> In most deployments subject to auditing (i.e. production) it’s likely that
>> compensating controls such as gated access, user logging, MAC etc. are all
>> in place to control the risk.
>>
>>  It’s a messy problem to deal with. I’ve seen approaches where the
>> process and configuration file are both owned by an elevated user, once the
>> process has loaded the configuration file it drops privs and can no longer
>> read the file, this can be useful as a mechanism for avoiding directory
>> traversal in web services etc I’m not sure how viable an approach this
>> would be with something like Swift.
>>
>>
>>
>> -Rob
>>
>>
>> I'd like to see a concerted effort to allowing all servcie to get
>> keystone tokens with either Kerberos (keytabs) or X509 Client certificates.
>>
>>
>>
>> *From:* Bryan D. Payne [mailto:bdpayne at acm.org <bdpayne at acm.org>]
>> *Sent:* 22 April 2014 01:16
>> *To:* Adam Lawson
>> *Cc:* openstack-security at lists.openstack.org
>> *Subject:* Re: [Openstack-security] Credentials in clear text
>>
>>
>>
>> This is fair.  I'm not personally familiar with Swift, so I will let
>> others chime in on that.
>>
>> -bryan
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:47 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>  Preventing access to passwords for the purpose of preventing
>> unauthorized access to data as another way I look at it.
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>  My initial concern is specific to Swift and gaining global access to
>> all data by virtue of having access to a single proxy node. It seems more
>> than access to system resources but a flaw in how data is controlled (and
>> passwords are controlled).
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org> wrote:
>>
>>  This would be a nice hardening step, but if you have sudo on the box
>> there's a lot of things you can do see.  This is just the tip of the
>> iceberg.  For example, access to the backend db?  Access to traffic on the
>> network / unix sockets / etc?  Access to logs.
>>
>>
>>
>> I am not aware of any current efforts to mask this information from the
>> config files.  But that doesn't mean it's not happening.  If someone is
>> aware of such an effort, I'd certainly be interested in learning more about
>> it.
>>
>>
>>
>> Cheers,
>>
>> -bryan
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Apr 21, 2014 at 4:26 PM, Adam Lawson <alawson at aqorn.com> wrote:
>>
>>   Have .conf files containing credentials and tokens been addressed or
>> being addressed? Seems there are a lot of keys to the kingdom clearly
>> visible to staff who have access to systems for day-to-day admin work but
>> don't/shouldn't be able to view them. If they have sudo access, they have
>> everything they need to get where they don't belong. Really strikes me as
>> an obvious audit issue...
>>
>>
>>
>> * Adam Lawson*
>>
>> AQORN, Inc.
>>
>> 427 North Tatnall Street
>>
>> Ste. 58461
>>
>> Wilmington, Delaware 19801-2230
>>
>> Toll-free: (844) 4-AQORN-NOW
>>
>> Direct: +1 (302) 268-6914 <%2B1%20%28302%29%20268-6914>
>>
>> [image: http://www.aqorn.com/images/logo.png]
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing listOpenstack-security at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/650194b0/attachment.html>