You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{"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"}
The text was updated successfully, but these errors were encountered:
As stated here, #105 (comment): 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
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.
Get fails:
Create fails:
The text was updated successfully, but these errors were encountered: