I am trying to setup a python app on GCP Cloudrun I need only authenticated users to be able to access the Cloudrun URL but I am facing 403 issue when I set up this app. Is there any alternative way to access the Cloudrun instance using browser provided it is configured to allow only authenticated users?
This is the flow which i am trying to implement :
HTTP(S) Load balancer -> Frontend forwarding rule -> Cloudrun Backend -> Python app deployed on Cloudrun
I have saw few other questions and tried that solution but it does not work few such similar questions would be :
403 "Error: Forbidden" when opening the URL of my Cloud Run service
If you're currently getting 403, it means you don't have the necessary permission to access the service (the App was deployed to cloud with the option to use 'authenticated' invocation which means you can't access it by directly typing the URL in the browser). You can do any of the following
Generate a token and then use curl to invoke your url using that token. See Google Documentation on this and a more detailed explanation from Google here. But you can't be doing this each time you wish to invoke the service. It's more for testing.
Update: The solution below was to allow him to actually see the App run in the browser but reread the question and see that OP wants only authenticated users to access the App.
2. Redeploy the App to Cloud Run but make sure you choose the option to allow for 'unauthenticated invocation'. See step 3.iv of this [blog article][3] we wrote on deploying to cloud run
After trying out IAP as said by #guillaumeblaquiere i was able to fix this issue. Thanks a lot as there is ver less documentation on how to fix this i have recorded steps that i implemented to fix this issue :
Accessing applications on Authenticated Cloud Run using IAP
Related
I'm hosting the backend for an internal admin tool on Cloud Run. Since only admins of the GCP project should be able to access this tool, I followed the instructions here to enable IAP for Cloud Run by setting up a load balancer with a static external IP (and custom domain), restricting ingress to "Internal and Cloud Load Balancing", and allowing public unauthenticated access for the Cloud Run service since IAP is handling the authentication and authorization.
Now I'm trying to set up some cron jobs on Cloud Scheduler, for which I've provided an endpoint corresponding to my custom domain (say https://customdomain.com/endpoint), along with a service account email that allows OIDC tokens to be generated. The audience for the OIDC token is set automatically to the same custom domain URL. However, as reported on this thread, there seems to be a bug with Cloud Scheduler that only allows run.app audiences - anything else (including custom domains) results in a 401 UNAUTHENTICATED. This happens even if I set my target URL to https://customdomain.com/endpoint but my audience to https://cloud-run-service.a.run.app/endpoint. Of course, I can't change my target URL to https://cloud-run-service.a.run.app/endpoint since it doesn't allow direct traffic not coming through the load balancer.
Has anyone been in this situation or know of any workarounds? Thanks!
I understand your issue is,
In Cloud Scheduler, the OIDC token that is sent to the Cloud Run Service only works if the Audience is the Cloud Run-provided URL, not the Custom Domain URL.
Doesn't work: URL: https://service-url.customdomain.com | Audience: https://https://service-url.customdomain.com
Works: URL: https://service-url.customdomain.com | Audience: https://example-abcdefg.a.run.app
Works: URL: https://example-abcdefg.a.run.app | Audience: https://example-abcdefg.a.run.app
Google is aware of the issue and is working on allowing them to specify custom audiences for Cloud Run services, which will solve your problem.
Right now as per the latest update on May, 2022 we're about to ship custom audiences for Cloud Run. Please fill out this form if you are interested in being an early tester for "custom audiences for Cloud Run."
Currently, to authenticate the caller via Cloud IAM, you must pass in JWT token with the audience field set to the full URL of the service, such as https://example-abcdefg.a.run.app.
With this capability, you can specify a custom domain as the audience field in the OAuth token instead of the original service URL enable a service deployed in multiple regions to accept a common audience field
Issue tracker reference :
https://issuetracker.google.com/182490050
I believe you can still set the target URL (while configuring Cloud Scheduler) to the run.app/endpoint of your Cloud Run service by making use of service accounts
First create a service account for Cloud Scheduler
Then give this service account permission to invoke your Cloud Run Service
See Google's documentation here
After hours of painful debugging, here's the solution for anyone with the same issue. While it's still true that custom domains mapped to the Cloud Run service don't work as the OIDC audience, neither does the Cloud Run-provided run.app URL when using IAP in front of a load balancer. It turns out the expected audience in such cases is the IAP Client ID. You can find this under Credentials -> APIs and Services -> OAuth 2.0 Client IDs -> <IAP service name>. Just manually set the OIDC audience to this exact string and things should start working!
I built a simple application using Streamlit (python) and AWS Cognito. I managed to set up a user pool and access to the application through an application load balancer and Fargate.
However, although logging in is no problem, I'm struggling trying to figure out how to actually log out. I found the following documentation: https://docs.aws.amazon.com/cognito/latest/developerguide/logout-endpoint.html. I assumed that entering https://<my-application>.ca-central-1.elb.amazonaws.com/logout?client_id=xxxxxxxxxxxxxxxxxx&logout_uri=https://myclient/logout/ in the address bar would result in a logout, but I just get a 404 response?
Any help would be greatly appreciated.
aws sso login --profile //profile name// is usually open browser and ask for approval is there any other way we can do this without browser. I have a situation where I need to setup aws cli in my docker container and I can only use aws sso login and I don't want to use any selenium to handle browser approval since its looks complex so I want to do all in cli itself…
aws sso login takes a --no-browser flag which suppresses the browser launch
From there you can control the sso verification url via a browser automation library e.g. puppeteer.
You can also get the verification url via aws sso-oidc actions/commands.
An example in golang using go-rod is available on github here although this won't work with a non-mfa process flow, which is what you want here. The code at the link can be modded or updated to support that use-case with not a whole lot of effort.
Generally using aws sso isn't recommedended for this type of use-case. Instead, you're better off using IAM user credentials (while outside VPC for example) or if in a VPC - instance profiles if they're available.
I have a service to service set up that I completed using the google cloud tutorial (https://cloud.google.com/run/docs/authenticating/service-to-service#nodejs)
Changed the cloudrun Service account to have roles/run.invoker (they both share the same role)
Make a request to get the access token: http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://XXXX-XXXX-XXXX-xx.a.run.app'
(failing) Use that access token to make a request at https://XXXX-XXXX-XXXX-xx.a.run.app/my-endpoint with the access token: axios.post('https://XXXX-XXXX-XXXX-xx.a.run.app/my-endpoint', {myData}, {headers: {Authorization: 'Bearer eyJhbGciOiJSUz.....'}})
However, on step 3, making the call to my service, I receive a 403 error, any thoughts on what I missed?
Note: I have tried deploying my invoked service with --allow-unauthenticated and without it. I am not using a custom domain, I am using the CloudRun created url.
PS: If I change the ingress from internal and load balancer to all it works, however I'm not sure if this is correct to do.
The HTTP 403 Forbidden error message when accessing your Cloud Run service means that your client is not authorized to invoke this service.
You have not granted the service account permission to call the receiving service. Your question states that you added roles/run.invoker but the error message indicates you did not complete this step correctly.
Go to the Google Cloud Console.
Select the receiving service (this is the Cloud Run service you are calling).
Click Show Info Panel in the top right corner to show the Permissions tab.
In the Add members field, enter the identity of the calling service.
Select the Cloud Run Invoker role from the Select a role drop-down menu.
Click Add.
Note: When requesting the Identity Token, do not specify the custom domain. Your question's wording is confusing on that point.
[UPDATE]
The OP has enabled internal and load balancer. This requires setting up Serverless VPC Access.
Connecting to a VPC network
Solution was to add a VPC Connector and route all traffic through it. I added this to the deploy script --vpc-egress all-traffic. Originally I had --vpc-egress private-ranges-only to connect to redis MemoryStore, however this was insufficient to connect to my other service (internal only ingress).
Credit to excellent insight from #JohnHanley and #GuillaumeBlaquiere
Interesting Note About NodeJS: My container wouldn't start when I switched the --vpc-egress to all-traffic, and I had no idea why because there were no logs. It turns out running node v16.2 caused some weird issues with --vpc-egress all-traffic that I couldn't debug, so downgrading to 14.7 allowed the container to start.
Title says it all: is it possible to host a static-generated site on S3 and restrict access to it based on Github OAuth?
Scenario: You generate a static site (using Hugo or whatever) and you upload it to S3 as a static site. Is there some combination of AWS services (API Gateway, Lambda, etc.) that can make it so that only members of my Github organization can access this site? Authenticating with Github's OAuth? Anyone not authenticated should be treated with a 404.
Has anyone done this or know how to do it? Is such a thing possible without running a backing server (EC2, Heroku, DigitalOcean Droplet, etc.) of some kind?
Looking for a complete answer that outlines steps on how to set this up (if possible) with the lowest cost/complexity.
Yes this is possible. I've followed this tutorial in the past to secure a static site on S3 behind an Auth0 authentication, using DynamoDB as the user account store, and API Gateway + AWS Lambda as the authentication service. That was an AngularJS SPA, but the general concept should be the same.
Github is listed as an Auth0 identity provider. I would recommend looking at this documentation for using Auth0 on your site. Once you get it working you would have to configure your static site generator to include the authentication JavaScript code on every page it generates.