If configuration object is used concurrently
it is not safe to mutate self.
There is no need for mutation so avoid it
just in case.
Kubernetes-commit: 9e360eb05efafd0fcabd5a065b62cb8226da94c2
- The main idea here is that we want to 1) prevent potentially large CA
bundles from being set in an exec plugin's environment and 2) ensure
that the exec plugin is getting everything it needs in order to talk to
a cluster.
- Avoid breaking existing manual declarations of rest.Config instances by
moving exec Cluster to kubeconfig internal type.
- Use client.authentication.k8s.io/exec to qualify exec cluster extension.
- Deep copy the exec Cluster.Config when we copy a rest.Config.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Kubernetes-commit: c4299d15d5289768808034676858e76a177eeae5
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
