Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Google OAuth credentials for GKE auth using Google Service Accounts #580

Closed
wants to merge 1 commit into from

Conversation

dev-dsp
Copy link
Contributor

@dev-dsp dev-dsp commented Aug 22, 2019

Support Google OAuth credentials for GKE auth using Google Service Accounts

<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.6</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have to be careful here since this is part of Core. Probably you meant to use <exclude>s instead.

<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.5</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto, or use the library plugin for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added these deps here due to enforcer (Require upper bound dependencies error) and I am actually not sure how to apply excludes here.
Could you assist with that or share some info on using library plugin?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you needed to do this, the POM mistakes are probably upstream in the google-oauth plugin.

@@ -240,7 +251,8 @@ public ListBoxModel doFillCredentialsIdItems(@AncestorInPath Item item, @QueryPa
CredentialsMatchers.instanceOf(StandardUsernamePasswordCredentials.class),
CredentialsMatchers.instanceOf(TokenProducer.class),
CredentialsMatchers.instanceOf(StandardCertificateCredentials.class),
CredentialsMatchers.instanceOf(FileCredentials.class)
CredentialsMatchers.instanceOf(FileCredentials.class),
CredentialsMatchers.instanceOf(GoogleRobotCredentials.class)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not how we want to work with credentials. AFAIK there should be no need to touch the kubernetes plugin at all. Rather, the Google-related plugins should be implementing TokenProducer. That is how a generic plugin can support authentication with various credential types, including from AWS etc. I would have to refresh my memory on the details though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, there is kubernetes-credentials-plugin, that defines TokenProducer. Should then my code be moved there, or google-oauth-plugin should implement that interface itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure offhand, would need to spend time researching it. I had thought the official API here was via the authentication-tokens plugin, which allows for example docker-commons to pick up Registry credentials from multiple vendors, but now I see that kubernetes-credentials indeed defines its own interface, perhaps in ignorance of that system. @Vlatombe @stephenc opinions?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we deprecated the OpenShift kind already, in #529. #268 is the older change. Asking for advice from @maxlaverse.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

authentication-tokens should be able to provide the mapping... you want to turn the credentials into something that knows how to add auth to the HTTP client library... that may mean providing implementations of that for all the supported credential types... but it also means that the support can be added by extension plugins rather than needing to modify the base all the time. See https://github.com/jenkinsci/gitea-plugin/blob/master/src/main/java/org/jenkinsci/plugin/gitea/authentication/GiteaAuthUserSource.java and https://github.com/jenkinsci/gitea-plugin/blob/d5aa571acd4fb9e5d2f9c39034b577b397980f0b/src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMSource.java#L720 for an example

@jglick jglick requested a review from maxlaverse August 22, 2019 15:15
Copy link
Contributor

@maxlaverse maxlaverse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a limited access to Internet for two weeks and didn’t really manage to go into that PR on my mobile @jglick

The only thing I can say is that all credential related classes have been moved into ‘kubernetes-credentials-plugins’. The OpenShift implementation is in that plugin as well iirc. You could probably do the same and implement the TokenProducer interface, and wouldn’t need any change here, right ?

That being said, I extracted this kubectl configuration feature from the ‘kubernetes-plugin’ in the ‘kubernetes-cli-plugin’ a while ago. If you want pipeline support and if there are any changes to do on those KubeCtlWrappper classes, you might want to open a PR there.

@dev-dsp
Copy link
Contributor Author

dev-dsp commented Aug 23, 2019

@jglick so, based on discussion above, would it be sufficient for now to move my changes to kubernetes-credentials by implementing its TokenProducer interface? As I understand, both kubernetes and kubernetes-credentials plugins should be reworked to support AuthenticationTokens and it would take much more time, but can be done in separate issue.

@jglick
Copy link
Member

jglick commented Aug 23, 2019

@dev-dsp that would be my understanding as well.

@dev-dsp
Copy link
Contributor Author

dev-dsp commented Aug 27, 2019

I don't see any correct way to implement it in kubernetes-credentials, because required google credentials class is final, so it is not possible to extend it, and for implementing GoogleRobotCredentials interface I would need to duplicate code of getGoogleCredentials.

Implementing AuthenticationTokenSource interface however was much simplier and took ~70 loc in both kubernetes-credentials and kubernetes plugins (but with crutches to support all three methods - hardcoded plugins, AuthenticationTokenSource and TokenProducer).

My suggestion is to merge my changes for now (since they are small and fit to the plugins current state), and after that rework all three plugins (k8s-credentials, k8s, and k8s-cli) to use AuthenticationTokens

@Vlatombe
Copy link
Member

It is always a pain to handle migration issues after the fact. I would recommend implementing a minimal support for AuthenticationTokens in kubernetes-plugin, to provide OauthToken in builder, or --token in the cli form.

Then add your google oauth implementation directly to kubernetes-credentials, adding the required dependencies (google-oauth, authentications-token). Then existing implementations using TokenProducer could be gradually migrated to AuthenticationTokens.

@dev-dsp
Copy link
Contributor Author

dev-dsp commented Aug 28, 2019

So I've opened jenkinsci/kubernetes-credentials-plugin#12

It contains classes defining different authentication types for Kubernetes along with Google OAuth Credentials token source.

I already have code changes for kubernetes-plugin to use that new API, but need to release new version of kubernetes-credentials before opening PR with them.

@Vlatombe
Copy link
Member

Vlatombe commented Aug 29, 2019

@dev-dep Please open the PR, even if you reference the snapshot (the CI will fail but at least we'll be able to review). I filed jenkinsci/kubernetes-credentials-plugin#13 so that you will be able to refer to your changes using Jenkins incrementals (https://jenkins.io/blog/2018/05/15/incremental-deployment/) once it is merged.

@Vlatombe
Copy link
Member

Superceded by #588

@Vlatombe Vlatombe closed this Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants