-
-
Notifications
You must be signed in to change notification settings - Fork 658
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
refactor: token permissions, drop admin-like permissions #4050
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
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.
I might be missing some details, I think this looks good but there are a few things I'm struggling to understand, so let's take a look at them tomorrow ;)
@@ -106,7 +91,7 @@ const tokenTypeToUpdatePermission: (tokenType: ApiTokenType) => string = ( | |||
) => { | |||
switch (tokenType) { | |||
case ApiTokenType.ADMIN: | |||
return UPDATE_ADMIN_API_TOKEN; | |||
return ADMIN; |
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.
This allowed customers to have fine-grained control over permissions, I'm just trying to play devil's advocate here. But before admins could remove the admin permission to update an admin token, but now it's all or nothing, right? I'm wondering if we should keep the fine-grained permissions
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.
This permission was only introduced in #4019 (yesterday) so it's not like these are breaking changes.
I don't think there's a use case for someone that has access to admin tokens but is not an admin themselves, as they could simply create an admin API token and override the specific permissions anyways.
Basically what I meant by:
Drops our higher-level permissions that basically mean ADMIN (e.g. ADMIN token permissions) in favor of ADMIN permission in order to avoid privilege escalations;
DELETE FROM permissions WHERE permission IN ('CREATE_API_TOKEN', 'UPDATE_API_TOKEN', 'DELETE_API_TOKEN', 'READ_API_TOKEN'); | ||
DELETE FROM permissions WHERE permission = 'UPDATE_ROLE'; | ||
DELETE FROM permissions WHERE permission IN ('CREATE_ADMIN_API_TOKEN', 'UPDATE_ADMIN_API_TOKEN', 'DELETE_ADMIN_API_TOKEN', 'READ_ADMIN_API_TOKEN'); |
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.
I would not delete these permissions just yet to prevent potential backward compatibility problems. Note that the old version will still be running while these permissions are deleted
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.
This was only added a few versions back 3acb116#diff-d9d1a3ae5564ee96665ff5c5d42f10debedce779340e421d55dc2f3de9b3117fR4-R19 but this could be already deployed to customers. I'd just open a new PR after this one gets merged and deployed
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.
Reminder that ADMIN
overrides this anyways and custom root roles are not available for customers yet, but if we feel safer only adding a migration with these deletions after we make sure the code changes are there, we can do that.
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.
Addressed in: dd2ac48
We should add this in a later PR:
DELETE FROM permissions WHERE permission IN ('CREATE_API_TOKEN', 'UPDATE_API_TOKEN', 'DELETE_API_TOKEN', 'READ_API_TOKEN');
DELETE FROM permissions WHERE permission = 'UPDATE_ROLE';
DELETE FROM permissions WHERE permission IN ('CREATE_ADMIN_API_TOKEN', 'UPDATE_ADMIN_API_TOKEN', 'DELETE_ADMIN_API_TOKEN', 'READ_ADMIN_API_TOKEN');
@@ -107,7 +105,7 @@ export const CreateApiToken = ({ modal = false }: ICreateApiTokenProps) => { | |||
handleSubmit={handleSubmit} | |||
handleCancel={handleCancel} | |||
mode="Create" | |||
actions={<CreateButton name="token" permission={permission} />} | |||
actions={<CreateButton name="token" permission={ADMIN} />} |
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.
Does this apply for all types of API tokens? Or just admin tokens?
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.
All types of tokens currently. It's essentially the same behavior as before: Only ADMIN
s are able to create API tokens, except now we're being specific about it instead of pointing to a permission that only ADMIN
s have anyways.
Of course with the new permissions and custom root roles you're now able to create tokens of a specific type if you have that permission, but only on the API level, it's not reflected on the UI yet.
This is what I meant in:
There's some UI permission logic around this, but in the future https://linear.app/unleash/issue/2-1156/adapt-api-tokens-creation-ui-to-new-permissions could take it a bit further by adapting the creation of tokens as well.
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.
It's essentially the same behavior as before: Only ADMINs are able to create API tokens, except now we're being specific about it instead of pointing to a permission that only ADMINs have anyways.
Thanks! Cristal clear!
@@ -67,7 +88,7 @@ export const ApiTokenPage = () => { | |||
/> | |||
<PageHeader.Divider /> | |||
<CreateApiTokenButton | |||
permission={CREATE_API_TOKEN} | |||
permission={ADMIN} |
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.
Is only admin able to create new ones? What if we want to assign the permission of creating new client tokens to a service account?
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.
They can through the API. Same as #4050 (comment)
@@ -490,11 +465,11 @@ describe('Fine grained API token permissions', () => { | |||
}); | |||
await destroy(); | |||
}); | |||
test('READ_ADMIN_API_TOKEN should be able to see ADMIN tokens', async () => { | |||
test('ADMIN should be able to see ADMIN tokens', async () => { |
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.
I think we can add the opposite test as well: VIEWER or EDITOR (you pick) cannot see ADMIN tokens
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.
Sure, good point 🙂
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.
Addressed in 42280e9
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
798828e
to
2080cdd
Compare
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.
Well done! Especially clarifying doubts 🎯 and adding more tests 🤖! LGTM!
https://linear.app/unleash/issue/2-1155/refactor-permissions
rbac-middleware
now supports multiple OR permissions;ADMIN
permission in order to avoid privilege escalations;This PR may help with https://linear.app/unleash/issue/2-1144/discover-potential-privilege-escalations as it may prevent privilege escalations altogether.
There's some UI permission logic around this, but in the future https://linear.app/unleash/issue/2-1156/adapt-api-tokens-creation-ui-to-new-permissions could take it a bit further by adapting the creation of tokens as well.