You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, plugins will pull pods and services at the cluster scope and then prune them against namespace-limiting options (-i|--include-namespace and -n|--exclude-namespace). This assumes that the pod running the check can read resources at the cluster scope, preventing multi-tenant cluster users from running their own per-namespace clients (well, without doling out overly-generous RBAC perms, that is). A few possible options:
Modify --include-namespace to explicitly pull resources from the provided namespace(s) individually, rather than pulling cluster-wide and then pruning.
Add a flag specifying cluster-wide vs namespaced usage. Examples:
--cluster-wide=<bool> (true by default)
--namespaced=<bool> (false by default)
Add a --namespace [NS] option to specify the namespace in which to operate. Perhaps the argument could be optional, with the current namespace used when not specified.
I am happy to perform this work, although input on a preferred route would be appreciated.
The text was updated successfully, but these errors were encountered:
Currently, plugins will pull pods and services at the cluster scope and then prune them against namespace-limiting options (
-i|--include-namespace
and-n|--exclude-namespace
). This assumes that the pod running the check can read resources at the cluster scope, preventing multi-tenant cluster users from running their own per-namespace clients (well, without doling out overly-generous RBAC perms, that is). A few possible options:--include-namespace
to explicitly pull resources from the provided namespace(s) individually, rather than pulling cluster-wide and then pruning.--cluster-wide=<bool>
(true
by default)--namespaced=<bool>
(false
by default)--namespace [NS]
option to specify the namespace in which to operate. Perhaps the argument could be optional, with the current namespace used when not specified.I am happy to perform this work, although input on a preferred route would be appreciated.
The text was updated successfully, but these errors were encountered: