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

Enhancement: Global Catalog of Resources #25

Open
nheimlich opened this issue Mar 17, 2021 · 3 comments
Open

Enhancement: Global Catalog of Resources #25

nheimlich opened this issue Mar 17, 2021 · 3 comments

Comments

@nheimlich
Copy link

nheimlich commented Mar 17, 2021

Post in Discourse

When managing 30+ namespaces with sensu flow, it would be nice to utilize the default namespace as a global namespace where checks, filters, handlers, and mutators can live and be called from entities from within other namespaces.

Ideal Scenario:
Suppose a check has the same name and lives in the same directory. That check will take precedence over the check from the default namespace. The catalog of checks, handlers, mutators, & filters resides in the default namespace and is version controlled with sensu flow, and a change to the catalog affects all namespaces.

Current Scenario:
Currently, copying and managing versioning between checks that are often duplicates can be difficult to manage.

Not sure if this is a sensu flow or sensu go feature request as the checks wouldn't be just copied to each namespace, instead placed in the default namespace.

This is similar to issue 23, however, that is copying resources, whereas this is not.

*Potentially an opt-in parameter that can be set within the sensu-backend on each cluster node.

@calebhailey
Copy link

Do you want to keep these resources synchronized every time you make changes (e.g. if you update a resource in the "source" namespace should those changes cascade across the entire cluster), or only use them to "seed" new namespaces? I've been thinking that the latter should be supported by Sensu Go proper and we're having some internal discussions about this.

In the interim, I recently setup a demo where I have a set of resources that I want to exist in every namespace and I basically set it up in a way that's not too dissimilar to what we're doing in sensu-flow. I think it makes sense for us to figure out how to support this in sensu-flow until we have a first-class solution for "namespace seeding" in Sensu Go. And even if/when we do support namespace seeding in Sensu Go, if what you really want is to keep these resources updated across the cluster, we ought to be able to facilitate that in sensu-flow.

@nheimlich
Copy link
Author

Hi, @calebhailey sorry for the delay; from internal discussions and personal experience, I believe implementing the first option where resources are synchronized regardless of namespace creation time should be eventually supported. I currently have a basic script that deletes all current checks and copies all check files from our local catalog to each namespace. Those changes are replicated in each namespace, reducing the number of unique checks we currently have. If we have custom checks, I created a "custom" folder in each namespace checks folder that is excluded from my script.

@jspaleta
Copy link
Contributor

jspaleta commented Jun 3, 2022

Doing this inside the sensu backend itself would be very very tricky because of the RBAC policy ramifications. We'd have to be careful about that. If someone with only read access to namespace A resources, used the web-ui to look at what was going on.. would they be able to see the checks inherited from the global namespace? There would be a lot of ways you could misconfigure RBAC interaction with a global default namespace. We may need enforce specific RBAC policy rules when a global default is enabled, reasoning the admin who enabled it intended to allow read access to everyone in the system to the global namespace.

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

No branches or pull requests

3 participants