OIDC token auth about cloudtasker HOT 6 OPEN

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.

from cloudtasker.

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.

from cloudtasker.

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!

from cloudtasker.

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

from cloudtasker.

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 ?

from cloudtasker.

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:

• See: https://github.com/keypup-io/cloudtasker/blob/master/examples/cloud-run/README.md

from cloudtasker.