Api keypair restructure #9504
Api keypair restructure #9504
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #9504 +/- ##
===========================================
Coverage 15.81% 15.82%
- Complexity 12554 12572 +18
===========================================
Files 5629 5638 +9
Lines 492028 492737 +709
Branches 62750 61359 -1391
===========================================
+ Hits 77813 77970 +157
- Misses 405892 406429 +537
- Partials 8323 8338 +15
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
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 10869 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-11249)
|
|
@KlausDornsbach all the tests were skipped because of errors like these can you explain this as a bug or feature somehow? It seems most of the simulator tests (from the github actions) passed but none of the tests with hypervisors. |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@KlausDornsbach , can you look at the conflicts and the comments please? |
…e an API key (fix failing marvin tests)
|
Sorry for taking a bit long @DaanHoogland! |
|
@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 11049 |
|
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 11120 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-11485)
|
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.
The following endpoints were created:
listUserKeys: Through this API the user will be able to specify a singlekeypairidto fetch its specific properties, auseridto fetch an user's api keypair list. If nokeypairidoruseridis provided, the API defaults to fetching information on the calling user. Thelistallproperty allows for fetching all keypairs, if not specified, it defaults to false, fetching only the last created apikey.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