Skip to content
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

Closed
wants to merge 7 commits into from
Closed

Conversation

alimaredia
Copy link
Contributor

@alimaredia alimaredia commented Feb 28, 2023

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

Checklist

  • Tracker (select at least one)
    • References tracker ticket
    • Very recent bug; references commit where it was introduced
    • New feature (ticket optional)
    • Doc update (no ticket needed)
    • Code cleanup (no ticket needed)
  • Component impact
    • Affects Dashboard, opened tracker ticket
    • Affects Orchestrator, opened tracker ticket
    • No impact that needs to be tracked
  • Documentation (select at least one)
    • Updates relevant documentation
    • No doc update is appropriate
  • Tests (select at least one)
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

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
Copy link
Contributor Author

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]"
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

@cbodley cbodley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -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'
Copy link
Contributor

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?

Copy link
Contributor Author

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.

src/rgw/driver/rados/rgw_rest_user.cc Show resolved Hide resolved
src/rgw/driver/rados/rgw_rest_user.cc Outdated Show resolved Hide resolved
src/rgw/driver/rados/rgw_rest_user.cc Outdated Show resolved Hide resolved
src/rgw/driver/rados/rgw_rest_user.cc Outdated Show resolved Hide resolved
src/rgw/driver/rados/rgw_user.cc Outdated Show resolved Hide resolved
@@ -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]"
Copy link
Contributor

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);
Copy link
Contributor Author

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.

Copy link
Contributor

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

@cbodley
Copy link
Contributor

cbodley commented Mar 2, 2023

looks great, just needs some new test cases

@alimaredia alimaredia force-pushed the wip-rgw-add-cap-keys branch 2 times, most recently from d69f04b to 1fd7118 Compare April 7, 2023 20:40
@alimaredia
Copy link
Contributor Author

@alimaredia
Copy link
Contributor Author

jenkins test make check

@alimaredia
Copy link
Contributor Author

jenkins test api

@alimaredia
Copy link
Contributor Author

jenkins test make check

@alimaredia
Copy link
Contributor Author

jenkins test api

@cbodley
Copy link
Contributor

cbodley commented Apr 12, 2023

can you please document this change in PendingReleaseNotes? something like:

RGW: A new "keys" capability was added to the /admin/user REST APIs. The "keys=write" capability is now required to create or modify secret keys, and "keys=read" is required to read them.

i think this broke something in the api tests:

FAIL: test_all (tasks.mgr.dashboard.test_rgw.RgwBucketTest)

@alimaredia alimaredia requested a review from a team as a code owner April 12, 2023 19:59
@alimaredia alimaredia requested review from nizamial09 and Pegonzal and removed request for a team April 12, 2023 19:59
@github-actions
Copy link

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

@alimaredia alimaredia force-pushed the wip-rgw-add-cap-keys branch 2 times, most recently from 822011d to 6374e69 Compare July 27, 2023 19:18
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>
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=*'
Copy link
Contributor

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>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
Signed-off-by: Ali Maredia <amaredia@redhat.com>
@github-actions
Copy link

github-actions bot commented Sep 7, 2023

This pull request can no longer be automatically merged: a rebase is needed and changes have to be manually resolved

@alimaredia
Copy link
Contributor Author

jenkins test api

@alimaredia
Copy link
Contributor Author

jenkins retest this please

Copy link

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.
If you are a maintainer or core committer, please follow-up on this pull request to identify what steps should be taken by the author to move this proposed change forward.
If you are the author of this pull request, thank you for your proposed contribution. If you believe this change is still appropriate, please ensure that any feedback has been addressed and ask for a code review.

@github-actions github-actions bot added the stale label Nov 18, 2023
Copy link

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!

@github-actions github-actions bot closed this Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
2 participants