OpenStack SDK

get_secret and delete_secret in key_manager always fail with 404

Bug #1628957 reported by Douglas Mendizábal on 2016-09-29

6

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	OpenStack SDK	New	Undecided	Douglas Mendizábal

Bug Description

The key_manager methods to retrieve a secret, and to delete a secret always fail with 404 for existing secrets. Consider the following sample code:

from openstack import profile
from openstack import connection

prof = profile.Profile()
prof.set_region('key-manager', 'IAD')

    conn = connection.Connection(auth_url='https://identity.api.rackspacecloud.com/v2.0',
                                 username='my_username',
                                 password='PA$$W0rD',
                                 profile=prof)

    my_secret = conn.key_manager.create_secret(secret_type='passphrase',
                                              payload='foobar',
                                              payload_content_type='text/plain')

# my_secret has been successfully created in the service at this point

retrieved_secret = conn.key_manager.get_secret(my_secret) # raises ResourceNotFound

conn.key_manager.delete_secret(my_secret, ignore_missing=True) # also raises ResourceNotFound

The expected behavior is that get_secret and delete_secret should succeed since the secret is successfully created with create_secret.

Douglas Mendizábal (dougmendizabal) on 2016-09-29

Changed in python-openstacksdk:
assignee:	nobody → Douglas Mendizábal (dougmendizabal)

Revision history for this message

Douglas Mendizábal (dougmendizabal) wrote on 2016-09-29:

#1

I dug around the source tree for a bit, and these failures are due to an error when preparing the URL used in the GET /v1/secrets/UUID and DELETE /v1/secrets/UUID requests. Since Barbican objects don't have an 'id' property, the current implementation uses a workaround that sets a new 'secret_id' property on the Secret class that is set to be an alternate_id.

However, there is a subtle detail in the logic that uses alternate_id properties that makes the 'secret_id' property not work as intended. This results in the prepared URLs being set to /v1/secrets/SECRET_REF_URL which results in a 404.

Revision history for this message

Brian Curtin (brian.curtin) wrote on 2016-09-29:

#2

Yeah this is something I was looking around with before but hadn't finished it. Barbican mostly needs its own Resource subclass due to how differently it works.

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2016-09-29: Related fix proposed to python-openstacksdk (master)

#3

Related fix proposed to branch: master
Review: https://review.openstack.org/379594

Revision history for this message

Douglas Mendizábal (dougmendizabal) wrote on 2016-09-29:

#4

Brian,

I wrote a unit test for _alternate_id() that shows the issue that is causing this bug. [1] The current implementation of key_manager.v1.secret.Secret assumes this unit test would pass, but I'm not sure if that's how alternate ids are supposed to work because of the comment on the 'secret_id' property. [2]

[1] https://review.openstack.org/#/c/379594
[2] http://git.openstack.org/cgit/openstack/deb-python-openstacksdk/tree/openstack/key_manager/v1/secret.py#n58

Revision history for this message

Brian Curtin (brian.curtin) wrote on 2016-09-29:

#5

Yeah we need a bunch of work here, and I'll probably get to it after what I'm wrapping up now. That secret_ref not being an actual ID ruins everything so the temporary fix is probably not right. I don't really care to work on it as-is though, since we probably need to implement something that intercepts the setting/getting of an id-related attribute to convert it from a URI into just an ID so that we can use it when constructing other calls.

Revision history for this message

Douglas Mendizábal (dougmendizabal) wrote on 2016-09-29:

#6

Brian, I understand you have other priorities, which is why I assigned this bug to myself as I would like to contribute a patch to fix this bug. I apologize if that was unclear. What I would like to know is if the unit test I submitted in the above patch is what you were expecting when you wrote the workaround. If so, then I don't think the fix is going to require much work at all.

I also sense some frustration on your part because of the way the current Barbican API handles IDs (or doesn't have the usual UUID IDs rather). I think it would make sense for Barbican to have an API that is more in-line with the rest of OpenStack so I've added a note to fix this in a future /v2 api. [1]

[1] https://wiki.openstack.org/wiki/Barbican/v2

Revision history for this message

Douglas Mendizábal (dougmendizabal) wrote on 2016-10-05:

#7

WORKAROUND:

For now you can retrieve secrets by using the secret.secret_id property.

retrieved_secret = conn.key_manager.get_secret(my_secret.secret_id)

works as expected.

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.