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

whitelisting suggestion #5

Open
haithkris opened this issue Aug 17, 2017 · 6 comments
Open

whitelisting suggestion #5

haithkris opened this issue Aug 17, 2017 · 6 comments

Comments

@haithkris
Copy link

Is there a possibility to add a whitelist to the kube monkey configuration? It could be exclusive with blacklisting. You either do the first or the second one. I find whitelisting better to deal with if you manage a lot of namespaces.

Thank you

@asobti
Copy link
Owner

asobti commented Aug 17, 2017

Are you thinking of a scenario where all deployments within the whitelisted namespaces will be enrolled into Kube monkey? We'd have to figure out a way to specify parameters like MTBF etc. in this case.

An alternative way to do that would be instead of opting in deployments, maybe there could be an option to opt-in namespaces instead (by adding the kubernetes labels to them).

In either case, this isn't something that is currently supported. I'll try to take a look, but PRs are also welcome.

@EIrwin
Copy link

EIrwin commented Aug 25, 2017

We too had discussed the preference of configuring opt-in vs opt-out. The cluster we would like to run this on has feature namespaces provisioned sometimes on daily basis in which case, we likely would not want to disturb those. This would also require us to constantly update the blacklisting of namespaces, versus explicitly saying which namespaces to run it against. I might look into branching off and making it configurable.

@asobti
Copy link
Owner

asobti commented Aug 30, 2017

@EIrwin I'm all for having an opt-in option. I just haven't figured out the best way to handle configurations like MTBF etc in this case. Perhaps we could use a system where you globally set the mode to opt-in and specify some global value for MTBF. individual deployments can then override this value.

I'll take a look at this but if you do end up forking and implementing this, do ping me and I'll take a look at it.

@EIrwin
Copy link

EIrwin commented Aug 30, 2017

@asobti that was similar to the approach I have started implementing. The first iteration could simply use a opt-in bool along with a global MTBF to be used. In later iteration(s), this could be extended to allow individual deployments to override this value.

@asobti
Copy link
Owner

asobti commented Aug 30, 2017

Sounds good. I'll hold off on working on this for now in that case so we're not repeating the same work.

@janwillies
Copy link

Facing the same use-case. We have a shared cluster and there's no way for us to know all the namespaces to blacklist.

Maybe another idea is to have kube-monkey run per namespace? Or limit via RBAC rules?

@Aergonus Aergonus mentioned this issue Jan 3, 2018
asobti pushed a commit that referenced this issue Jan 24, 2018
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

4 participants