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 #2340