Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Namespaces blocklist #1677

Closed
dananichev opened this issue Jan 21, 2019 · 8 comments
Closed

Namespaces blocklist #1677

dananichev opened this issue Jan 21, 2019 · 8 comments

Comments

@dananichev
Copy link

Is there any way to blacklist namespaces? Whitelisting is quite hard thing to maintain in case you have a lot of namespaces (dynamically created/removed). Plus, only a couple of namespaces should be blacklisted (eg, kube-system, default, monitoring). And it is easier to blacklist them than to keep whitelist up-to-date.

Also, are namespaces defined in GIT's manifests monitored and updated by Flux (even if --k8s-namespace-whitelist argument present) or no?

Thanks, Dmitry

@2opremio
Copy link
Contributor

2opremio commented Jan 21, 2019

@dananichev yep, namespace whitelisting is not complete yet, and all namespaces in got are still synced regardless of the namespaces passed in the whitwlist.

Good news is that I am completing whitelisting soon, see #1668

Regarding blacklisting, it shouldn't be too hard to add a flag called --k8s-disallow-namespace after #1668

@dananichev
Copy link
Author

So basically once you finish #1668 Flux will honor new flag --kubernetes-allow-namespace while parsing and applying manifests from git's repo?

Is there any cons against RBAC usage for this purposes?
I guess, it is possible to give access to some service account to all namespaces but blacklisted via RBAC?

@2opremio
Copy link
Contributor

So basically once you finish #1668 Flux will honor new flag --kubernetes-allow-namespace while parsing and applying manifests from git's repo?

Yep

Is there any cons against RBAC usage for this purposes?
I guess, it is possible to give access to some service account to all namespaces but blacklisted via RBAC?

At the very least it will cause quite some noise in the logs.

In particular it will try to sync manifests from those manifests in git (since flux doesn't currently know better) cause errors, which may prevent manifests in legitimate namespaces from being synced (I don't know in detail how flux would react to those errors).

The same could happen when attempting to read resources from the blacklisted namespaces in k8s, possiblly preventing resources in legitimate namespaces from being read.

@squaremo mind adding your two cents?

@dananichev would you mind trying it in a test cluster?

@dananichev
Copy link
Author

dananichev commented Jan 22, 2019

@2opremio as far as i understood i can't specify namespaces restrictions for ClusterRole. Only for Role resources. But i'm not quite sure how it will affect Flux (i mean, changing ClusterRole definition to Role definition). and i don't have any testing clusters on hand sadly.

Or it would be ok to change ClusterRole to Role with namespace: some-foo-bar (and for each other namespaces something like this)?

Also i wanted to ask, why wouldn't you use Kubernetes for such parameters as --kubernetes-allow-namespace or --kubernetes-block-namespace? It would be easier to configure it via ConfigMaps without recreating Flux's POD each time.

Also also, how about some default behavior related to namespaces handling? I mean, monitor only those namespaces which described in GIT repo with manifests?

@squaremo squaremo changed the title Namespaces blacklist Namespaces blocklist Jan 22, 2019
@dananichev
Copy link
Author

With release of 1.10 and exclude domains from image metadata scanning this issue now should be considered as closed. Thanks!

@max-lobur
Copy link

So --k8s-disallow-namespace still doesn't exist?

@abisare
Copy link

abisare commented May 6, 2020

I would like to have this flag --k8s-disallow-namespace available as well. Particularly, I need flux to be able to apply changes in multiple namespaces, but it is not quite suitable to keep namespaces whitelist up-to-date

@max-lobur
Copy link

Created #3064

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

No branches or pull requests

4 participants