How do I make my cloud run link more secure? - api

When I make a GCP cloud run instance anyone can to that link. I am using it for an API for my website. I do not want joe blow opening F12 and following the HTTP requests to my API. I use API keys and stuff however I want my link to be protected to only certain IP addresses or at least lock it behind a username and password. How can I do this with cloud run on GCP?

Cloud Run exposes a public URL by default. You can make it public (let allUsers invoke your endpoint) or restricted (only authorized user can invoke)
The problem with the second solution is that only the Google accounts (Workspace or Gmail) can be added and so restrict your user to use that type of credentials.
So, the solution is to make your API public. You can implement security mechanism in it to software control the authN and authZ of your user, but you aren't protected against DDOS attacks.
Therefore, Cloud Armor enters in the game. You have to create a Load Balancer and to put your Cloud Run service as backend of it. Then activate Cloud Armor. You will be able to check the IP source of the requester, but also to protect your service against attacks.

Related

Disable authentication for an app cloudflare

I have a server and I make a tunnel with cloudflare to be able to access from outside creating an application in Cloudflare Zero Strust and I am trying to disable all the policies so that it allows me to access the application without authentication.
But nothing works, whenever I try to enter my linkstream.domain.org application, it asks me for authentication via email.
The reason is that this application allows me to play streams so I don't want it to have authentication to access.
I've searched and configured everything, but I can't remove this authentication from cloudflare:
Cloudflare Access is a product that can be used to add authentication to an application. If you want your application to be public (i.e. no authentication), I'd recommend not adding it to Access at all. You can set up a Cloudflare Tunnel without adding any Access application, for example to expose a webserver to the public.
I'd recommend looking also at the Allow policies.

Using Firebase Auth id tokens to authenticate (multiple) Cloud Run services

Related to Security Cloud Run services for end-users and other services
I'm using:
Firebase Auth to generate id tokens for users with Google, Microsoft, GitHub ... identities
Cloud Endpoints on Cloud Run to invoke (Cloud Run) gRPC services
Firebase Auth users are auth'd by one of my services
Where I'm struggling....
My app provides 1 or more Cloud Run services that the app's users should be able to curl. But authenticating Cloud Run services require per-service id tokens; the id token's audience must use the Cloud Run service URL and the Cloud Run service URL is service-specific.
It seems as though I ought to be able to exchange the Firebase Auth id token for (Google Account) id tokens (with appropriate audiences) that can then be used to invoke the Cloud Run service. The proxy could also run on Cloud Run and it would use my app's auth service to verify whether the id token user should be issued with a Google id token.
Guillaume Blaquire's answer proposes either Coud Endpoints or a proxy similar to what I describe above. However, Cloud Endpoints requires that the backend services be known at deploy time (which these Cloud Run services won't be) and I want to provide the user with the id token so that they can use curl or some other tool to make the auth'd request.
Cloud Run has some compelling documentation for Authenticate (sic.) but I want something between:
Authenticating users -- I have the JWT but I want to receive a Google id token for the Cloud Run service
Authenticating service-to-service which Guillaume's alternative proposal in the answer.
Rather than place your Cloud Run behind Cloud Endpoints, where you have to know the Cloud Run instances ahead of time, you can handle the request and authentication inside the Cloud Run instance itself.
To be able to handle Firebase Authentication tokens inside the Cloud Run instance, they must be setup so that they can be invoked unauthenticated. Then, inside the Cloud Run, it should launch a web server, parse the incoming request (paying attention to the Authorization header - Firebase Auth sample) and then either action or terminate the request.
To achieve this, take a look at this thread for details on how you can handle both HTTP and service-service requests. Alternatively, you could just deploy the Functions Framework image from which that thread's code is based.
If you want cleaner URLs, host multiple endpoints within a single Cloud Run instance and then place that instance behind Cloud Endpoints or you can take a more manual approach via a custom domain using a service like Firebase Hosting.

Getting 403 Forbidden on Google Cloud Run with API key

I have set up a very simple Node application with Express on Google Cloud Run.
It works great, but when I set it up with "Allow unauthenticated invocations to [service] (y/N)?" to No, I get a 403 Forbidden even though I created an API key and I'm making the calls adding key=[My API key] in the query string, as told in the documentation. My URL ends up looking like
https://service-wodkdj77sba-ew.a.run.app?key=[My API key].
I've tried with restricted (for Google Cloud Run) and unrestricted API keys.
Is there anything I'm missing?
Cloud Run, like many product in GCP, doesn't support API Key authorization. As detailed in your provided link, only a subset of service use API KEY.
It's also mentioned :
API keys do not identify the user or the application making the API request, so you can't restrict access to specific users or service accounts.
Where Cloud Run authentication section specify this here
All Cloud Run services are deployed privately by default, which means that they can't be accessed without providing authentication credentials in the request.
By the way, the Cloud Run expectation and the API Key capabilities aren't compatible.
However, if you want to access to your Cloud Run private service with API Key a workaround exist. You can deploy an Extensible Service Proxy (ESP) on another Cloud Run service. In it, authenticate the API Key and, if it's valid, call the Cloud Run private service with the ServiceAccount of your ESP (which must have roles/run.invoke role).

Satis - password protection

I have a satis repository which connects the dots for my private bitbucket repositories. I want to be able to charge for access to this satis repository by sending over the applications (my base application uses Laravel) secret key and validate it against the users account. Is there a way to send over the key for me to validate?
regards
Satis is simply a script that compiles some files that can be hosted anywhere where static file hosting is available.
If you want to add access control, it is not a question of using Satis correctly, but implementing access control for static HTTP resources.
By the way: The only authentication protocol Composer offers is HTTP Authentication (aka ".htpasswd"), so if you want a sophisticated payment and access control, you have to implement something that would send 401 HTTP status codes, wait for a username/password and check if that account paid.

Oauth2 authentication for installed applications using service account flow

I've successfully built a ruby script and a mac app that use service account credentials to authenticate (without user interaction) to google cloud storage and upload/download objects.
I now need to perform similar actions on an iOS device. Is it possible to use installed application credentials to authenticate still without user interaction?
If it's possible or has been done, can you please provide an example or point me in the right direction.
Thanks!
You need the private key for the service account to get the access token for the application. Please bear in mind that some hacker may steal that private key for both mac and iOS app. If the data is per user and you have a backend server, you may authenticate the user on the backend and then use the private key on the server to access the storage. If the data is per app, seems there is no good way to prevent the private key abuse.