-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RGW: add new cap 'keys' #50313
RGW: add new cap 'keys' #50313
Conversation
doc/radosgw/adminops.rst
Outdated
will be swift type. If only one of ``access-key`` or ``secret-key`` is provided the | ||
committed key will be automatically generated, that is if only ``secret-key`` is | ||
specified then ``access-key`` will be automatically generated. By default, a | ||
will be swift type. If only one of ``access-key`` or ``secret-key`` is provided an |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though this is out of scope for this PR I noticed that both of the keys needed to be included in a create new key request or else the operation would not go through. I get a InvalidSecretKey
and InvalidAccessKeyID
when either are empty in a request.
@@ -311,7 +311,7 @@ To add administrative capabilities to a user, execute the following:: | |||
You can add read, write or all capabilities to users, buckets, metadata and | |||
usage (utilization). For example:: | |||
|
|||
--caps="[users|buckets|metadata|usage|zone|amz-cache|info|bilog|mdlog|datalog|user-policy|oidc-provider|roles|ratelimit]=[*|read|write|read, write]" | |||
--caps="[users|keys|buckets|metadata|usage|zone|amz-cache|info|bilog|mdlog|datalog|user-policy|oidc-provider|roles|ratelimit]=[*|read|write|read, write]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbodley do you think it would be worth documenting what each of these caps does at a high level in the docs? There's nothing like that so far, though in the admin api does reference which caps are necessary for certain operations.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the adminapi docs are consistent about showing the required caps, i think that's probably all the documentation we need
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
qa/tasks/radosgw_admin_rest.py
Outdated
@@ -141,7 +141,7 @@ def task(ctx, config): | |||
admin_display_name = 'Ms. Admin User' | |||
admin_access_key = 'MH1WC2XQ1S8UISFDZC8W' | |||
admin_secret_key = 'dQyrTPA0s248YeN5bBv4ukvKU0kh54LWWywkrpoG' | |||
admin_caps = 'users=read, write; usage=read, write; buckets=read, write; zone=read, write; info=read;ratelimit=read, write' | |||
admin_caps = 'users=read, write; usage=read, write; buckets=read, write; zone=read, write; info=read;ratelimit=read, write; keys=read, write' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, so this verifies that all of the output is the same if you add the keys caps; but i think we also want to test that we don't see keys if we're missing that cap. i think that means we need to create a separate Assistant Admin User
with only the user caps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I'm going to be adding those tests at the end of the file. I wanted to just get the PR out there and make sure that this tests passes with the new caps on a locked teuthology machine before I start adding more to this test file.
@@ -311,7 +311,7 @@ To add administrative capabilities to a user, execute the following:: | |||
You can add read, write or all capabilities to users, buckets, metadata and | |||
usage (utilization). For example:: | |||
|
|||
--caps="[users|buckets|metadata|usage|zone|amz-cache|info|bilog|mdlog|datalog|user-policy|oidc-provider|roles|ratelimit]=[*|read|write|read, write]" | |||
--caps="[users|keys|buckets|metadata|usage|zone|amz-cache|info|bilog|mdlog|datalog|user-policy|oidc-provider|roles|ratelimit]=[*|read|write|read, write]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the adminapi docs are consistent about showing the required caps, i think that's probably all the documentation we need
if(keys_perm < 0) { | ||
dump_keys = false; | ||
} | ||
return RGWUserAdminOp_User::create(dpp, store, op_state, flusher, dump_keys, null_yield); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cbodley I determined the value of dump_keys
from the op_state
here. Was that the right thing to do? I don't know which code paths exercise this RGWUserAdminOp_User::create()
so I'm not sure if there is an req_state
somewhere up the call stack.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alimaredia i think it's right, but nothing uses this RGWUserCreateCR
class after @yuvalif removed pubsub in #48996. i'd rather remove the class entirely than continue to maintain it
54fe3c9
to
d7a273b
Compare
looks great, just needs some new test cases |
d69f04b
to
1fd7118
Compare
jenkins test make check |
jenkins test api |
jenkins test make check |
jenkins test api |
d7d3d66
to
01bba25
Compare
can you please document this change in PendingReleaseNotes? something like:
i think this broke something in the api tests:
|
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
822011d
to
6374e69
Compare
This new capability for a user of the admin ops api determines whether the user can write keys and read keys from the response of an operation made via the admin api. Tests in teuthology for new cap added as well. Signed-off-by: Ali Maredia <amaredia@redhat.com>
670aec9
to
8b4c81b
Compare
Signed-off-by: Ali Maredia <amaredia@redhat.com>
@@ -223,6 +223,7 @@ def _get_user_keys(user: str, realm: Optional[str] = None) -> Tuple[str, str]: | |||
'user', 'create', | |||
'--uid', user, | |||
'--display-name', 'Ceph Dashboard', | |||
'--caps', 'keys=*' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alimaredia oh, this is already a --system
user. i think our rest apis should treat system users as if they have all caps
Signed-off-by: Ali Maredia <amaredia@redhat.com>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
8583817
to
1e2e69b
Compare
Signed-off-by: Ali Maredia <amaredia@redhat.com>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved |
jenkins test api |
jenkins retest this please |
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution! |
This new capability for a user of the admin ops api determines whether the user can write keys via admin api operations and read keys from the response of an operation made via the admin api.
Details of the behavior pull request can be read here:
https://gist.github.com/alimaredia/02fd412aaa024922f9270fc24a01857f
Contribution Guidelines
To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
Checklist
Show available Jenkins commands
jenkins retest this please
jenkins test classic perf
jenkins test crimson perf
jenkins test signed
jenkins test make check
jenkins test make check arm64
jenkins test submodules
jenkins test dashboard
jenkins test dashboard cephadm
jenkins test api
jenkins test docs
jenkins render docs
jenkins test ceph-volume all
jenkins test ceph-volume tox
jenkins test windows