openstack team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

Justin Santa Barbara wrote:
> Here's an overview of the problem:
> 
> EC2 uses an (api_key, api_secret) pair.  Post-revert, OpenStack uses the
> api_key(!) as the password, but a different value entirely as the
> username: (username, api_key).  The bugfix made it so that both APIs
> used the EC2 credentials (api_key, api_secret) .  This did mean that
> anyone that had saved the 'bad' OpenStack credentials was unable to
> continue to use those credentials.  I also overlooked exporting the
> updated credentials in novarc (though a merge request was pending).
> 
> [...]
> As things stand now, post-revert, this is probably a security flaw,
> because the EC2 API does not treat the api_key as a secret.  The EC2 API
> can (relatively) safely be run over non-SSL, because it uses signatures
> instead of passing the shared secret directly.

That's two different issues. (1) is a consistency vs. ease-of-use issue
(you want both APIs to use the same set of credentials, even if that
means changing from a human-memorable username to a complex api_key).
(2) is a security issue: using the non-secret api_key as the secret
component in OpenStack API.

As far as (1) is concerned, it's a trade-off where there is no obvious
right and wrong solution, so it needs to be openly discussed.

For (2) I think we *need* to move to using something secret rather than
api_key as the "password" in OpenStack API. That's a security issue.

I like how Dragon presented the options on the whiteboard at:
https://blueprints.launchpad.net/nova/+spec/authentication-consistency

In all cases, changes that will break existing systems, even if they are
badly wanted, should systematically raise a preventive thread on the ML
so that people know it will break (and how to fix it) and others can
propose alternative solutions.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack