- 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
If a bearer token is present in a request, the exec credential plugin should accept that as the chosen method of authentication. Judging by an [earlier comment in exec.go](c18bc7e9f7/staging/src/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go (L217)), this was already intended. This would however not work since UpdateTransportConfig would set the GetCert callback which would then get called by the transport, triggering the exec plugin action even with a token present in the request. See linked issue for further details.
See #87369 for further details.
Signed-off-by: Anders Eknert <anders.eknert@bisnode.com>
Kubernetes-commit: b423216a3b781009fb4ec4d5974eeb3f882f9d2d
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
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
Properly wrapping a transport can be tricky. Make the normal case
(adding a non-nil transport wrapper to a config) easier with a helper.
Also enforce a rough ordering, which in the future we can use to
simplify the WrapTransport mechanism down into an array of functions
we execute in order and avoid wrapping altogether.
Kubernetes-commit: 1f590e697ef64812620c787720b4b5942027e4a1
- 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
Instead of Transport. This fixes ExecPlugin, which fails if
restclient.Config.Transport is set.
Kubernetes-commit: 3357b5ecf42db9bcf6e54c9d2b6712cfbae077bf
