Epic: API Export Permissions on Binding

[shawn-hurley]

Demo Objective

• Service provider should be able to ask for additional permissions when creating an API Export for when the API is bound
• API Binding users must accept or deny the specific permissions when binding to the APIExport
• When accepted and bound, the objects granted access should be projected into the APIExports virtual workspace.

Demo Steps

1. Service Provider creates an APIExport but asks for permissions to a secrets
2. User binds to the API and accepts the permissions
3. Service provider can access the secret from the virtual workspace.

Stories

• Add new API Spec Fields for PermissionClaims that allows for addition of resources to the virtual workspace #1221
• Adding permissions claims API for granting more resource for VirtualWorkspace #1244
• When accepting the permissions, the virtual workspace should now have access to watch/list those resources.

------ 0.6 cut line

• APIExport VW should restrict for a given workspace based on bindings acceptance or rejection #1632

------- 0.7 cut line

• Add known internal types to internalschemas for the virtual workspace to use (RBAC) #1544
• Refactor permission claim object labelling to own controller #1500

------- 0.7.1 cut line

• Add e2e test cases Add more e2e test cases for permission claims #1864
  • When an APIExport removes a permission claim, its apiexport virtual workspace no longer serves that resource
  • When an APIBinding changes an accepted claim to rejected, the apiexport virtual workspace no longer serves that resource (was: Test: APIExport should be able to update permission claims at any time #1501)
  • When an APIBinding has not accepted a claim (it's neither accepted nor rejected), the apiexport virtual workspace does not include resources from the binding's workspace
• 💣🔒 APIExport VW should restrict for a given workspace based on bindings acceptance or rejection fixed in main
• Pending/approval life-cycle in APIBindings
  • add binding.status.exportPermissionClaims

------- 0.8 cut line

• 💣🔒 APIExport VW for a claim should not override MaximalPermissionPolicy of the owning APIExport of the resource (Resources accessed through PermissionClaims cannot allow privilege escalations #1337) @s-urbaniak
  • @ncdc has an e2e ready to go for this, but it will fail until we fix it
• warning on entering a workspace if there are claims from an APIExport that have not yet been accepted/rejected in an APIBinding (inside of kubectl kcp) @nrb feature: Warn Users of Pending Permission Claims On Entering A Workspace #1934

-------- MVP complete – testing-ready --------

• kubectl kcp apis bind | accept | reject – sketch out a command @dinhxuanvu feature: A Command-Line Interface For Managing API Bindings #1935
• 🔒 APIExport can add authorization and limit what a user can do in their own namespace using permission claims. feat: ability for an API provider to fully own resources in a consumer's workspace (reverse permission claim) #1840
• 🔒 Add permissions: read, create, write, delete feature: Specify Which Permissions Are To Be Claimed #1936
• Add object selection feature: Specify Which Objects Of A Resource A PermissionClaim Applies To #1937
  • single object names
  • by namespace
  • by labels
  • object reference selector (e.g. secrets referenced in PodSepc), maybe JSONPath
  • Adding regex pattern selector (on name or namespace)

[robinbobbitt]

@shawn-hurley the controller my team is building currently needs to be able to create a service account, cluster role, and cluster role bindings through the virtual workspace. Please let me know if you need additional detail. Thanks!

[pweil-]

@shawn-hurley 0.8 check in here.

Demo objectives
Service provider should be able to ask for additional permissions when creating an API Export for when the API is bound - I believe this can be checked off as complete. The remaining tasks seem to be about limiting scope and security. Correct?

Stories

are these scoped for delivery in 0.8? If not can you update the description with expected delivery items?

• APIExport VW for a claim should not override MaximalPermissionPolicy of the owning APIExport of the resource (if that is the case, we need an e2e)
• Pending/approval life-cycle in APIBindings

[pweil-]

cc @stevekuznetsov for 0.8 check in

[ncdc]

Moved #1337 to after 0.8. All claim-related work for 0.8 is now done. Moving epic milestone to v0.9

[ncdc]

APIExport can add authorization and limit what a user can do in their own namespace using permission claims.

@sttts how is this different from the local MaximalPermissionPolicy?

[ncdc]

re

Add permissions: read, create, write, delete
Add object selection
 single object names
 by namespace
 by labels
 object reference selector (e.g. secrets referenced in PodSepc), maybe JSONPath
 Adding regex pattern selector (on name or namespace)

I'd say the most basic use case here is "API provider must only be allowed to see the resources it needs and no more", or to be more specific: "you can't see all my secrets" 😄.

[stevekuznetsov]

I've expanded on the remaining bullets here to create full issues and migrated this issue to a project view.

[kylape]

@stevekuznetsov that link gives me a 404

[stevekuznetsov]

Updated link: https://github.com/orgs/kcp-dev/projects/1/views/31