keypair-list should allow you to specify a user or all-users

Bug #1182965 reported by Scott Devoid
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Wishlist
Dan Smith

Bug Description

Support one or more of the following:

nova keypair-list --all-users
nova keypair-list --user-id <uuid>
nova keypair-list --user <username>

Currently you can only see keypairs you uploaded.

This feature is useful for two reasons:
1. You can attach someone else's keypair to a VM, allowing them to login.
2. An administrator can query for keypairs.

Anusha K (anusha25)
Changed in python-novaclient:
assignee: nobody → Anusha Konda (kondaanushareddy)
status: New → In Progress
Anusha K (anusha25)
Changed in python-novaclient:
status: In Progress → New
assignee: Anusha Konda (kondaanushareddy) → nobody
Revision history for this message
Scott Devoid (scott-devoid) wrote :

We may need to rope in changes to nova. I think the current APIs are at fault there.

Revision history for this message
Andrew Laski (alaski) wrote :

The Nova api doesn't support retrieving keypairs for another user. I'm not sure how this feature will be possible without a large reworking of keypairs since there's no mapping of keypair to tenant anywhere, they're only attacked to user_ids. So rather than a bug I see this as more of a feature that needs to be implemented before a client can support it.

Changed in python-novaclient:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Scott Devoid (scott-devoid) wrote :

This bug relates to a feature that is not currently supported in the Nova API. It would be useful to attach other user's keys to an instance (e.g. allow multiple users to login to the same instance). Additionally it is useful as an operator for verifying keypair fingerprints against the user's private key fingerprint.

affects: python-novaclient → nova
summary: - keypair-list should allow you to specify a tenant or all-tenants
+ keypair-list should allow you to specify a user or all-users
description: updated
Revision history for this message
Dan Radez (dradez) wrote :

I've submitted https://review.openstack.org/#/c/70485/ and https://review.openstack.org/#/c/70490/ for review. Take a few mins to apply and test it and submit a review for it to be merged.

It only supports passing a user id, not a user name. This conforms with other client parameter handling.

As admin user you can do:
nova keypair-list
and get your keypairs, or you can do
nova keypair-list --user 123abc345def
and get the keypair list for the user id passed.

Changed in nova:
assignee: nobody → Dan Radez (dradez)
Revision history for this message
Scott Devoid (scott-devoid) wrote :

@dradez, this looks very promising. I couldn't find a nova-spec blueprint for this; would you like me to create one? I would very much like to see this make it for Juno!

Revision history for this message
Dan Radez (dradez) wrote :

@scott-devoid go ahead and make a blueprint if you'd like to. Thanks.
At this point the patches look that they're waiting for review for Juno.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

Change abandoned by Sean Dague (<email address hidden>) on branch: master
Review: https://review.openstack.org/70485
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.

Changed in nova:
status: Confirmed → In Progress
Revision history for this message
Davanum Srinivas (DIMS) (dims-v) wrote :

Removing "In Progress" status and assignee as change is abandoned.

Changed in nova:
status: In Progress → Confirmed
assignee: Dan Radez (dradez) → nobody
Changed in nova:
assignee: nobody → Kun Huang (academicgareth)
Changed in nova:
assignee: Kun Huang (academicgareth) → Dan Smith (danms)
status: Confirmed → In Progress
Changed in nova:
assignee: Dan Smith (danms) → Vladik Romanovsky (vladik-romanovsky)
Changed in nova:
assignee: Vladik Romanovsky (vladik-romanovsky) → Dan Smith (danms)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/70485
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1b8a2e0a928b142b453dd76dc1afed0b26ee6eae
Submitter: Jenkins
Branch: master

commit 1b8a2e0a928b142b453dd76dc1afed0b26ee6eae
Author: Vladik Romanovsky <email address hidden>
Date: Mon Apr 20 13:21:37 2015 -0700

    Adding user_id handling to keypair index, show and create api calls

    Administering an openstack cluster I found the need to see what keypairs a
    user had. I found this bug that was requesting the same thing and decided
    to implement it. This is the update to the api server to handle a query
    param passed to return a keypair list for a specific user-id. Only a user
    with admin privileges is allowed to make this call.

    Allowing the administrators to be able to list and get details of keypairs
    which owned by users other than themselves, as well as creating new and
    deleting keypairs on behalf of their users.

    DocImpact: This adds API microversion
    Implements blueprint admin-query-any-keypair
    APIImpact
    UpgradeImpact: Policy rules of the index, create, delete and show
                   operations has been updated to support the change.
                   os_compute_api:os-keypairs:{index, show, create, delete}:
                   "rule:admin_api or user_id:%(user_id)s

    Co-Authored-By: Dan Smith <email address hidden>
    Co-Authored-By: Dan Radez <email address hidden>
    Closes-Bug: #1182965
    Change-Id: I45846f770628e8f24a8c137dcdc46baa64c50801

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → liberty-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: liberty-3 → 12.0.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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