Describe the bug
When I want to enable RBAC, but don't want the cluster role te be generated, it still does want to generate the ClusterRole
Looking at the rbac-role.yaml the first line states:
{{- if and .Values.rbac.create (eq .Values.clusterRole.create false) -}}
However, the third and fourth resource being created is a ClusterRole and ClusterRoleBinding.
I believe that is wrong, because you explicitly configured NOT to create a ClusterRole.
Yes those are needed for CRD read-only access. There is no way around this, Flux needs to know what custom resource definitions are registered in your cluster.
Yes I'm aware of that, but look at the if statement. It says specifically that when the user does not want the clusterRole to be created eq .Values.ClusterRole.create false.
However, it still does creates the ClusterRole.
Let me give some background on my issue with this.
We are running OpenShift as Kubernetes Platform. It's secure by default, so ClusterRoles can not be created by a non cluster-admin role. OpenShift uses Projects which are actually namespaces with some additional features.
I gave tiller the role of Project Admin, so it can make changes to the Project resources. But not create any Cluster specific resource like ClusterRole.
The way the statements are written in rbac-role.yaml and rbac.yaml, I will never be able to use Helm to deploy FluxCD, because I can not manually set the ClusterRole name (which I have manually created) by disabling the creation of the ClusterRole in clusterRole.create.
What I expect is when I use the next values.yaml, it does not create a UserRole but uses a UserRole which is already available.
# values.yaml
rbac:
create: true
pspEnabled: false
serviceAccount:
create: true # This is possible, because serviceAccounts are Project bound, not cluster Bound.
clusterRole:
create: false
name: my-manually-created-fluxcd-clusterrole
[update]
While writing this comment, I did some research on Authorization in Openshift. Maybe I need to disable rbac entirely in the helm chart and create those local role bindings manually in a separate script.
[update]
We currently are not focussed on deploying helm charts, but rather our own application files. So listing custom resource definitions is not yet a requirement for us. It will be in the near future.
@stefanprodan Unfortunately, i do not have a cluster admin role in on-premise cluster, only namespace-scoped admin role. As a workaround, I use my own fork with disabled cluster-scope resources, but every future upgrade will be painful. It would be great if I could explicitly disable a creation of cluster-scope resources in chart.
Yes those are needed for CRD read-only access. There is no way around this, Flux needs to know what custom resource definitions are registered in your cluster.
In my case, any cluster-scope resources will create by cluster admins manually if needed on requests.
Most helpful comment
Yes I'm aware of that, but look at the if statement. It says specifically that when the user does not want the clusterRole to be created
eq .Values.ClusterRole.create false.However, it still does creates the ClusterRole.
Let me give some background on my issue with this.
We are running OpenShift as Kubernetes Platform. It's secure by default, so ClusterRoles can not be created by a non cluster-admin role. OpenShift uses Projects which are actually namespaces with some additional features.
I gave tiller the role of Project Admin, so it can make changes to the Project resources. But not create any Cluster specific resource like ClusterRole.
The way the statements are written in
rbac-role.yamlandrbac.yaml, I will never be able to use Helm to deploy FluxCD, because I can not manually set the ClusterRole name (which I have manually created) by disabling the creation of the ClusterRole inclusterRole.create.What I expect is when I use the next
values.yaml, it does not create a UserRole but uses a UserRole which is already available.[update]
While writing this comment, I did some research on Authorization in Openshift. Maybe I need to disable rbac entirely in the helm chart and create those local role bindings manually in a separate script.
[update]
We currently are not focussed on deploying helm charts, but rather our own application files. So listing custom resource definitions is not yet a requirement for us. It will be in the near future.