An API provider controlling users' ability to bind to its APIExport

[ncdc]

Currently a user must have bind permission (via RBAC) to create an APIBinding that references a specific APIExport. The bind permission is currently allowed via a ClusterRole that specifically mentions the APIExport by name (wildcards are not supported at this time - see #1939), such as:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: system:kcp:apiexport:tenancy:bind
rules:
- apiGroups: ["apis.kcp.dev"]
  resources:
  - "apiexports"
  resourceNames:
  - "tenancy.kcp.dev"
  verbs: ["bind"]

And here is an example ClusterRoleBinding that allows all authenticated users to bind to this APIExport:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kcp:authenticated:apiexport:tenancy:bind
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kcp:apiexport:tenancy:bind
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated

We have an admission controller that enforces this bind verb requirement.

We've recently had some discussions around taking additional information into account when authorizing APIBinding creation. One example scenario is where an API provider may want to allow or reject an APIBinding based on its containing workspace. For example, imagine this setup:

root:api-provider
root:users:bob
root:users:alice

• bob gets access to bind to APIExports from root:api-provider
• alice does not have this permission
• alice gives bob cluster-admin in root:users:alice
• the API provider is happy that bob is trying out the APIs, but they don't really want bob to bind to their APIExport anywhere and everywhere he has permission to create APIBindings (e.g. in root:users:alice)

Some reasons why this might not be desirable, from the API provider's perspective:

• there is a cost incurred by the API provider when users use their APIs
  • the API provider wants to use ResourceQuota to limit how many instances of their APIs can be created "by a user"
  • "by a user" actually gets translated to "within a workspace subtree" because there is no hard concept of ownership of kube-like APIs
  • the API provider is able to establish quota in root:users:bob when bob creates his APIBinding, and they're happy knowing bob can't exceed the quota they set
  • if bob is able to create new APIBindings in other workspaces, especially outside of the root:users:bob subtree, he can effectively get around the quota restrictions

Does this resonate with folks? Is this something we should pursue?

[stevekuznetsov]

I think philosophically, the mere act of binding an API into a workspace should be as cheap/simple for a service provider, as it is for the system itself. I wonder if providers can simply do some lazy initialization for any new workspaces where their API is bound, if they must have default objects, instead of this more complex flow.

[vincent-pli]

The preassembled workspace is a good idea, but a well designed process for API provider and API consumer is necessary, I mean consumer may want to consume specific API after workspace is ready then he/she want to gain the permission for binding, and API provider may reject it or set the quota

[stevekuznetsov]

@ncdc it seems like fail-closed by default will be something we need overall, no?

[ncdc]

@stevekuznetsov yes, I think it would be a useful admission plugin to add

[MatousJobanek]

What is the functional difference between binding to the API, and not having any quota to make any objects, and not being able to bind to the API?

If we build on the assumption that the service acts only and only based on the API that is provided by the service via the APIExport and not based on the creation/modification of any other claimed API, then yes - there is no difference. I guess that the service provider shouldn't set a quota for the claimed API, right?
Also (as was already mentioned) the services should not create a bunch of resources automatically as soon as the APIExport is bound - it should be done lazily, otherwise, it could hit the error with zero quotas.

However - as @ncdc mentioned - this expects:

• either that absence of the quota is equal to zero
• or every service provider (and each component of the service) has its own logic to automatically set zero quotas for every workspace which is not approved for the service

yes, I think it would be a useful admission plugin to add

@ncdc could you please elaborate on what admission plugin are you talking about

[ncdc]

An admission plugin that rejects creates for certain resources if there is no applicable ResourceQuota for them. TBD what the semantics would be - some possibilities:

• "quota required" list
  • if the resource being created is in the list, only allow the create attempt to proceed if there is at least 1 ResourceQuota that applies to this resource (the actual quota evaluation would be handled separately)
  • if the resource being created is not in the list, let it proceed to further admission checks
• "quota not required list"
  • same as "quota required", but the inverse

[MatousJobanek]

There is another option for limiting the scope where the service's APIBinding can be created (on the service provider side).

Consider that there is a controller called api-manager that automatically manages all APIBindings that are part of the service. The user (or CWT initializer) creates only the APIBinding of the api-manager. The controller then automatically creates additional APIBindings in the workspace (eg. Gitops, Build, etc... ).
We are going to have such an api-manager in AppStudio and in other services too.

So, the idea is that the api-manager could check (in some CR) if the workspace is entitled to the service or not. Then, based on this information, it can decide if it will create the additional APIBindings or not.

There is one requirement - the SA of the api-manager can be the only one who can bind the APIExports of the service in the user's workspace.