Api keypair restructure #9504
Api keypair restructure #9504
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9504 +/- ##
============================================
+ Coverage 16.53% 16.58% +0.04%
- Complexity 13819 13887 +68
============================================
Files 5717 5729 +12
Lines 506626 508035 +1409
Branches 61481 61628 +147
============================================
+ Hits 83782 84245 +463
- Misses 413454 414356 +902
- Partials 9390 9434 +44
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
nice feature @KlausDornsbach , some suggestions,
|
|
Hey @DaanHoogland, thanks for taking a look! It would make sense to be able to delete a keypair by name, we would just need to block users from creating multiple API keypairs with the same name. At the moment an admin is allowed to delete keypairs from users it has access, for example, a root admin user could delete any keypair in the platform, domain admin users can delete any keypair in the domain, normal users can only delete their own keys. These permissions are also true for visualization and creation APIs. |
Well, I think a unique constraint on UserId/KeyPairName makes sense also from a usability sense.
👍 |
|
@blueorangutan package |
api/src/main/java/org/apache/cloudstack/api/command/admin/user/ListUserKeysCmd.java
Outdated
Show resolved
Hide resolved
engine/schema/src/main/java/org/apache/cloudstack/acl/ApiKeyPairPermissionVO.java
Outdated
Show resolved
Hide resolved
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 10714 |
|
@blueorangutan package |
|
@rajujith a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 10720 |
|
@blueorangutan package |
|
@rajujith a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 10736 |
|
@blueorangutan test |
|
@blueorangutan package |
|
@nicoschmdt a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 13529 |
|
@blueorangutan package |
|
@nicoschmdt a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 13551 |
|
@blueorangutan package |
|
@blueorangutan package |
|
@nicoschmdt a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 13578 |
|
@DaanHoogland could we run the tests again? |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian Build Failed (tid-13460) |
|
Hey @DaanHoogland could you send me the log file so that I can identify the error? |
|
[SF] Trillian test result (tid-13462)
|
|
@nicoschmdt , there is now clearly some API that work so the main issue is no longer that the keys can not be found. The zip should contain any logs you need.
|
|
@DaanHoogland Thanks! I'll look into it as soon as possible |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
Hi @KlausDornsbach do you plan to work on this to resolve conflicts? Do you think this can be included in 4.22? |
9 participants
Description
API access keypairs are primarily used to support interactions between systems, without the need to create sessions (through user and password authentication). Currently, CloudStack's implementation of API keypairs does not allow you to specify permissions for each keypair, simply using the account's default permissions. Additionally, the number of keypairs is limited to one per user and they have no start and end dates.
An extension of the API keypairs functionality was implemented, adding several new features that increase flexibility and security. It is now possible to specify a subset of permissions (from the base account) for each keypair, as well as create more than one key per user. It is also possible to define start and end dates for the validity of a keypair. A key created without an expiration date will always be valid up until it is deleted. It should be noted that creating API keypairs without specifying permissions just creates an API keypair with all account's base permissions. Also, API keypairs older than this patch will always be viewed as keypairs with full account permissions.
The following endpoints were created:
A new
listUserKeysAPI was added. Through this API the user will be able to specify a singlekeypairidto fetch its specific properties, orapikeyfilterto return a specific keypair based on anapikey. The user can inform anuseridto fetch an user's api keypair list. If nokeypairid,apikeyfilteroruseridis provided, the API defaults to fetching information on the calling user. Thelistallproperty allows for fetching all keypairs in the structure that are visible based on the calling user/keypair permissions, if not specified, it defaults to false, fetching only the apikeys on the level of the calling user/keypair. Also, it is possible to informshowpermissionsto list all permissions associated with each returnedapikey.The API
getUserKeyswas modified preserving backwards compatibility. It now fetches the last keypair created for the informed user.The api
registerUserKeyswas modified so the new API keypair parameters could be specified on creation:A new keypair deletion API was added (
deleteUserKeys). It will accept only one required argument, the keypairid.I also added a
listUserKeyRulesapi, allowing the user to list the rules associated with an API keypair.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
How Has This Been Tested?
API Key Creation and Basic Testing
Single Key (via UI):
Multiple Keys (via Cloud Monkey):
Permissions Validation
Tested the permissions of keyrules listing, keypair listing, keypair deletion and keypair cretion with the following user/account/domain setup:
/ROOTaccount
root adminroot adminuser1domain
subdomaindomain admindomain adminuserAccountuser2user3The following table describes the results obtained when the user on the first column attempted to operate on the keypairs of users on the first row (V: operation was possible, F: operation was not possible).
Migration to
api_keypairTable4.19to4.20api_keypairtable, with the corresponding columns in the user table deleted.General validations