I have a Google CloudRun Service, that is can be accessed either by the CloudRun URL or by a custom domain via a Load Balancer in the Google Cloud.
Now I am trying to setup some kind of access control, so that the Service which run the Development Stage can only be accessed by logged-in developers.
So far I tried to set the Trigger Configuration of the CloudRun Service to authentication required. That works for the base CloudRun URL, but on adding a path to the base URL I get a Forbidden error, even if I could access the base URL. And Accessing the Service via the LoadBalancer always gives a Forbidden.
Is there a way to make the CloudRun Service Accessible (including different Paths) only to LoggedIn Developers?
And also is there a way to make the Service only accessible by the LoadBalancer URL and not the CloudRun URL?
Once you require authentication, all requests need to include a token authorized to access the service via any endpoint. You can check out more information here: https://cloud.google.com/run/docs/authenticating/developers
There's also a tool in the gcloud CLI for Cloud Run to make this process easier. If you try gcloud beta run services proxy [your-service], the service will be proxied to localhost, with your identity token included by default.
For restricting access only via the Load Balancing URL, There's an ingress setting (also settable under the 'triggers' tab). This can be set to 'internal and cloud load balancing'.
You can find more info here: https://cloud.google.com/run/docs/securing/ingress
"Authentication required" for a Cloud Run service really means "Token required". It checks that the right token is attached to the request, but it's up to you how to add that token. Because of that I think it's mostly useful for machine-to-machine communication. It doesn't provide a log-in user interface or client-side code that attaches tokens to users' requests.
If you do want that, Identity Aware Proxy can provide it.
Related
I have assets in a Google Cloud Storage bucket. I created a subdomain (aaa.bbb.com) and a load balancer using that subdomain to point to that bucket (e.g. aaa.bbb.com/image-to-read.png). I also have an application using Google Kubernetes Engine. The goal is to make sure all users are blocked except that application on GKE. And all the GKE application is doing is reading the url of the assets to display them. How do I achieve that?
Things I've tried:
Setting GCS cors for the bucket
It turns out this only restricts by domain if people are signed into Google with the domain.
Workload Identity
This has just not worked for me. I also have an API service in the same GKE cluster that uses this and I'm able to upload fine with it. However, using a plain <img /> tag with the source as a the GCS bucket ignores the Workload Identity as far as I can tell.
Cloud Armor
This seems the most promising. I have successfully restricted by IP address but, unfortunately, the only IP address I'm able to restrict by is my actual local computer. I believe that means the request headers are sending my computer's IP address to the load balancer. But what I am trying to do is restrict access by the application's load balancer IP address or even by the origin domain (preferred).
What I'm asking is probably a basic networking question, but I'm no wiz at all the devops/infrastructure concepts so any help would be appreciated. Thanks!
You have two options:
Cloud Storage authorization
Deploy an HTTP(S) Load Balancer + Cloud Armor.
I am not sure what you mean by GKE ingress IP.
The simplest is to add Authorization in your GKE application when accessing Cloud Storage.
Authorization:
Service Account OAuth Access Token
Signed URLs.
Both methods are easy to implement.
Note: Workload Identity Federation also generates service account OAuth access tokens. Use that method if need to federate credentials from one OAuth Authority to Google. However, for a GKE application, Signed URLs or service account OAuth access tokens are probably the correct solution.
I am trying to set up Google Integration in my self-hosted Nextcloud instance. For this I need a Google Cloud API Web application OAUTH Client ID and Secret, along with the preset Authorized redirect URI from my Nextcloud instance. I can easily create the ID and Secret for the Web app. But, if I put the Authorized redirect URI in the Google Cloud OAUTH page, it tells me "Save failed: The request has been classified as abusive and was not allowed to proceed".
For context, the Domain provided is a Google Domain which I am using with a Cloudflare proxied DNS. Google verification TXT record have been added to Cloudflare. I am self-hosting the Nextcloud instance with a subdomain of this domain behind an Nginx Proxy Manager with a Cloudflare SSL certificate. To add, all of these are running as docker containers on Ubuntu. Additionally I have also verified the Redirect URI as Safe from: https://global.sitesafety.trendmicro.com/result.php
Even then, apart from that specific URI, I have tried URI of other services I am self-hosting as well as the parent domain. All of these are giving the same message from the GCP OAUTH screen.
Kindly help me out with this considering I am fairly a novice.
I have an airflow web page that already has built in sso login. The web app is deployed internally, thus, I need to expose this publicly.
I'm using Tecnativa to expose the web page.
I deployed using
GKE.
In the internal deployment, OAuth 2.0 Client IDs has set up
with the necessary redirect urls.
Internal deployment has no issue.
The external deployment is successful. Yet, I'm not able to open the web page using the new external endpoint mapped from the internal endpoint.
Typical error: This site can’t be reached.
I believe this issue might be due to the redirect endpoints given in internal deployment, is unreachable.
How can I use Tecnativa to redirect from external endpoint to oauth redirect endpoint of internal url.
I try my best to explain lol.
I will include the yaml files if necessary.
I'm wanting to put Cloudflare in front of my API hosted on Cloud Run. I'd like to ensure my Cloud Run app only accepts connections from Cloudflare (to avoid bypassing DDoS mitigation + rate limiting in Cloudflare).
Is there any way to use Cloudflare's Authenticated Origin Pulls with Cloud Run?
Other solutions that achieve the same effect are welcome too - however the key is I don't want traffic from non-Cloudflare sources to trigger a Cloud Run invocation (otherwise a DDoS could result in billing spike). Thus, filtering traffic inside the Cloud Run app is too late, an invocation has already occurred.
Seems like there may be a way to add on HTTPS Load Balancer + Cloud Armor to do IP whitelisting and only allow requests originating from Cloudflare's IPs...but I'd rather not start tacking on two other services and add $$ just to achieve this.
Google Cloud Run supports two authorization mechanisms: unauthenticated (anyone/public) and OAuth Client ID. Cloudflare's Origin Pulls use TLS certificates, which means your Cloud Run application would need to verify the certificate as Google's Frontends do not support this. This would not accomplish your goal of preventing unauthorized invocations of Cloud Run.
In summary, unless your service is using OAuth Client IDs for authorization, there is no method to prevent Cloud Run service invocations except by limiting the maximum number of instances. If you have configured unauthenticated access, anyone calling your service endpoint will succeed in invoking your service or executing an overlapped request.
I have a backend service, which I don't want to be expose, and also, just the employees that uses Gsuite oAuth should access.
Instead of exposing the backend and add the logic of oauth in it, I looked at the vouch-proxy project, which fits me very well (a proxy that redirects unauthenticated traffic to oauth login page and then, when a valid token is passed, it's redirect to the backend.
Before using this vouch proxy, do GCP has something built-in for it? Or another kind of setup that my backend service is not exposed?
Google Cloud provides the Identity-Aware Proxy (IAP) that would precisely fit your needs since it's integrating well with G Suite domain and can sit in front of your Load-Balancer.