Authing no longer works with multiple args passed in as a list

[geoman3]

Recent change to auth'ing with ExecProvider broke my ability to auth.

This is what my k8's config looks like:

...
- name: <cluster-name>
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - --region
      - <region>
      - eks
      - get-token
      - --cluster-name
      - <cluster-name>
      - --output
      - json
      - --role
      - <aws-role>
      command: aws
      env:
      - name: AWS_PROFILE
        value: <profile-name>
      interactiveMode: IfAvailable
      provideClusterInfo: false
...

I tested this with version 31 and 29

with version 31 I am seeing this being output in the terminal:

usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help

aws: error: the following arguments are required: command

and then when I go to make a list pods call I get a 403 error as an unknown user

And on version 29 I do not see the above output and authentication works as desired.

I believe this is due to the following change: 2dfa782

which is causing all arguments following the first one to be dropped.

https://docs.python.org/3/library/subprocess.html#frequently-used-arguments

Let me know if you need any more information. I'm not too sure on the implications this would have for Windows users

• OS: MacOS 14.4.1
• Python version: 3.11.9

Thanks

[matts-au]

I think PR #2289 broke it.

[obaranov]

Yeah, we hit the same issue while using the kubernetes.core Ansible collection. We had to revert back to the kubernetes==31.0.0.

[yliaog]

#2338

does this PR fix the issue?

[jrwren]

I can confirm and reproduce this.

I can also confirm that going back to 31.0.0 works around it.

[yliaog]

thanks, assigned the PR to you for review

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale