I have created a simple Google Cloud Run helper program (does not handle any personal data nor does it make use of any storage facilities) and have implemented a public interface for it within a website (using HTML requests). I do not plan to add any user authentication, and I have also open-sourced the code within the Cloud Run container.
Should there be any further steps I should take to protect the container from malicious users? Could someone just overload the app with requests, exceeding the free invocation limit for the container (resulting in myself being billed)? I mainly just want to ensure that I am never billed for the Cloud Run app, given that it is simply meant to act as a small helper tool for a limited number of users.
Thanks.
Should there be any further steps I should take to protect the container from malicious users?
Always, protecting your apps and services from malicious users is always a must. As John Hanley very well point out, if you are not using any type of authentication, you are therefore leaving one door open to more malicious attacks/users than if you implement some kind of authentication.
As he mentioned, if you have enabled allow-unauthenticated you are basically open your Cloud Run services to the public. This is not entirely bad, but it is another way to malicious users to attack your services.
You will find more information about unauthenticated access here.
I highly recommend you to authenticate your Cloud Run services always if you can. As stated in the authentication overview for Cloud Run:
All Cloud Run services are deployed privately by default, which means that they can't be accessed without providing authentication credentials in the request.
Furthermore, by default, services are only callable by project owners, editors, and Cloud Run admins and developers.
To authenticate end-users in your Cloud Run's services you can refer to the documentation provided, but in summary:
Most applications handle requests from end users, and it's a best practice to restrict access to only the allowed end users. In order to accomplish this, you can integrate Google Sign-In and grant users the roles/run.invoker IAM role, or implement Firebase Authentication and manually validate their credentials.
Note that Cloud Run does not assist in the sharing of sessions between container instances, thus not guarantying session affinity to a specific container instance.
Furthermore, here you will find further information regarding security tips in Cloud Run that can help you improve your Cloud Run service's security.
Finally, as Kolban said, you could also use Cloud Endpoints in order to limit the quantity and number of request per minute, as seen here. This will ensure that you will not be billed further that what you would like to.
You will find a complete list of other services that you can use with Cloud Run in order to improve not only the end-user experience but also your security.
I hope it helps.