Feat add startup error when running in kube system#1031
Feat add startup error when running in kube system#1031LucasRoesler wants to merge 1 commit intoopenfaas:masterfrom
Conversation
|
Thank you for your contribution. unfortunately, one or more of your commits are missing the required "Signed-off-by:" statement. Signing off is part of the Developer Certificate of Origin (DCO) which is used by this project. Read the DCO and project contributing guide carefully, and amend your commits using the git CLI. Note that this does not require any cryptography, keys or special steps to be taken. 💡 Shall we fix this?This will only take a few moments. First, clone your fork and checkout this branch using the git CLI. Next, set up your real name and email address:
Finally, run one of these commands to add the "Signed-off-by" line to your commits. If you only have one commit so far then run: Check that the message has been added properly by running "git log". |
To avoid any accedential security issues, we block running anything in the kube-system namespace. We already have this explicitly blocked in the rest of the code that deals with namespaces and it causes hard to debug errors for users that try to deploy to the kube-system namespace. This adds an explicit check so that this mis-configuration is easier to detect and debug for end users. Signed-off-by: Lucas Roesler <[email protected]>
LucasRoesler
force-pushed
the
feat-add-startup-error-when-running-in-kube-system
branch
from
b3556c1 to
1aa19ec
Compare
|
|
||
| // use kubeclient to check the current namespace | ||
| namespace, _ := k8s.CurrentNamespace() | ||
| if namespace == "kube-system" { |
There was a problem hiding this comment.
This isn't quite the error we were running into.
You probably can run the openfaas core components in the kube-system namespace.
It was that you can't deploy functions there.
So we already have validation in the deployment handlers, but we could do better by checking the functionNamespace variable (if set), and exiting upon startup
There was a problem hiding this comment.
i thought this was part of the suggestion #1022 (comment)
but i see that what we also need to do is provide a meaningful api error as well
| // This implementation is based on the clientcmd.inClusterClientConfig.Namespace method. | ||
| // This is not exported and not accessible via other methods, so we have to copy it. | ||
| func CurrentNamespace() (namespace string, found bool) { | ||
| if ns := os.Getenv("POD_NAMESPACE"); ns != "" { |
There was a problem hiding this comment.
That is a pretty nice trick. TIL
Although please see my other *comment (typo)
2 participants
Description
To avoid any accedential security issues, we block running anything in
the kube-system namespace. We already have this explicitly blocked in
the rest of the code that deals with namespaces and it causes hard to
debug errors for users that try to deploy to the kube-system namespace.
This adds an explicit check so that this misconfiguration is easier to
detect and debug for end users.
Motivation and Context
Part of a comment on #1022
How Has This Been Tested?
Types of changes
Checklist:
git commit -s