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

Add manage_own_api_key cluster privilege #45696

Merged
merged 34 commits into from
Aug 23, 2019

Conversation

bizybot
Copy link
Contributor

@bizybot bizybot commented Aug 19, 2019

This commit adds manage_own_api_key cluster privilege which
only allows api key cluster actions on API keys owned by the
currently authenticated user.

Relates: #40031

Yogesh Gaikwad added 2 commits August 12, 2019 13:59
Currently, cluster permission checks whether a cluster action is
permitted and optionally in the context of a request. There are
scenarios where we would want to check whether the cluster action
is permitted, optionally in the context of a request and current
authentication. For example, management of API keys is only
restricted to the API keys owned by the current user. In this case,
along with the cluster action and API key request, the check
needs to perform whether the currently authenticated user is indeed
allowed to operate only on owned API keys.
With this commit, we are introducing one more context of the current
authentication that can be considered during permission evaluation.

Relates: elastic#40031
@bizybot bizybot added >bug :Security/Authorization Roles, Privileges, DLS/FLS, RBAC/ABAC v8.0.0 v7.4.0 labels Aug 19, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-security

Yogesh Gaikwad added 10 commits August 20, 2019 13:36
The permission checks that are dependent on actions and
optionally on request and/or on authentication, now
have a way to specify the predicates. By default
the implementation will tests all the predicates to be
successful for the operation to be allowed.
In case customization is required one has option to
implement `PermissionCheck`.

- Adds a permission check predicate interface that also
  allows implementers to specify behavior for `implies`.
This commit adds `manage_own_api_key` cluster privilege which
only allows api key cluster actions on API keys owned by the
current authenticated user.
Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

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

I left two questions.

Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

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

It is still not clear to me what API-Key-privileges do I have if I authenticate with an API Key. Do I inherit the API-Key privileges from the user that originally created the first API key that created my API Key, etc... ? Or I don't have any API Key privilege.

For example, a user with manage_api_key create a key. Does that key grant manage_api_key as well? I think it shouldn't but the code looks like it does.
The same for manage_own_api_key.

I

@bizybot bizybot requested a review from tvernum August 22, 2019 03:18
@bizybot bizybot changed the base branch from moap-authentication-based-permission-check to manage-own-api-key-privilege August 22, 2019 07:33
@bizybot
Copy link
Contributor Author

bizybot commented Aug 22, 2019

@albertzaharovits
Just to help the discussion and for my sanity:

User ▼ API Key Action ► Create API key Invalidate API key GET API key
User with all or manage_security or manage_api_key privilege Allow Allow Allow
User authenticated using API key with all or manage_security or manage_api_key privilege Allowed but resultant API keys are no-op Allow Allow
User with manage_own_api_key privilege Allow Allowed only on owned API keys Allowed only on owned API keys
User authenticated using API key with manage_own_api_key privilege Allowed but resultant API keys are no-op Allowed only to invalidate self Allowed only to retrieve self
User with no privilege related to API keys Deny Deny Deny
User authenticated using API keys with no privilege related to API keys Deny Deny Allowed only to retrieve self

Copy link
Contributor

@albertzaharovits albertzaharovits left a comment

Choose a reason for hiding this comment

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

I left one suggestion and voiced my preference about not using the owner flag in the authz process.
LGTM

@albertzaharovits
Copy link
Contributor

albertzaharovits commented Aug 22, 2019

Thank you for the tabled explanation @bizybot !
Nitpicking: An API key with manage_security can always create more API keys, because it can create other users (assuming the native realm is enabled) and create APi keys for those.

I agree we should explicitly deny authorization for API keys with manage_api_key (I won't worry about BWC because I consider this a bug) and this might require building a new NamedPrivilege implementation 🌞

Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

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

I think we're very close on this.

realm = (String) authentication.getMetadata().get(ApiKeyService.API_KEY_CREATOR_REALM);
} else {
realm = authentication.getAuthenticatedBy().getName();
}
Copy link
Contributor

@tvernum tvernum Aug 23, 2019

Choose a reason for hiding this comment

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

The same logic is in 2 transport actions. That seems like a strong enough argument to move it to a static method on the service.

Yogesh Gaikwad added 2 commits August 23, 2019 12:25
- separate tests to test one thing
- common code to extract realm name  move to ApiKeyService
- final and move variables to where it is being used
- test API keys with no cluster privilege for an API key
Copy link
Contributor

@tvernum tvernum left a comment

Choose a reason for hiding this comment

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

LGTM, subject to 1 minor change.

@bizybot bizybot requested a review from tvernum August 23, 2019 02:43
@tvernum
Copy link
Contributor

tvernum commented Aug 23, 2019

@bizybot It looks like you requested another approval after I had already commented.

@bizybot
Copy link
Contributor Author

bizybot commented Aug 23, 2019

@bizybot It looks like you requested another approval after I had already commented.

Oh, I looked at one of the cached pages in the browser and thought I missed on refresh.

@bizybot bizybot merged commit ed2062f into elastic:manage-own-api-key-privilege Aug 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants