Changed to have to specify namespace and context.#3
Changed to have to specify namespace and context.#3ykwyuta wants to merge 2 commits intotdihp:masterfrom
Conversation
|
Hi @ykwyuta , thanks for sending this PR! I think supporting namespace is great, , and it is good to also include context, however I'd prefer to have a default value for both, so it always easily work for simpler situations. Do you think it works for you to have a default following example of projects such as helm? Helm supports --namespace and --kube-context including many other configurations, but always follow the implicit pattern that the current kubectl context does if none is supplied. I'd be happy to make improvement into this direction. |
|
My apologies @ykwyuta , I didn't check this PR after you made change. I'll check and update. |
|
I'd prefer that dspcap has a default value and follows to current context of kubectl by default.
Using the method @tdihp suggested, we can easily achieve both using default values and using explicit options when run command. # Specify namespace explicitly when run dspcap
./dspcap-start --namespace={NAMESPACE}
./dspcap-stop --namespace={NAMESPACE}
# Using default values (following current context)
kubectl config set-context {CONTEXT} --namespace={NAMESPACE}
./dspcap-start
./dspcap-stopThis method is flexible. We can also use other options defined by # Specify kubeconfig file
./dspcap-start --kubeconfig=/path/to/kubeconfig
./dspcap-stop --kubeconfig=/path/to/kubeconfig |
I want you to make it mandatory to specify the namespace and context.
I find it very dangerous to run a script whose namespace and context are not named. We operate hundreds of Kubernetes clusters on our system, and without explicit context, operators run the risk of accidentally capturing packets in different environments. You may also not be able to deploy privileged containers in the default namespace on clusters that have Pod Security Standards applied.