Open Stack

On 05/21/2014 01:49 PM, Mathieu Gagné wrote:
> Hi operators,
>
> (welcome back from the OpenStack Summit for those I had the chance to 
> meet)
>
> The OpenStack Security Guide includes some guidelines on how to harden 
> the security of administrative users.
>
> OpenStack Security Guide (May 21, 2014) on page 81:
>
>> Administrative users
>>
>> We recommend that admin users authenticate using Identity Service and
>> an external authentication service that supports 2-factor 
>> authentication,
>> such as a certificate. This reduces the risk from passwords that may be
>> compromised. This recommendation is in compliance with NIST 800-53
>> IA-2(1) guidance in the use of multi factor authentication for network
>> access to privileged accounts.
>
> Can someone provide a reference or documentation on how to accomplish 
> such hardening?
>
> My concern is that such hardening would:
>
> - Force ALL users to provide a client certificate if this config is in 
> keystone.conf:
No.  I think that there is no way to say "user cannot authenticate with 
Password"  but you could do  X509 Client cert authentication via mod_nss 
or mod_ssl, and map that users ID to REMOTE_USER, and use the external 
login. They would have a separate Auth URL,

Note that this kindof implies HTTPD.  It might be possible to do this in 
Eventlet, but Python is really poor at doing cryptography, and adding a 
single threaded web server to the mix is probably going to perform poorly.


I'd love it if Admin users could use X509 and/orKerberos across the 
board, but there is not yet support for Kerberos in the clients. That is 
changing soon, though.

>
>   [token]
>   enforce_token_bind = required  # or x509
Token bind is something different, not for this.
>
> - Not prevent an administrative user to come up without a valid client 
> certificate if this config is in keystone.conf:
>
>   [token]
>   enforce_token_bind = permissive
>
>
> Or is the actual implementation of the recommendation left as an 
> exercise to the reader? In that case, as an operator, although those 
> recommendations are good to know, they are near impossible to 
> implement without the help of a knowledgeable developer.
>
> On the other hand, what are you guys doing to protect your 
> administrative and service users from being compromised through the 
> public API?
>