open-feature / open-feature-operator

A Kubernetes feature flag operator
https://openfeature.dev
Apache License 2.0
181 stars 35 forks source link

Helm installation broken #651

Closed toddbaert closed 4 months ago

toddbaert commented 4 months ago

Helm installation is not working due to the recently added overlays removing rules from the open-feature-operator-manager-role. The operator is now not able to read openfeature.dev/* custom resources when installed with Helm:

failed to list *v │
│ 1beta1.InProcessConfiguration: inprocessconfigurations.core.openfeature.dev is forbidden: User "system:serviceaccount:open-featur │
│ e-operator-system:open-feature-operator-controller-manager" cannot list resource "inprocessconfigurations" in API group "core.ope │
│ nfeature.dev" at the cluster scope

image

toddbaert commented 4 months ago

@thisthat @bacherfl When I checked the output charts in https://github.com/open-feature/open-feature-operator/pull/647, the role-binding looked fine, but I never checked the role which is now more messed up :sweat_smile:

I will see how far I can get with this, but I wonder if we should change the patch to not be a delete and instead add the additional rules we need for ingress creation?

toddbaert commented 4 months ago

I started down the path of maintaining 2 roles and 2 rolebindings, one that controls the extra stuff we need when managerConfig.flagdResourceEnabled is enabled, but after running through some proposed tutorials and dealing with this additional complexity, I honestly think the entire idea of managerConfig.flagdResourceEnabled is not worth it. My reasoning is that it's easy to restrict the creation of flagd CR instances entirely (or instances with ingresses) through many different tools and policies, since these are not created automatically by annotations. I just don't think we need to control them at the OFO install level.

Sorry @bacherfl for the wasted time here, since this was initially my idea. :pensive: