[Openstack-security] Credentials in clear text
Clark, Robert Graham
robert.clark at hp.com
Wed Apr 23 17:06:58 UTC 2014
So in this example you'd require manual intervention to provide the
encryption key. (I believe 'read' takes data from the CLI).
That's not going to work for anyone running OpenStack at any sort of
scale. Of course if systems had valid ways to authenticate with Keystone
they could query Barbican for key material, once Barbican is a little
more mature. Then maybe you could look at encrypted configuration files
a little more realistically.
-Rob
From: Adam Lawson [mailto:alawson at aqorn.com]
Sent: 23 April 2014 17:49
To: Tim Bell
Cc: openstack-security at lists.openstack.org
Subject: Re: [Openstack-security] Credentials in clear text
How feasible (or unfeasible) would it be for each service to look for an
encrypted conf file and use the clear text version if the encrypted file
doesn't exist? The file could be all settings but technically only
credentials and tokens would need this level of protection in my
estimation.
I could envision doing this, for example, with OpenSSL as follows (bash
for example):
#!/bin/bash
#OpenSSL file encryption
decrypt=credentials.txt
encrypt=${decrypt}.encrypted
if [[ $# -eq 0 ]] ; then #encrypt creds in file
read username
read -s password
#write creds to the file
echo ${username}:${password} | openssl des3 -salt -out
$encrypt
elif [[ $1 = '-d' ]] ; then #decrypt creds from file
openssl des3 -d -salt -in $encrypt -out $decrypt
else
echo "Error: $1 invalid. Decrypt='-d', Encrypt=no-args" >&2
exit 1
fi
Thoughts? It just seems (to me of course) like a meaningful design
option for companies who cannot afford to give credentials to all
sysadmins with sudo access to *any* of the nodes for a given solution.
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
<http://www.aqorn.com/images/logo.png>
On Wed, Apr 23, 2014 at 7:24 AM, Tim Bell <Tim.Bell at cern.ch
<mailto:Tim.Bell at cern.ch> > wrote:
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://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)
08 Apr 2014 07:14:32 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=python-keystoneclient> python-keystoneclient
Review "Initial kerberos plugin implementation."
Submitted by:
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN) (#35)
Change Id: <https://review.openstack.org/74974>
Idf02bf27b5933c00827dd08d11ac131896184ad8
Code Review: 1
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)
02 Apr 2014 14:59:32 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=requirements> requirements
Review "kerberos requires an additional requests library. Older versions
break in py33"
Submitted by:
<http://stackalytics.com/?user_id=ayoung&project_type=all&release=all&me
tric=all&company=> Adam Young (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=Red+Hat> Red Hat) (#200)
Change Id: <https://review.openstack.org/84740>
I2100915f123c0fea41d5b17d01947901aa0119c5
Code Review: 1
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)
20 Feb 2014 09:21:31 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=python-keystoneclient> python-keystoneclient
Patch "Initial kerberos plugin implementation."
Current Status: ABANDONED
Change Id: <https://review.openstack.org/74974>
Idf02bf27b5933c00827dd08d11ac131896184ad8
<http://stackalytics.com/?user_id=jose-castro-leon&project_type=all&rele
ase=all&metric=all&company=> Jose Castro Leon (
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=CERN> CERN)
18 Feb 2014 10:19:23 in
<http://stackalytics.com/?user_id=&project_type=all&release=all&metric=a
ll&company=&module=keystone> keystone
Patch "Initial kerberos plugin implementation."
Current Status: ABANDONED
Change Id: <https://review.openstack.org/74317>
I2fad67c3613c273187f6ca32985d360352c81bf8
From: Nathanael Burton [mailto:nathanael.i.burton.work at gmail.com
<mailto:nathanael.i.burton.work at gmail.com> ]
Sent: 23 April 2014 14:42
To: Adam Young
Cc: openstack-security at lists.openstack.org
<mailto: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: <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914
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: <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914
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: <tel:%2B1%20%28302%29%20268-6914> +1 (302) 268-6914
_______________________________________________
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
_______________________________________________
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/46a572bd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4333 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 1686 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 410 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6187 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140423/46a572bd/attachment.bin>
More information about the Openstack-security
mailing list
