Which service account takes precedent when triggering a Cloud Function v2?

Question

I have a Cloud Function v2, which is configured to use a service account, [email protected]. This service account has permission to access all Secret Manager secrets within this project.

This Cloud Function is being triggered by PubSub via an Eventarc trigger. I noticed that the Eventarc trigger also has a service account attached, which is the default service account for the project [email protected].

I'm getting PERMISSION DENIED error messages when attempting to access the secret, even though the service account configured for the Cloud Function should have access to read the secret. I'm wondering if the Cloud Function is actually assuming the permissions of the account that is triggering it? Meaning that [email protected] is actually the account being used by the function?

I tried to confirm this by adding this code to my function:

    # Get the default credentials
    creds, project = google.auth.default()
    
    # If the credentials are a service account, print the email
    if isinstance(creds, service_account.Credentials):
        print("Service Account:", creds.service_account_email)
    else:
        print("Not using a service account")

It's showing that the function isn't using a service account.

Would I need to change the service account associated with the Eventarc trigger so that it matches the one configured for my Cloud Function?

EDIT:

To clarify, I was trying to retrieve the secret by calling this function.

def get_secret_key():
    client = secretmanager.SecretManagerServiceClient()
    response = client.access_secret_version(request={"name":"projects/PROJECTID/secrets/SECRETNAME/versions/1"})
    return response.payload.data.decode("UTF-8")

I've resolved my issue by setting the secret as an environment variable (set in the serviceConfig.secretEnvironmentVariables configuration of the Cloud Function) instead of trying to retrieve the secret at runtime.

Answer 1

Posting this as a community wiki so that others can benefit from it.

---

As mentioned by @guillaume blaquiere

The Cloud Functions runtime service account is this one you specify when you deploy your Cloud Functions. Share your deployment command line to show us this service account. The Cloud Functions can't assume another identity (i.e. service account email)when it is called by eventarc or any other services. Your piece of code works only when you have a service account key file, it won't work here.

---

Reference:

• Cloud Functions - Eventarc triggers