Possibility to configure RBAC

[ONordander]

What problem are you facing?

I'm trying to use provider-kubernetes to create Kubernetes Jobs, however the RBAC settings for the used ServiceAccount won't allow it.
I can specify a ServiceAccount to use but then I also need to manually add the RBAC settings for my resources as well as the CRDs from this package.

How could Crossplane help solve your problem?

Ability to somehow configure RBAC settings for the provider without having to create an extra ServiceAccount.
I suppose it would also be okay if the created ServiceAccount was deterministic (for example by specifying the name).
Then we could just add extra Roles on top of the pre-existing ones.

[morningspace]

@ONordander Trying to understand your problem. Is it the RBAC for the service account that is needed for the Job that you create by using this provider, or you are referring the RBAC for the provider itself? It would be good to give some concrete example.

[ONordander]

Hey @morningspace, thanks for responding.
I'm talking about RBAC for the provider itself. The provider "suffers" from the same problem that the other providers do, they use a generated ServiceAccount name which makes it more difficult to set correct permissions.

For example if I want to give the provider the permission to create secrets I can do that declaratively by creating a new ServiceAccount, however that ServiceAccount will not have the correct permissions to handle the provider objects itself e.g.
providerconfigs.kubernetes.crossplane.io
So I have to add that myself, which is not very user-friendly.
I would like to use a custom ServiceAccount and be able to add only my own additions on top and get the needed permissions for the provider out of the box.
I hope that makes sense, and we can probably draw inspiration from similar discussions in the other providers.

[morningspace]

Ah, the provider uses sa where the name is something randomly generated, right? IIRC, that logic comes from crossplane core, so that's not something we can address at provider level, and that's a common issue across all providers. Have you got chance to raise it in crossplane/crossplane?

cc: @turkenh for any comment on that.

[ONordander]

I understand, I'll see if I can find any open issues in the main Crossplane repository first.
And yes, it has a random suffix in the name, so it's not predictable as far as I know.
FWIW, here's the same request for provider-aws crossplane-contrib/provider-aws#607.
Thanks again!

[turkenh]

Currently, the best solution we have is something like this: https://github.com/crossplane-contrib/provider-kubernetes/blob/main/examples/provider/config-in-cluster.yaml#L5

You can also pass an alternative SA via controller config https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/ControllerConfig/v1alpha1@v1.6.3#spec-serviceAccountName

There is also a related PR: crossplane/crossplane#2880

[ONordander]

@turkenh
crossplane/crossplane#2880 seems to be what I'm looking for, and as I understand if that is merged it will propagate to provider-kubernetes as well, if so I think we can close this.

[wwentland]

Sadly crossplane/crossplane#2880 has not been merged, so it might make sense to re-open this. It would definitely be great to have!