Port exec-based client auth provider to Python client

[dbenhur]

With 1.10, this exec-based client auth credential provider alpha feature was introduced kubernetes/features#541 for client-go. Exec-based auth plugin should be supported by this Python client in addition to client-go. Umbrella issue: kubernetes#62185

/kind feature
/sig api-machinery

[roycaihw]

Link to the credential plugin feature: https://kubernetes.io/docs/admin/authentication#client-go-credential-plugins
Design proposal: https://github.com/ericchiang/community/blob/2bfa7e1e624a5c87cbd1d07566e617563e2280fd/contributors/design-proposals/auth/kubectl-exec-plugins.md

The feature is in alpha state which means the API may change and support may be dropped in future. Python client auth is happening in kubeconfig loader class in python base repo: https://github.com/kubernetes-client/python-base/tree/master/config.

cc @Lawouach

[jasonkriss]

With AWS EKS going GA, this seems to be a pretty important feature. @dbenhur any chance you guys are already working on this? It's currently blocking us from moving to EKS.

[palnabarun]

Hi, Can the client communicate with EKS clusters at this point of time?

[naumvd95]

Subscribe and hope , that this feature will be implemented asap) ill try to investigate it by myself and do my best in help-offer

[fillbit]

Hi,

I am looking for this feature as well. Is anyone working on it? I'm willing to do work on it if not.

Phil

[dovreshef]

Hi

I've implemented it here: kubernetes-client/python-base#75.

[qubusp]

experiencing the same thing

import boto3 
import simplejson as json 
from base64 import b64decode
from kubernetes import client, config
from pprint import pprint
ecr = boto3.client('ecr',
    region_name='eu-central-1'
)


response = ecr.get_authorization_token()
raw_data=response['authorizationData'][0]['authorizationToken']
user, decoded_data=b64decode(raw_data).decode('UTF-8').split(":")


config.load_kube_config()
v1 = client.CoreV1Api()
namespace = 'default'
metadata = {'name': 'aws-login', 'namespace': 'dev'}
data = {'user': 'AWS', 'token': decoded_data}
api_version = 'v1'
kind = 'Secret'
body = client.V1Secret(api_version, data , kind, metadata, type='kubernetes.io/tls')
api_response = v1.create_namespaced_secret(namespace, body, async=True)
pprint(api_response)

The result is bad request 400. There is only one context on the machine.

[willthames]

A release that includes #619 should fix this

[jw-maynard]

Any plans for a release that includes this fix?

[roycaihw]

@jw-maynard We usually align the python client release with main kubernetes release. The python client v8 release procedure will start after kubernetes 1.12.0 is cut.

[jw-maynard]

@roycaihw Cool, this is currently a blocker to getting our tooling working with EKS. I was hoping to you guys could do something like a 7.0.1 release that adds this feature since it's v1beta1 in 1.11. If not, do you know the rough time frame for 1.12 and then getting a release of the client from that? Thanks!

[alexandraj777]

@roycaihw I'd be interested in learning how I can get notified about releases of this client!

@jw-maynard I don't know if this is helpful, but we've written a python package that uses EKS, and our current solution is to have a wrapper class that calls kubectl from subprocess. Every subprocess call looks something like:

subprocess.Popen(
  pargs=['kubectl', ...],
  env=dict(KUBECONFIG=<config_file_path>, PATH=<path_to_kubectl>),
  ...
)

It's not the prettiest, but it works for now. We're planning to swap out the subprocess code for the python client once EKS is supported 😄

[roycaihw]

@jw-maynard Currently the planned date for 1.12.0 cut is Sep. 27th. Ideally I'd like to do an 8.0.0a1 release on Sep. 28th.

@alexandraj777 We send announcements about python client releases to kubernetes-dev mailing list. You could join the google group via https://groups.google.com/forum/#!forum/kubernetes-dev

[jw-maynard]

@roycaihw Awesome! I think we can just wait for that.

@alexandraj777 Thanks! Trying to avoid wrapping kubectl if we can but if push comes to shove this will definitely help.

[jw-maynard]

@roycaihw Hey, just wondering if you guys were hoping to get an 8.0.0a1 build out sometime this week? Thanks!

[roycaihw]

Yes, we've generated the client and collected release notes last Friday #631. Hopefully we will push the release to pypi today :)

[roycaihw]

Hi folks, the 8.0.0a1 release has been uploaded to pypi https://pypi.org/project/kubernetes/8.0.0a1/. I will create a github release page and send a notification to kubernetes-dev mailing list shortly. Thanks for your patience, and please give it a try and file any issue to let us know :)

Closing this issue as the feature has been released in 8.0.0a1...

[Lawouach]

You folks rock!

[nakulpathak3]

Hi I'm using the 8.0.0a1 issue and I'm doing

api_client = config.new_client_from_config(kube_config_yaml_file)
v1_core = client.CoreV1Api(api_client)

and this seems to pass almost always but every now and then I get an error from the python client

ERROR:root:exec: process returned 1. could not get token: AccessDenied: Access denied
	status code: 403, request id: 296d0777-de24-12b8-b352-c942b2ac475e

which seems to be getting triggered here in the exec_provider in python-base.
The main change that I could think of it being is that I'm using the -r flag and passing in an access role to use with the authenticator command which I don't see a test for in the exec_provider. Even with the flag the command passes sometimes but fails at other times.

When I try to use the same kubeconfig file with kubectl, it works though.

I'm using EKS with aws-iam-authenticator.

Update: Opened an issue #678.