Configure policy.default using envronment variable

[lgatellier]

Hi,

Thanks for this promising project ! I was thinking of developing such an operator to suit my multi-tenancy needs, but this new one seems really good 😺

I'd love to be an early adopter of this project (even for some little production use cases), but I need to customize the default policy to an empty string.

Would it be possible to handle some environment variable, for example ? Thus, I'd be able to configure it directly in the operator Deployment spec using Helm.

Thanks !

[ggkhrmv]

Hi,

Thanks for this promising project ! I was thinking of developing such an operator to suit my multi-tenancy needs, but this new one seems really good 😺

I'd love to be an early adopter of this project (even for some little production use cases), but I need to customize the default policy to an empty string.

Would it be possible to handle some environment variable, for example ? Thus, I'd be able to configure it directly in the operator Deployment spec using Helm.

Thanks !

Hi Léo! Happy to hear that u like the project :)

I will look into it, but shouldn't be a difficult thing to implement, since policy.default is stored in internal/controller/common/defaults.go as a String.

You can fork and open a PR if u want to add this feature, otherwise I could look into it, and add it later on :D

[lgatellier]

These will be my very first lines of Golang, but I can give it a try.

[ggkhrmv]

These will be my very first lines of Golang, but I can give it a try.

Thank you!

Just lmk if you have any questions 😀

[ggkhrmv]

Hi @lgatellier,

looked into it, the default policy is not being set by the operator, since it's just adds policies to an already existing cm, if the CM does not exist, no policies will be created

I could add a CM to the Helm chart, but it will overwrite an already existing CM, thus deleting already existing policies

Argo CD offers a helm chart, maybe it's something u can look into or just change the default policy manually :)

[lgatellier]

Hi,

I already deploy ArgoCD using the official Helm Chart.

Thus I'm gonna have a GitOps problem :

• The argocd-rbac-cm is deployed with basic permissions by ArgoCD itself using the official Helm chart.
• The RBAC Operator will patch this ConfigMap to add some RBAC configuration from Roles and RoleBindings
• ArgoCD will change its status to OutOfSync, thus self-healing and removing policies added by the operator

I think it's a best practise to manage a resource from a single operator (ArgoCD, or RBAC Operator). So I think it would be better to completely handle the ConfigMap with the Operator (and thus set configs.rbac.create to false in the ArgoCD chart).

What do you think about it ?

[ggkhrmv]

Hi @lgatellier,

sorry i totally forgot, that you left a new comment on this issue :(

yes that is true, we would need to find a way to allow users to use both operators. we could handle the CM with the RBAC Operator, but this would mean, that the CM created by manually/by the ArgoCD Helm Chart will be overwritten, and not backward compatible.

I think we could manage the CM completely with the RBAC Operator, as soon as we support AppProjects-RBAC to not completely lock-out people wanting to use RBAC for AppProjects

[lgatellier]

Hi,

No problem for the delay, we all have many things to work on 😺

I think i'll try to use the spec.ignoreDifferences property of my ArgoCD application to ignore policy.csv file in the argocd-rbac-cm ConfigMap to avoid this problem.