0

I created a backend service that connects to the Auth0 oauth2 endpoint. When testing all of this locally on localhost it works fine with the provided configurations. However as soon as I deploy the backend service to Google Cloud Run it fails to work because the configuration endpoint is having a connection timeout.

Here is the error log:

Caused by: org.springframework.web.client.ResourceAccessException: I/O error on GET request for "https://myproject.eu.auth0.com/.well-known/openid-configuration": Connection timed out (Connection timed out); nested exception is java.net.ConnectException: Connection timed out (Connection timed out)
    at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:785)
    at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:670)
    at org.springframework.security.oauth2.jwt.JwtDecoderProviderConfigurationUtils.getConfiguration(JwtDecoderProviderConfigurationUtils.java:150)
    ... 77 common frames omitted

Here is my Cloud Run service configuration:

  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args:
      - 'alpha'
      - 'run'
      - 'deploy'
      - 'foo-service'
      - '--image=eu.gcr.io/$PROJECT_ID/foo-service:$BUILD_ID'
      - '--concurrency=80'
      - '--cpu=2'
      - '--memory=512Mi'
      - '--region=europe-west4'
      - '--min-instances=1'
      - '--max-instances=2'
      - '--platform=managed'
      - '--port=8080'
      - '--timeout=3000'
      - '--set-env-vars=SQL_CONNECTION=10.113.160.3, SQL_USER=root, SQL_PASSWORD=root, SQL_DATABASE=dev'
      - '--set-env-vars=LOG_LEVEL=debug'
      - '--ingress=internal'
      - '--allow-unauthenticated'
      - '--vpc-connector=cloud-run'
      - '--vpc-egress=all-traffic'

I guess the important part here is the --vpc-egress=all-traffic option so I am sure that the service is able to communicate to the outside.

However the Ingress is configured to --ingress=internal. Might this be a problem? I thought when I have an egress defined and there is a request being launched through that - that it will receive the response through that channel again and it should not be routed through the ingress and therefore be blocked by its policies?

Edit #1 Removing the ingress=internal option did not seem to work. I guess it's because it's being disabled by default if an egress is defined.

xetra11
  • 7,671
  • 14
  • 84
  • 159

1 Answers1

2

The option --vpc-egress=all-traffic means that all traffic originating from your Cloud Run service goes through the VPC connector you called cloud-run. If you use that option, I don't think you can reach your Auth0 endpoint at https://myproject.eu.auth0.com/.well-known/openid-configuration. That's why the connection Cloud Run service => Auth0 times out.

I guess you need the VPC connector to connect to the private IP of your Cloud SQL instance. So only the traffic from your Cloud Run service to your Cloud SQL instance's private IP should go through the VPC connector. I think you can achieve this by using --vpc-egress=private-ranges-only instead.

Also, by setting --ingress=internal you are saying that your Cloud Run service can only be called within your VPC network. This means that Auth0 won't be able to call your Cloud Run service.

jackdbd
  • 4,583
  • 3
  • 26
  • 36
  • Well Auth0 is not the one calling my service anyway - so I guess this shouldn't be a problem right? – xetra11 Mar 15 '22 at 19:27
  • I thought your Cloud Run service needed an OAuth 2.0 access token from Auth0. If not, why calling Auth0 in the first place? (I might be missing something, I haven't used Auth0 in a while) – jackdbd Mar 15 '22 at 20:28
  • I receive a token from my frontend - but the backend services needs to check that token against the Auth0 API to see if the token is authenticated. Furthermore the JWT holds information about the claims (permissions) of that user token which is needed for my API endpoints to be called. On startup my application configures its JWT decoder with the mentioned openid-configuration endpoint for future JWT readings – xetra11 Mar 15 '22 at 21:15
  • 1
    However your egress info was the relevant one. I forgot that it's called `vpc-egress` and not just 'egress'. Therefore its routing any egress request through the VPC network. That is somewhat causing trouble. I set my egress now to `private-ranges-only` as you've suggested. Works now – xetra11 Mar 15 '22 at 21:17