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

feature: restrict claiming API bindings #2462

Open
1 task done
s-urbaniak opened this issue Dec 8, 2022 · 1 comment
Open
1 task done

feature: restrict claiming API bindings #2462

s-urbaniak opened this issue Dec 8, 2022 · 1 comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@s-urbaniak
Copy link
Contributor

Feature Description

During development of #2089 it came to our attention that API bindings are special in the virtual API export service.

Today, similar to any other resource API bindings can be claimed like any other resource. This is dangerous as it opens up the possibility for service providers to claim API bindings and thus be able to import any arbitrary API into user workspaces. Creating API bindings should be in the autonomy of the actual workspace users and thus claiming it should be prohibited.

Proposed Solution

Needs discussion and design.

Alternative Solutions

No response

Want to contribute?

  • I would like to work on this issue.

Additional Context

No response

@s-urbaniak s-urbaniak added the kind/feature Categorizes issue or PR as related to a new feature. label Dec 8, 2022
@stevekuznetsov
Copy link
Contributor

In the past we spoke not of forbidding it entirely, but allowing it if and only if the permission claim was for "everything", that is - make it clear to users that if they accept a claim on APIBindings, they are giving someone else total admin over all the data in the workspace.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
Status: New
Development

No branches or pull requests

2 participants