I have a firebase function which is pretty simple, it logs some debug messages and it makes a fetch after it checks if the user is logged in. It also requires the ability to read environment variables and use the secret manager.
In my GCP console, on the Cloud Run Services page, it recommends the following for this function: "[this service] is using the default Compute Engine service account. By default, this service account has broad IAM permissions.". I'd like to apply the principle of least privilege and heed this recommendation.
I know how to create a service account, I know how to create roles, and I know how to grant roles to that service account. However, I'm not sure what permissions I need to put in the new role so that my firebase function continues to work. https://firebase.google.com/docs/projects/iam/permissions is a sea of information. Trial-and-error isn't really an option since the function will be broken while I tinker, not to mention that this sounds like an exceptionally inefficient approach.
Depending on the desired functionality, the service account under discussion might need to get different IAM roles. The set of required roles significantly dependent on what APIs and what methods are being called by the cloud function with the given service account.
For example, to write into the log, the service account might need to get the 'roles/logging.logWriter' role. For error reporting - 'roles/errorreporting.writer'. For working (read/write) with the Firestore - 'roles/datastore.user'. To publish messages to a pubsub topic - 'roles/pubsub.publisher'. To run BigQuery jobs - 'roles/bigquery.jobUser' and so on (note - the service account might need additional roles to read the data).
You might like to go to relevant APIs documentation pages and find out what roles are required for methods you are using in the cloud function.
Bear in mind that roles are not only bounded to different resources (project, dataset, bucket, folder, pubsub topic, etc. ) but those resources might be in different projects as well. So the target project id is to be explicitly provided when a binding between the service account, the role and the resource happens. That might be especially important in case you have some CICD automation and all IAM happens during the deployment job run (and there should be difference in deployment and permissions for different environments - dev, test, prod, etc.)
== Updated with details for the comment:
Suppose my application runs on GCP, developed in Go, and it should write log entries. In this case I look into a page - Setting Up Cloud Logging for Go, then check the Run on Google Cloud paragraph, which states:
With the link to to a page, where I can find more details if required - roles/logging.logWriter
Another possible approach (can be used together with the above search) - to deploy the cloud function and check the logs to see errors and exceptions. I think, in the body of those errors, there should be some details and hints on the missing permissions.