- Run hack/update-codegen.sh
- Run hack/update-generated-device-plugin.sh
- Run hack/update-generated-protobuf.sh
- Run hack/update-generated-runtime.sh
- Run hack/update-generated-swagger-docs.sh
- Run hack/update-openapi-spec.sh
- Run hack/update-gofmt.sh
Replay of a9593d634c6a053848413e600dadbf974627515f
Kubernetes-commit: 15d9d196476d64482189f00f1cf1a2061aea5b35
This change updates the transport.Config .Dial and .TLS.GetCert fields
to use a struct wrapper. This indirection via a pointer allows the
functions to be compared and thus makes them valid to use as map keys.
This change is then leveraged by the existing global exec auth and TLS
config caches to return the same authenticator and TLS config even when
distinct but identical rest configs were used to create distinct
clientsets.
Signed-off-by: Monis Khan <mok@microsoft.com>
Kubernetes-commit: e3bffcd28922b24e54cc89c4356c2dc16e778e67
- Also update test-cmd.sh to pass a signing ca to the kube controller
manager, so CSRs work properly in integration tests.
Signed-off-by: Margo Crawford <margaretc@vmware.com>
Kubernetes-commit: f015fd66ce95d02cd66efc263eb9e5441b42a17d
These were missed because our tests did not pass in the correct test
data input (the command to execute).
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: a6ac42082b4d7c0057b52900736bd7fbc2c44241
With the client-go credential plugin functionality going GA in 1.22,
it is now time to deprecate these legacy integrations.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: 6bfaeaf91658835aeea267500299de1c4a35a248
The value here is that the exec plugin author can use the kubeconfig to assert
how standard input is treated with respect to the exec plugin, e.g.,
- an exec plugin author can ensure that kubectl fails if it cannot provide
standard input to an exec plugin that needs it (Always)
- an exec plugin author can ensure that an client-go process will still call an
exec plugin that prefers standard input even if standard input is not
available (IfAvailable)
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Kubernetes-commit: cd83d89ac94c5b61fdd38840098e7223e5af0d34
If a user specifies basic auth, then apply the same short circuit logic
that we do for bearer tokens (see comment).
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Kubernetes-commit: 9dee2b95c27a9d61c2bade8fe67f120b5853c4d6
Whether `providerless` is present or not, the OIDC plugin
should be available.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
Kubernetes-commit: b1e9fc4935e60092b4823bd67e82c4d2bfb1a7fc
We are not sure why this was stdout, since stdin is what the user uses to pass
information to the exec plugin.
There is a question of backwards compatibility here. Our take is that this is a
bug, and so we are ameliorating behavior instead of breaking behavior. There are
2 main cases to consider with respect to backwards compatibility:
1. an existing exec plugin depended on stdin being hooked up to them if stdout
was a terminal (e.g., echo foo | client-go-command-line-tool); we believe
this is an anti-pattern, since the client-go-command-line-tool could be using
stdin elsewhere (e.g., echo foo | kubectl apply -f -)
2. an existing exec plugin depended on stdin not being hooked up to them if
stdout was not a terminal (e.g., client-go-command-line-tool >/dev/null);
hopefully there are very few plugins that have tried to base logic off of
whether stdin returned EOF immediately, since this could also happen when
something else is wrong with stdin
We hope to apply a stronger fix to this exec plugin user interaction stuff in a
future release.
Signed-off-by: Andrew Keesler <akeesler@vmware.com>
Kubernetes-commit: aea995c45ff057406b586144e28bd9575162b8df
Errors from staticcheck:
cmd/preferredimports/preferredimports.go:38:2:
package golang.org/x/crypto/ssh/terminal is deprecated:
this package moved to golang.org/x/term. (SA1019)
vendor/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go:36:2:
package golang.org/x/crypto/ssh/terminal is deprecated:
this package moved to golang.org/x/term. (SA1019)
vendor/k8s.io/client-go/tools/clientcmd/auth_loaders.go:26:2:
package golang.org/x/crypto/ssh/terminal is deprecated:
this package moved to golang.org/x/term. (SA1019)
Please review the above warnings. You can test via:
hack/verify-staticcheck.sh <failing package>
If the above warnings do not make sense, you can exempt the line or
file. See:
https://staticcheck.io/docs/#ignoring-problems
generated:
- hack/update-internal-modules.sh
- hack/lint-dependencies.sh
- hack/update-vendor.sh
Signed-off-by: Stephen Augustus <foo@auggie.dev>
Kubernetes-commit: d9435800b65d6787beaf061546599d757b8e87c9
- 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
The openstack auth plugin was deprecated in v1.11 in favor of the
"client-keystone-auth" credential plugin. This change removes the
plugin in v1.19 (eight releases seems more than sufficient notice).
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: 0beb8ea0fef3556474b3a713a2203d4edbbb4fc2
This reverts commit d1480ab49d603d0a95e509b627252ee7af8559ae.
Revert this commit due to incomplete migration path
Kubernetes-commit: 71b2a4cdcc18694387961d119c6ab71772579918
This change includes the cluster address in the cache key so that
using the same issuer and client ID with different tokens across
multiple clusters does not result in the wrong token being used for
authentication.
Signed-off-by: Monis Khan <mok@vmware.com>
Kubernetes-commit: 96fe76a9ed4fde16f449995cc698dca3719ed546
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
