make AccessControlClientset public for creating a kubernetes client outside pkg/kubernetes

[harche]

With this change, the clients outside pkg/kuberntes, such as the one getting developed for openshift-mcp-server, can assemble a statically typed client.

With this change we can assemble a typed client like this, https://github.com/openshift/openshift-mcp-server/compare/main...harche:kubernetes-mcp-server:exec_tool?expand=1#diff-b880f18e8c0[…]405fe48bac8bR110
and then create an object (a pod in this case) like this, https://github.com/openshift/openshift-mcp-server/compare/main...harche:kubernetes-mcp-server:exec_tool?expand=1#diff-b880f18e8c0[…]405fe48bac8bR195

Even if we are making the rest config public, this doesn't increase the attack surface because the user would have been able to create arbitrary CRs allowed by their authorization using existing ResourcesCreateOrUpdate anyway.

[harche]

/cc @mrunalp

[mrunalp]

This seems reasonable to me.

[manusa]

This is partially OK.

However, if the config has configured denied access to a given resource, access WILL NOT be restricted and would be up to the toolset implementor to check the config (which won't happen)

Considering the following config:

[[denied_resources]]
version = "v1"

The implementation in the linked PR will still be able to execute.

I'm unaware of the downstream possible scenarios but I'd still suggest that we don't open it that much (i.e. completely exposing the RESTConfig).

My suggestion would be to give access to the AccessConstolClientset
And then, exposing whatever clientset is needed donwstream.

Unless I missed anything, the current implementation already provides access to every API that's needed.

So:

func (k *Kubernetes) AccessControlClientset() {
  return k.manager.accessControlClientSet
}

Should allow for:

k.AccessControlClientset().Pods($namespace).xxxWhateverInCoreV1PodInterface

If an interface is missing (Nodes or whatever), we can simply add a new method to the AccessConstolClientset

I believe that this serves as the main reasoning as to why the access to the underlying APIs should remain centralized in a central place and the API should only expose the computed clients.
If at any point we change access-control-related logic implementors automatically benefit from it and we won't have to struggle with changing implementations downstream.

[harche]

Thanks @manusa, I have updated the PR to make AccessControlClientset public instead.

[manusa]

LGTM, thx!