Kubernetes provider needs not to require cluster-admin role

[grafanalf]

What problem are you facing?

As per the documentation, and based on my own experience running it in production, it is complicated to infer what permissions to grant to the provider-kubernetes Service Account other than the cluster-admin. Running as cluster-admin is seen as a risk by our security team.

How could Crossplane help solve your problem?

It would be highly appreciated if, as part of the provider documentation, or as part of the integration with Crossplane's RBAC, the Kubernetes provider can describe the least permissions to be ran use, other than user cluster-admin.

[phisco]

I don't think there is a way to do this, you'd have to predict the future and know what resources you'll wrap in Objects either directly or through Compositions

[grafanalf]

The problem is that when using watches (Alpha at the moment), I can't seem to get the correct RBAC policy to have my Object resources properly watch the underlying Kubernetes resources. Instead, propagation of status from the real Kubernetes resource into atProvider takes the reconciliation time (10 minutes).

Using cluster-admin works fine, though.