Question: Extending RBAC permissions to other CRDs

[bobh66]

Is there a recommended way to extend RBAC permissions for the provider to other CRDs in the local cluster?

I have some custom resources that are not accessible by the default provider service account due to RBAC, and since the default service account and cluster role are generated it's not possible to automatically provision access to those CRDs for the generated SA.

I can create a Service Account for the provider to use and give it the right permissions, but I'm hoping there's a more elegant solution.

Thanks

[bobh66]

@muvaf suggested creating a ServiceAccount with the desired permissions attached and generate a kubeconfig/secret for a ProviderConfig dedicated to that resource set, which can be used when any of those resources need to be created by provider-kubernetes. I'll give that a try, I suspect I'll need to observe the ServiceAccount to find the secret and then observe the secret to get the token, so I can create the target kubeconfig.

[turkenh]

@bobh66 yes, you can either define a new service account with enough permissions and pass it to the provider using controller config or you can grab existing SA for an installed provider-kubernetes and bind further permissions like here.

[bobh66]

Thanks @turkenh - the problem with creating my own service account for the provider is then I have to maintain all RBAC permissions for the provider going forward, which I would rather leave to to Crossplane. My goal is to automate the deployment of Crossplane + provider-kubernetes + my custom CRDs, and automatically bind the right permissions to the provider SA. The existing provider-kubernetes SA would work if the name was constant across provider versions but since each version generates a new hash and new SA name, the automation doesn't know the SA name to bind the custom permissions to. Fortunately the hash appears to be the same for all deployments of the same version of the provider, so for now I can hard-code the SA name with the hash associated with the current version of provider-kubernetes, and when we bump the version we can update the hash at the same time.

Role aggregation would solve the problem but I understand that this issue is specific to provider-kubernetes and it doesn't make sense to add role aggregation just for this one provider.

[chlunde]

Did you see this?

apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
...
  name: kubernetes-config
spec:
...
  serviceAccountName: crossplane-provider-kubernetes

[bennesp]

@chlunde since ControllerConfig is now deprecated, do you have any other suggestion on how we should address this problem?

I would like to define everything in a declarative manner to enable a git-ops approach, and this issue is a real concern for me. Is probably https://github.com/crossplane/crossplane/pull/2015 supposed to allow providers to ask for permissions? Should this be implemented by provider-kubernetes?

For now I have the following which seems to me to be too verbose for a simple provider installation, but that's just my thought

apiVersion: v1
kind: ServiceAccount
metadata:
  name: crossplane-provider-kubernetes
  namespace: crossplane-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: crossplane-provider-kubernetes
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: crossplane-provider-kubernetes
    namespace: crossplane-system
---
# Deprecated. See https://github.com/crossplane/crossplane/issues/3601
apiVersion: pkg.crossplane.io/v1alpha1
kind: ControllerConfig
metadata:
  name: provider-kubernetes
spec:
  serviceAccountName: crossplane-provider-kubernetes
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-kubernetes
spec:
  package: "crossplane/provider-kubernetes:main"
  controllerConfigRef:
    name: provider-kubernetes
---
apiVersion: kubernetes.crossplane.io/v1alpha1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: InjectedIdentity