Regression in ExecProvider for AWS EKS Token Retrieval after adding shell=True in exec_provider introduced in commit 2dfa782

[HaimLC]

Regression in ExecProvider for AWS EKS Token Retrieval

Summary

After commit 2dfa782, our AWS EKS token retrieval command fails when running in a Docker container using Python 3.11. Previously, the same command executed without errors. The regression appears linked to using shell=True for Windows compatibility.

Details

1. What happened:

   • We run the following command arguments for the exec provider:

     ['aws', '--region', 'us-east-1', 'eks', 'get-token', '--cluster-name', 'cluster', '--output', 'json']
     

   • Under commit 2dfa782, the command fails. Debugging shows that when recreated without shell=True, it works as expected. When allowed to run as is (with shell=True), the stderr output indicates a failure.

   • Screenshot from the debugger (showing stderr, the recreation of the process, and the JSON output) is included below:

     

2. What you expected to happen:

   • The token retrieval command should run successfully, as in previous versions of the Python client.

3. How to reproduce it:

   • Use a Docker container with Python 3.11:

     FROM python:3.11
     RUN pip install kubernetes
     

   • Configure AWS EKS or manually set self.args to:

     ['aws', '--region', 'us-east-1', 'eks', 'get-token', '--cluster-name', 'cluster', '--output', 'json']
     

   • Run:

     from kubernetes import client, config as kubeconfig
     kubeconfig.load_config()
     

   • Observe that the command fails when using the latest commit that includes shell=True.

4. Environment:

   • Docker base image: python:3.11
   • Python version: 3.11
   • Kubernetes Python client version: 32.0.0
   • Relevant commit: 2dfa782

Additional Information

• The issue appears tied to the introduction of shell=True in the code, presumably for Windows support. Removing or bypassing shell=True resolves the problem in a Linux-based environment.

[roycaihw]

I think this has been fixed in 32.0.1. Please upgrade and check again.

[HaimLC]

@roycaihw can you point to the commit it has been fixed? couldn't find it in the git history

[roycaihw]

I think it's https://github.com/kubernetes-client/python/pull/2340

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.