Open Stack

I think Jose from CERN has been putting in some work on the clients and the server for Kerberos in this area.

There were some problems with the Kerberos packaging and pre-reqs along with how to fake a Kerberos server in the test suite but he was making progress.

Is this on the summit agenda ? It would be good to get it working since I think it was on my summit talk in Boston.

Tim

Activity Log
[http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
08 Apr 2014 07:14:32 in python-keystoneclient<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>
Review “Initial kerberos plugin implementation.”
Submitted by: Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>) (#35)
Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
Code Review: 1
[http://www.gravatar.com/avatar/a1040384?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
02 Apr 2014 14:59:32 in requirements<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=requirements>
Review “kerberos requires an additional requests library. Older versions break in py33”
Submitted by: Adam Young<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&metric=all&company=> (Red Hat<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=Red+Hat>) (#200)
Change Id: I2100915f123c0fea41d5b17d01947901aa0119c5<https://review.openstack.org/84740>
Code Review: 1
[http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
20 Feb 2014 09:21:31 in python-keystoneclient<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=python-keystoneclient>
Patch “Initial kerberos plugin implementation.”
Current Status: ABANDONED
Change Id: Idf02bf27b5933c00827dd08d11ac131896184ad8<https://review.openstack.org/74974>
[http://www.gravatar.com/avatar/a1657571576?s=64&d=identicon]
Jose Castro Leon<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&release=all&metric=all&company=> (CERN<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=CERN>)
18 Feb 2014 10:19:23 in keystone<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=all&company=&module=keystone>
Patch “Initial kerberos plugin implementation.”
Current Status: ABANDONED
Change Id: I2fad67c3613c273187f6ca32985d360352c81bf8<https://review.openstack.org/74317>



From: Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com]
Sent: 23 April 2014 14:42
To: Adam Young
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Credentials in clear text


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<mailto: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<mailto: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]
Sent: 22 April 2014 01:16
To: Adam Lawson
Cc: openstack-security at lists.openstack.org<mailto: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<mailto: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<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

On Mon, Apr 21, 2014 at 4:46 PM, Adam Lawson <alawson at aqorn.com<mailto: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<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

On Mon, Apr 21, 2014 at 4:41 PM, Bryan D. Payne <bdpayne at acm.org<mailto: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<mailto: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<tel:%2B1%20%28302%29%20268-6914>
[Image removed by sender. http://www.aqorn.com/images/logo.png]

_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security






_______________________________________________

Openstack-security mailing list

Openstack-security at lists.openstack.org<mailto:Openstack-security at lists.openstack.org>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security


_______________________________________________
Openstack-security mailing list
Openstack-security at lists.openstack.org<mailto: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/f2ca3a04/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: image003.jpg
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/f2ca3a04/attachment.jpg>