🐛 Remove scope from initializingworkspaces virtual workspace #3264
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
As part of #3235, we added scoping to the impersonation that happens in the
initializingworkspaces
virtual workspace when proxying through content access. This creates a fundamental problem: When creatingAPIBindings
through it (a common activity done by kcp itself for the default API bindings in aWorkspaceType
), the impersonated identity will always be out-of-scope for the workspace that holds the targetAPIExport
for a default binding.This means default API bindings would always be bound as
system:anonymous
/system:authenticated
(the identity of out-of-scope entities), which means you cannot properly provide permissions to the owner of a workspace (which is the identity impersonated by the virtual workspace).So for now we think we should undo the scoping in the virtual workspace.
Related issue(s)
Fixes #
Release Notes