Authentication config for cloud run behind IAP - google-cloud-platform

I want to run a Cloud Run service behind an external HTTPS LB and IAP. After setting everything up, I still get a 403 Forbidden when trying to access the Service via the URL pointing to the LB (after IAP login pops up and I sign in). I presume this is because the Cloud Run service Auth configuration is set to 'Require Authentication' and according to Google Documentation it needs to be 'Allow Unauthenticated Invocations'. Unfortunately, according to an Organization policy, this is not possible.
However, I noticed I have another Cloud Run service (in another Organization) with basically the same setup (HTTPS LB and IAP enabled for the service), and here I can access the Service through the IAP even though the Cloud Run Service is set to 'Require Authentication'.
So there seems to be a way to have a Cloud Run Service with Authentication AND IAP, but I can't figure out how (or why it works for one service and not for the other one).
What could be the reason for that?

Related

ERROR: Access is forbidden when trying cloud run service-to-service communication

I'm trying to implement cloud-run services to service communication.
Aim: service A (frontend) need to call service B (content-api) which is connected to cloud SQL DB.
Implemented using official doc - https://cloud.google.com/run/docs/authenticating/service-to-service
My present setup is as below
Frontend service config
Created a new service account and attached it.
Created a serverless VPC connector in the host project and configured it with all traffic through this connector.
Ingress is set to allow all traffic
Authentication is set to allow unauthenticated invocations
Content-api config
Create another new service account and attached it.
Used the same serverless vpc access connector which is in the host project and configured with all traffic through this connector.
Ingress is set to allow internal traffic only.
Authentication is set to required authentication (frontend service code is fetching token from metadata server and is able to connect using that token)
Also configured cloud run invoker role for frontend service account principle in content-api (show info panel settings).
Expecting to get data from content-api when frontend service is triggered.
I'm able to trigger frontend service but getting access forbidden error (guessing due to content-api is set to allow internal ingress only ). But when I change that content-api ingress setting to allow all traffic. It Is working fine - requesting a token and using that to call content-api and which queries DB and responds with the expected value.
what could be the cause for the internal setting error ( Access Forbidden )? And how to resolve this? Thanks in advance for your answers/suggestions.

Connecting to Google Workspace via Google Cloud Identity Aware Proxy

We are considering a configuration that connects to Google Workspace via Identity Aware Proxy.
I have done the following setup and it is returning ErrorCode 52.
(1) Create a custom URL in Google Workspace
　　For Google drive: http://drive.mydomain.com
(2) Create a network endpoint for the custom URL
(3) Configure HTTPS load balancer and specify the network endpoint as the backend
　　URL: https://iap.mydomain.com
(4) Enable IAP
We have confirmed that Google drive can be accessed via the load balancer with IAP turned off.
Also, when IAP is enabled, accessing with an account that does not have access rights will lead to the screen as expected.
The access by the account with access rights is not working.
I issued a wildcard certificate ("*.mydomain.com") and connected it to the load balancer, but this did not change the situation.
I also added "*.mydomain.com" to the allowed domains with the following command, but this was not valid either.
gcloud iap settings set SETTING_FILE.json --project=myprojectid --resource-type=iap_web
Is what I am trying to do feasible with IAP?
Are there any other settings I should do?
(I connect to the Internet via a corporate proxy.)
Documents I referred to when troubleshooting
https://cloud.google.com/iap/docs/allowed-domains
https://cloud.google.com/iap/docs/faq

Cloud run invoking another Cloud run with "Allow internal traffic and traffic from Cloud Load Balancing" fails with error 403

I have built a Django backend and deployed it in cloud run. I have also built a react frontend that was also deployed in cloud run. Frontend calls Django backend. Everything works while backend Allow all traffic, when I change it to "Allow internal traffic and traffic from Cloud Load Balancing" I get 403 error. Both are using VPC connector. And also both are on un-authenticated cloud Run.

Focus on your architecture and where the code is running.
Your backend run on Cloud Run
Your front ent? it's served by Cloud Run, but executed on your browser.
That's why, your browser haven't a serverlessVPC connector or something like that and the request to the backend come from the internet, nothing from your Cloud Run frontend.

Getting 403 when connecting to a Cloud Run service when using a Serverless VPC Connector

I have a service on Cloud Run (Service A) who is trying to call another service on Cloud Run (Service B). Both the services are in us-east1.
For Service B, Ingress is set to 'Allow internal traffic only' and Authentication is set to 'Allow unauthenticated invocations.
I created a Serverless VPC Connector in the same region as the services and set the IP address range to 10.8.0.0/28. 
I then connected Service A to the connector mentioned above and set 'Route only requests to private IPs through the VPC connector'.
I seem to be getting a 403 when attempting to hit the service. Has anyone had this issue? If so, how did you solve this problem?

You need to set the egress to All, to route all the traffic to the serverless VPC connector.
Indeed, even if you set the service B to internal egress, the Cloud Run service is still exposed publicly, but an additional check is performed on the requests that come in to validate the traffic origin (comes from your VPC or not).
In your case, in the service A, with the private range only egress, you route only the traffic going to private IP, and it's not the case of the always-publicly-exposed "internal" service B.

I am guessing that the code 403 you are getting it from the cloud run service and that is a problem with the authentication, so to solve that error code you could follow this link, there you will find a detail explanation of how authenticated users for you services.

I was able to fix this issue. This must be used when you have to use authenticated user to access cloud run application
Accessing Authenticated Cloud Run applications using IAP

It means that your client is not authorized to invoke this service.
You can address this by taking one of the following actions:
If the service is meant to be invocable by anyone, update its IAM settings to make the service public.
If the service is meant to be invocable only by certain identities, make sure that you invoke it
Please find the link that might help in troubleshooting this error.

Programmatically authenticating and accessing service inside AWS EKS cluster from outside when ALB is used

We build a Kubernetes application that is deployed by our users, our users connect to the deployed API server using a client and then use that client to submit jobs.
This question is about programmatically connecting to an application running inside Kubernetes cluster from outside of the cluster.
We have this working with local Kubernetes deployments and Google Kubernetes Engine (using IAP).
However some of our users on Amazon cloud cannot connect to the application.
I do not have much experience with AWS. I'm used to token-based auth and OAuth-like auth methods where authentication happens outside of a library: the user is redirected to some page where they log into a service and the client library only gets a token without ever seeing the password.
One of our users have implemented an auth solution that takes username and password and then uses Selenium to emulate the login process and get a cookie which is then used for sending requests. https://github.com/kubeflow/pipelines/pull/4182
Here is a quote from the PR.
Currently, kfp client can not be used outside AWS EKS cluster. Application load balancer manages outside traffic and require authentication before traffic coming into mesh. This PR automates ALB authentication and get session cookie to authenticate KFP python client to Kubeflow cluster.
This unblocks user to submit pipeline/run outside kubeflow cluster and user can integrate with their CI/CD solutions much easier.
Cognito or OIDC behind ALB both can leverage this solution.
Is there a better way to authenticate with AWS EKS ALB?
I've searched the AWS documentation for programmatic authentication methods, but did not find what I wanted (the docs mostly focused on server-side auth setup). In my last search I found the following article, but I'm not 100% sure it covers what our AWS users want.