Enable oidc auth

[dmyerscough]

No description provided.

[mbohlool]

To pass tests, you need a PR in the main repo with only adding dependency (not updating /base submodule).

[mbohlool]

look like there is only formatting issues with test: https://travis-ci.org/kubernetes-client/python-base/jobs/270071663

Sorry that I didn't spend time on this yet because of the rush of PRs before kubernetes code freeze. I will do a proper review very soon.

[codecov-io]

Codecov Report

Merging #31 into master will decrease coverage by 2.27%.
The diff coverage is 50.98%.

@@            Coverage Diff             @@
##           master      #31      +/-   ##
==========================================
- Coverage   93.93%   91.65%   -2.28%     
==========================================
  Files          11       11              
  Lines         824      875      +51     
==========================================
+ Hits          774      802      +28     
- Misses         50       73      +23

Impacted Files	Coverage Δ
config/kube_config_test.py	92.64% <100%> (+0.15%)	⬆️
config/kube_config.py	84.4% <44.44%> (-8.78%)	⬇️
config/dateutil.py	93.33% <0%> (+4.44%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 84d1284...e62a87a. Read the comment docs.

[dmyerscough]

Thanks @mbohlool Ill write some unit tests this week or next (time depending).

[mbohlool]

any update on this? also did you test this? e.g. is there a minikube way to setup oidc and test this? or what flavor of kubernetes cluster have oidc support?

[dmyerscough]

@mbohlool sorry I have been down with the cold.. I have tested this with CoreOS Tectonic which uses OIDC for authentication.

I can probably just write unit tests to begin with before integration tests.

[mbohlool]

@dmyerscough no worries. Integration tests are not required for this PR to be merged, but if you are up to add it, go for it. But unit tests are more important.

Thanks for doing this.

[mbohlool]

I don't think we should use the actual login keys in test. Can you mock it and use something like "test_login..."

[dmyerscough]

I can mock this out; I noticed due to the mocking the code coverage test fails.

[mbohlool]

@dmyerscough friendly ping. Any updates?

[mbohlool]

@dmyerscough you may want to look at this comment kubernetes-client/python#368 (comment)

[dmyerscough]

@mbohlool I have been pretty busy and haven't had time to look at this.

[lichen2013]

Using auth here can remove all the use of cert staff above:

refresh = request.refresh_token(
    token_url=response['token_endpoint'],
    refresh_token=provider['config']['refresh-token'],
    auth=(provider['config']['client-id'], provider['config']['client-secret']))

[lichen2013]

I get an error in my test:

TypeError: Incorrect padding

Would be nice to handle this error here.

[ltamaster]

Hi @dmyerscough , @mbohlool:
I am interested in this enhancement, I forked the last version of the client and apply manually these changes.
I added a fix for TypeError: Incorrect padding and I changed the variable values on the test.
Please let me know if you are OK if I send a new PR.

Thanks
Luis

[dmyerscough]

@ltamaster you are more than welcome to take over this, I have been swamped with a new job and preparing for a new born.

[mbohlool]

@ltamaster I am fine with a new PR.

[ltamaster]

Hi @dmyerscough,
I think I am ready for the PR, my only problem is that I cannot pass the SSL certificate to the refresh_token call. According to this PR (requests/requests-oauthlib#293) it is possible, but it didn't work for me. My workaround is not to verify the certificate using request.verify=false ( on the call when the client try to refresh the token). Is that OK @mbohlool @dmyerscough?

[ltamaster]

@dmyerscough @mbohlool forgot my last message, I found my problem

[ltamaster]

hi @dmyerscough
I have problems with travis on the test test_oidc_with_refresh (on coverage), any idea?

----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/tmp.yxT81y67iD/python/.tox/coverage/lib/python2.7/site-packages/mock/mock.py", line 1297, in patched
    arg = patching.__enter__()
  File "/tmp/tmp.yxT81y67iD/python/.tox/coverage/lib/python2.7/site-packages/mock/mock.py", line 1353, in __enter__
    self.target = self.getter()
  File "/tmp/tmp.yxT81y67iD/python/.tox/coverage/lib/python2.7/site-packages/mock/mock.py", line 1523, in <lambda>
    getter = lambda: _importer(target)
  File "/tmp/tmp.yxT81y67iD/python/.tox/coverage/lib/python2.7/site-packages/mock/mock.py", line 1206, in _importer
    thing = __import__(import_path)
ImportError: No module named config

[mvle]

I apologize in advance if this is already supported, but from looking at the PR, I think there needs to be a way to refresh the token not only at configuration initialization time but also during invocation of the K8 API calls. The token might expire right before a call thus causing the call to fail with an authentication failure. This will be needed for services that run a long time and rely on being able to reach the K8 Api Server (also short services that happen to be unlucky).

I think this can be done with a check to 'exp' field in the id-token right before a call_api or catch a 401 return status and perform a refresh token operation and update the configuration object with the new id_token and refresh_token values from the OAuth server.

#48

[dmyerscough]

Please ref #48