Clarify which credentials plugins should use to access Kubernetes clusters

[kahirokunn]

While implementing the Secret Reader plugin, I noticed that it is unclear which credentials a plugin should use to access a Kubernetes cluster:

1. Load from the environment
2. Use cp-creds.json
3. Be explicitly provided by the controller using the plugin

Currently, the KEP does not provide guidance on this.
I believe it would be helpful to clarify the expected approach and, if necessary, add supplementary notes to the KEP.

Related PR: #21

[ryanzhang-oss]

I wonder what is a "plugin" in this context?

[kahirokunn]

Thank you for your question!
I'm referring to the Secret Reader plugin described in the KEP here:
https://github.com/kubernetes/enhancements/blob/master/keps/sig-multicluster/5339-clusterprofile-plugin-credentials/README.md#secret-reader-plugin
The core question is: How should the Secret Reader plugin obtain credentials to access Kubernetes clusters? I believe this should be clearly specified.
In my current implementation, I'm taking a best-effort approach by reading kubeconfig from the environment. However, I'm uncertain whether this is the correct approach.
My concern is this: if the controller receives parameters at startup to specify a KUBECONFIG file or Context, there could be a mismatch between the credentials used by the controller and those used by the plugin. Is this the intended behavior?
I believe this issue hasn't been problematic until now because most plugins typically retrieve information from non-Kubernetes APIs (such as AWS or GCP). However, when a plugin needs to access the Kubernetes API for credentials, the expected behavior becomes unclear.
If the specification intends to leave this flexible and up to individual plugin implementations, I would like to propose adding explicit documentation to the KEP stating that this is intentionally left as an implementation detail for each plugin.
I'd be happy to contribute a PR to add clarification on this topic to the KEP if that would be helpful.

[skitt]

/sig multicluster

[ryanzhang-oss]

@kahirokunn, IMO, the entire KUBCONFIG is not supposed to be the enviornment to the plug-in. That's almost equalvent to just store the KubeConfig in a secret which is exactly what we want to avoid. The clusterProfile itself does not provide any credetial so in most cases, any plug-in (the real credential provider) should be able to acess it.

[kahirokunn]

@ryanzhang-oss Thanks!

For the Secret Reader plugin specifically, what’s the intended/ideal way to access the target Kubernetes cluster and read Secrets, if passing a full kubeconfig via env is discouraged?
Is the expectation in-cluster SA/RBAC, or obtaining short-lived creds from an external identity provider (OIDC/STS, etc.)?

[kahirokunn]

The Secret Reader plugin requires permission to access the Kubernetes cluster in order to retrieve secrets.
I created this issue because I believe we need to consider in detail how the Secret Reader plugin should properly obtain that permission.
This is because similar plugins requiring access to the Kubernetes cluster will likely emerge in the future, and having guidelines would be helpful.