kubectl apply --dry-run=client attempts to connect to the server

mjj29 commented 5 months ago

What happened?

I have an environment which doesn't have server credentials for security reasons for running PR checks on our gitops repository (post-merge actual application has a separate environment with credentials). I would like to do a dry-run check on the validity of the configuration in the PR, without having cluster credentials.

When I ran kubectl apply -f output --dry-run=client it prompted for connection details and failed

What did you expect to happen?

I expected --dry-run=client not to connect to the server

How can we reproduce it (as minimally and precisely as possible)?

Create a kubeconfig with an empty connection token for your server (or no details at all)
Run kubectl --kubeconfig=kubeconfig --dry-run=client apply -f output
kubectl will prompt for username and password (or if you don't have server details, attempt to connect to localhost:8080 and fail)

Anything else we need to know?

No response

Kubernetes version

I'm using 1.26.14, but I also tested with 1.30.0

Cloud provider

n/a

OS version

Linux RHEL8

Install tools

Container runtime (CRI) and version (if applicable)

Related plugins (CNI, CSI, ...) and versions (if applicable)

k8s-ci-robot commented 5 months ago

There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:

/sig <group-name>
/wg <group-name>
/committee <group-name>

Please see the group list for a listing of the SIGs, working groups, and committees available.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

k8s-ci-robot commented 5 months ago

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

sftim commented 5 months ago

/remove-kind bug /kind support

AIUI: kubectl needs to know the API definition(s) for your cluster in order to do a client side dry run. I don't think we can avoid that but we could document why it happens.

mjj29 commented 5 months ago

Well then it's not really a client side validation is it. Is there any kind of validation I can do without giving pre approval PRs cluster credentials?

sftim commented 5 months ago

There's a better home for this request. /transfer kubectl

ardaguclu commented 5 months ago

/remove-kind support /kind feature

Yes it is known that dry-run=client still requires to access to cluster (see more: https://github.com/kubernetes/kubernetes/pull/123337#discussion_r1505855167). /triage accepted /priority backlog

ardaguclu commented 5 months ago

/sig cli

kubernetes / kubectl