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

OIDC token auth #28

Open
jasonjho opened this issue Apr 27, 2021 · 6 comments
Open

OIDC token auth #28

jasonjho opened this issue Apr 27, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@jasonjho
Copy link

Thanks for open sourcing a great framework. I didn't see this in the docs or codebase anywhere, but is it possible to specify the OIDC token via service account?

We would need to be able to authenticate target HTTP Tasks, but didn't see an obvious way for us to do that.

Thanks!

@alachaum alachaum added the question Further information is requested label Apr 28, 2021
@alachaum
Copy link
Member

alachaum commented Apr 28, 2021

Hi @jasonjho, my pleasure!

So the library has its own authentication system (we generate a JWT token for each task). The reason we implemented our own authentication system is to ensure the library still works even with non-OIDC endpoint.

Having said that, you should be able to override the /cloudtasker/run route and provide your own controller to support custom authentication, such as OIDC.

You can copy and customise the following controller file. Just override the authenticate! method with your own logic.
https://github.com/keypup-io/cloudtasker/blob/master/app/controllers/cloudtasker/worker_controller.rb

I haven't tried it myself but it should theoretically work. Let me know if you have issues doing it and I'll try to do a small prototype on a separate repo.

@jasonjho
Copy link
Author

jasonjho commented Apr 28, 2021

Hi @alachaum thank you for the explanation. Is the assumption then that these Cloud Run task handlers are deployed as a public endpoint in order to receive the request to handle the custom authentication?

My understanding is if you have a Cloud Run service that is deployed privately (default), then you must authenticate Cloud Task to have the CloudRunInvoker role as well as include the OIDC or OAuth token when sending the request payload to create the task:

{
  http_method: :POST,
  url: url,
  oidc_token: {
    service_account_email: ___
  },
  body: payload,
  headers: headers
}

Would love to better understand how we can support this use case, if possible.

I'll take a look at the custom controller approach in the meantime as a possible workaround.

Thanks!

@alachaum
Copy link
Member

At the moment we use public endpoints indeed. I'll do a bit more digging to see what needs to be done in order to support OIDC.

We may indeed need to modify the way tasks are created - changing the controller might not be enough.

@alachaum alachaum added the enhancement New feature or request label Apr 28, 2021
@emerson-argueta
Copy link
Contributor

I think oidc could be implemented using google's metadata server url:
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity

Calling the endpoint and passing in the the query param "audience" as the configured processor_host will give back an identity token that can be used when sending the request stored in the cloud tasks queue.

I can see that this file:
https://github.com/keypup-io/cloudtasker/blob/master/lib/cloudtasker/backend/google_cloud_task_v2.rb

creates the http request used to execute the worker.

It would then be possible to add the token to the headers in the http request on line 108.
The token can be retrieved using an http client in a helper method

@JonLev
Copy link

JonLev commented Feb 1, 2023

Hello guys,I came across your thread and PR when I was implementing the gem myself because it seemed necessary to have this feature to secure a specific cloud run service to run jobs. But after several reading and trial, I think we can implement a secure enough stack without OIDC in this specific use case.

The goal of OIDC is to transfer a IAM user to the cloud task to be authenticated to the cloud run service as an invoker. But you can create a Cloud Run service with an ingress blocking all external request but allowing unauthenticated requests. With this the need of OIDC should be lessened. Would you think @alachaum that this would be a good point to add to the README for answering to people that would have security as a concern ?

@alachaum
Copy link
Member

Hey @JonLev , that's actually a very good idea. If you make a PR to update the README, I'll be happy to review it.

On a side note I have incorporated @emerson-argueta 's work on OIDC. It's available on master and I have added an example app and some instructions to setup OIDC:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants