KlausDornsbach opened a new pull request, #9504:
URL: https://github.com/apache/cloudstack/pull/9504
### 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:
`listUserKeyPairs`: Through this API the user will be able to specify a
single `keypairid` to fetch its specific properties, a `userid` to fetch an
user's api keypair list. If no `keypairid` or `userid` is provided, the API
defaults to fetching information on the calling user. The `listall` property
allows for fetching all keypairs, if not specified, it defaults to false,
fetching only the last created apikey.
| **Name** | **Description** | **Required** |
**Default** |
|:---------------------:|:----------------------------:|:--------------:|:-----------:|
| userid | id of owner of the keypairs | no |
none |
| keypairid | id of keypair | no |
none |
| listall | list all accessable keypairs | no |
false |
The API `getUserKeyPairs` was modified preserving backwards compatibility.
It now fetches the last keypair created for the informed user, also new
parameters were added:
| **Name** | **Description** | **Required** |
**Example** | **Default**
|
|:---------------------:|:---------------------------:|:--------------:|:---------------------------------------------:|:----------------------------------:|
| id | user id | Yes |
b8914774-771e-11ee-8e59-5254003754dc | -
|
| name | name of the keypair | No |
MyKey | userId + " - API Keypair"
|
| startdate | date when key becomes valid | No |
2024-04-09 | no start date
|
| enddate | date when key expires | No |
2024-04-09 | never expires
|
| description | keypair description | No |
read only permissions | no description
|
| rules | list of API access rules | No |
rules[1].rule=list* rules[1].permission=allow | all user API permissions based
on Account Role |
Also, a new keypair deletion API was added (`deleteUserKeys`). It will
accept only one required argument, the keypair `id`.
| **Name** | **Description** | **Required** |
|:---------------------:|:---------------------------:|:--------------:|
| id | api key of the keypair | yes |
### Types of changes
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [X] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [X] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] build/CI
- [ ] test (unit or integration test code)
### Feature/Enhancement Scale or Bug Severity
#### Feature/Enhancement Scale
- [X] Major
- [ ] Minor
#### Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [ ] Minor
- [ ] Trivial
### How Has This Been Tested?
#### API Key Creation and Basic Testing
Single Key (via UI):
1. I was able to create API keypairs through the UI through the button on
the top right of the user view;
2. Through Cloud Monkey, validated that the keypair had the same permissions
as the base user by calling a series of APIs;
Multiple Keys (via Cloud Monkey):
1. Created multiple keys;
2. Validated the operation was successful on the DB;
3. Tested creating a key that was not valid and would become valid in the
future, with success;
4. Tested creating a key that was valid and would become invalid in the
future, with success;
5. Tested trying to create keys that were already invalid and got errors;
6. All permissions of the API key pairs were consistent with each key pair
tested.
#### Permissions Validation
Tested the permissions of keyrules listing, keypair listing, keypair
deletion and keypair cretion with the following user/account/domain setup:
- domain `/ROOT`
- conta `root admin`
- user `root admin`
- user `user1`
- domain `subdomain`
- conta `domain admin`
- user `domain admin`
- conta `userAccount`
- user `user2`
- user `user3`
The 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).
| user | rootAdm | user1 | domainAdm | user2 | user3 |
| ----- | ------- | ----- | --------- | ----- | ----- |
| rootAdm | V | V | V | V | V |
| user1 | V | V | V | V | V |
| domainAdm | F | F | V | V | V |
| user2 | F | F | F | V | F |
| user3 | F | F | F | F | V |
#### Migration to `api_keypair` Table
1. A key was created for a read-only user
2. The database was updated from version `4.19` to `4.20`
3. The API key data was successfully migrated to the `api_keypair` table,
with the corresponding columns in the user table deleted.
4. Confirmed correct permission handling of the api key.
#### General validations
- Could not create an API keypair with more permissions than the base
keypair.
- Deleting system keys was not possible.
- After deleting a user or account, the API keypairs were invalidated.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@cloudstack.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
