composable manager has no rights to view or create resources

[lhriley]

Get fails:

{"level":"error","ts":1677612553.3451736,"logger":"controller.composable","msg":"Reconciler error","reconciler group":"ibmcloud.ibm.com","reconciler kind":"Composable","name":"foo","namespace":"default","error":"redisinstances.redis.cnrm.cloud.google.com \"foo\" is forbidden: User \"system:serviceaccount:composable-system:composable-controller-manager\" cannot get resource \"redisinstances\" in API group \"redis.cnrm.cloud.google.com\" in the namespace \"default\", Error finding an object reference","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227"}

Create fails:

{"level":"error","ts":1677615673.8247418,"logger":"controller.composable","msg":"Reconciler error","reconciler group":"ibmcloud.ibm.com","reconciler kind":"Composable","name":"foo","namespace":"default","error":"services is forbidden: User \"system:serviceaccount:composable-system:composable-controller-manager\" cannot create resource \"services\" in API group \"\" in the namespace \"default\"","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227"}

[xvzf]

Hey @lhriley

First of all, thx a lot for your contributions!

As stated here, https://github.com/composable-operator/composable/pull/105#discussion_r1162689898: Opening up the access for composable-operator introduces quite a few side-channel attack vectors, limiting the security of the cluster.

I'd suggest we introduce a new kustomize target, that patches in cluster wide access, so it's an explicit choice by the user rather than an implicit catch-all

[lhriley]

I think that's a fair proposal. I mentioned in my reply on the PR comment about a middle ground "opt-in" approach where the end user can make the decision via values.yaml rather than have to incorporate kustomize into a workflow when they might not be using it already.