Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Configure policy.default using envronment variable #12

Open
lgatellier opened this issue Nov 14, 2024 · 5 comments
Open

Configure policy.default using envronment variable #12

lgatellier opened this issue Nov 14, 2024 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@lgatellier
Copy link

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
Copy link
Collaborator

ggkhrmv commented Nov 14, 2024

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
Copy link
Author

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

@ggkhrmv
Copy link
Collaborator

ggkhrmv commented Nov 17, 2024

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 ggkhrmv self-assigned this Dec 12, 2024
@ggkhrmv ggkhrmv added the enhancement New feature or request label Dec 12, 2024
@ggkhrmv
Copy link
Collaborator

ggkhrmv commented Jan 3, 2025

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
Copy link
Author

lgatellier commented Jan 16, 2025

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 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants