This commit adds the ability for users to specify an install hint for
their exec credential provider binary.
In the exec credential provider workflow, if the exec credential binary
does not exist, then the user will see some sort of ugly
exec: exec: "does-not-exist": executable file not found in $PATH
error message. If some user downloads a kubeconfig from somewhere, they
may not know that kubectl is trying to use a binary to obtain
credentials to auth to the API, and scratch their head when they see
this error message. Furthermore, even if a user does know that their
kubeconfig is trying to run a binary, they might not know how to obtain
the binary. This install hint seeks to ease the above 2 user pains.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Kubernetes-commit: 94e2065df2eef3b198942efb156ef6e27abcc6f9
With support of http, https, and socks5 proxy support. We already
support configuring this via environmnet variables, but this approach
becomes inconvenient dealing with multiple clusters on different
networks, that require different proxies to connect to. Most solutions
require wrapping clients (like kubectl) in bash scripts.
Part of: https://github.com/kubernetes/client-go/issues/351
Kubernetes-commit: f3f666d5f1f6f74a8c948a5c64af993696178244
* Kubectl user exec should accept zero-length environment values #652
* Changing TestValidateAuthInfoExecInvalidEnv to allow for empty strings as Exec values
Kubernetes-commit: f30af9dd6da46f0f01e38b477d455907da9f1b6c
* Added custom error message when wrong file is provided with KUBECONFIG
* Modified test case
* Updated the code to warn the missing files
* Renamed the variable
Kubernetes-commit: a5eedcde611658c220c56d2819bf0420aded4ed6
An example of incorrect log message:
{
"component":"virtctl",
"level":"info",
"msg":"Config loaded from fileocp/auth/kubeconfig",
"pos":"loader.go:359",
"timestamp":"2019-03-07T18:50:20.923470Z"
}
Note how the resulting message has no characters between the text and
file name.
Kubernetes-commit: 65fb63a15473589f615bdfeb2f35e56414050f94
It's very easy to add glog.Info(config) calls for debugging (or actual
logging). In some scenarios those configs will carry sensitive tokens
and those tokens will end up in logs or response bodies.
Leaking of those stringified configs compromises the cluster.
Also implement fmt.GoStringer.
Kubernetes-commit: c9ad1d7339b164dfba0846ec49fa4a52474d3e23
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
Kubernetes-commit: 954996e231074dc7429f7be1256a579bedd8344c
Adding blank line between comment tag and package name in doc.go. So
that the comment tags such as '+k8s:deepcopy-gen=package' do not show up
in GoDoc.
Kubernetes-commit: 61117761cd4a1b2e6ad9ff2d7eb915f3d2739dc6
Trades runtime complexity for spacial complexity when modifying
large amounts of contexts on a kubeconfig.
In cases where there are few destination filenames for a given
amount of contexts, but a large amount of contexts, this patch
prevents reading and writing to the same file (or small number
of files) over and over again needlessly.
Kubernetes-commit: d5651948cf1a14ed284b4708e2057e4cbc72bcbe
These constants will never change, and tools/ should not be depending on
core/api/v1 (there is nothing v1 specific about them).
Kubernetes-commit: aa9fd2bf11ae6be922b5b0fe45f5254c40366b2e
