nova passes incorrect authentication info to cinderclient
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
Unassigned | ||
python-cinderclient |
Invalid
|
Undecided
|
Unassigned |
Bug Description
There are multiple problems with the authentication information that nova/volume/cinder code passes to cinderclient:
1. nova/volume/
get_cinder_
c = cinder_
c.client.auth_token = context.auth_token or '%s:%s' % (context.user_id,
Under normal circumstances ( i e in cases where the context has auth_token) , the auth_url is never used/required. So this is required only when the token expires and an attempt to do fresh authentication is made here:
def _cs_request(self, url, method, **kwargs):
attempts = 0
backoff = 1
while True:
if not self.management_url or not self.auth_token:
if self.projectid:
try:
except exceptions.
if attempts > self.retries:
except exceptions.
if auth_attempts > 0:
# First reauth. Discount this attempt.
2. nova/volume.
3. There are other problems around this which is summarized as below:
cinderclient should really support a way of passing an auth_token in on the __init__ so it is explicitly supported for the caller to specify an auth_token, rather than forcing this hack that nova is currently using of setting the auth_token itself after creating the cinderclient instance. That's not strictly required, but it would be a much better design. At that point, cinderclient should also stop requiring the auth_url parameter (it currently raises an exception if that isn't specified) if an auth_token is specified and retries==0, since in that case the auth_url would never be used. Userid and password would also not be required in that case.
nova needs to either start passing a valid userid and password and a valid auth_url so that retries will work, or stop setting retries to a non-zero number (it's using a conf setting to determine the number of retries, and the default is 3). If the decision is to get retries working, then we have to figure out what to pass for the userid and password. Nova won't know the end-user's user/password that correspond to the auth_token it initially uses, and we wouldn't want to be using a different user on retries than we do on the initial requests, so I don't think retries should be supported unless nova is going to make ALL requests with a service userid rather than with the end-user's userid... and I don't think that fits with the current OpenStack architecture. So that leaves us with not supporting retries. In that case, nova should still stop passing the auth_token in as the password so that someone doesn't stumble over that later when retry support is added. Similarly for the auth_url it should start passing the correct keystone auth_url, or at least make it clear that it's passing an invalid auth_url so someone doesn't stumble over that when trying to add retry support later. And it definitely needs to stop setting retries to a non-zero number.
Changed in nova: | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | added: volumes |
Changed in python-cinderclient: | |
status: | New → Incomplete |
Changed in nova: | |
status: | Confirmed → Fix Committed |
Changed in nova: | |
milestone: | none → kilo-rc1 |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | kilo-rc1 → 2015.1.0 |
This looks to be using the user's token meaning a couple things: Nova could never pass a username/password to cinderclient, and refreshing the token is not working since you don't have a username/password [today].
There are a couple approaches to fix this (no particular order):
1) as outlined, don't set retries
2) Keystone team needs to evaluate allowing a "refresh" of a token with a longer expires in some cases (this however has a lot of security implications, and is unlikely to go through).
3) (as discussed at the summit), when policy.py is graduated (in process) to it's own library we can add the ability to the rules engine to accept expired tokens (explicitly configured) for some calls (this also requires some changes to auth token middleware). This would need to also be reviewed by the security teams, but some cases it would be ok (checking status of things) be allowed to use an expired token. Some mechanics on this approach likely need to still be worked out.
4) Migrate this call to use a service user nova actually controls.
The short answer is that as of today, the only easy option is to not retry, since the user's token isn't guaranteed to be valid the entire time and we can't refresh it.