fix: tf roles app sa

[eliasecchig]

No description provided.

[gemini-code-assist]

Summary of Changes

Hello @eliasecchig, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

I've made some adjustments to the default roles assigned to the application service account within the Terraform configurations. The primary goal of these changes is to ensure that the service account has the necessary permissions for specific deployment targets like Cloud Run, and to generally facilitate broader service usage. I've also refined the conditional logic for existing roles to ensure they are applied more accurately based on the project's configuration.

Highlights

• Cloud Run Invoker Role: I've conditionally added the roles/run.invoker permission to the application service account. This role is crucial for applications deployed on Cloud Run to be able to invoke other Cloud Run services. This permission will only be applied when the cookiecutter.deployment_target is set to 'cloud_run'.
• Service Usage Consumer Role: I've added the roles/serviceusage.serviceUsageConsumer role to the default list of permissions for the application service account. This role allows the service account to enable and disable Google Cloud APIs and services, which can be necessary for various application functionalities.
• Secret Accessor Role Logic Refinement: I've adjusted the conditional logic for the roles/secretmanager.secretAccessor permission. Previously, its inclusion was tied to a broader condition. Now, it is explicitly and solely dependent on whether the cookiecutter.session_type is set to "alloydb", ensuring more precise role assignment.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments or fill out our survey to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the IAM role assignments for the application service account in the Terraform templates. The changes correctly associate the roles/secretmanager.secretAccessor role with the alloydb session type and roles/run.invoker with the cloud_run deployment target. A new role, roles/serviceusage.serviceUsageConsumer, is also added. My review focuses on the security implications of the assigned roles. While the logic fixes are correct, some of the roles are granted at the project level, which is overly permissive. I've added comments suggesting to scope down the roles/run.invoker and roles/secretmanager.secretAccessor permissions to specific resources to adhere to the principle of least privilege.

[gemini-code-assist]

While these roles are necessary for their respective features, granting them at the project level is overly permissive and goes against the principle of least privilege.

• roles/run.invoker: This allows the service account to invoke any Cloud Run service in the project. It should be scoped to specific services that the application needs to call.
• roles/secretmanager.secretAccessor: This allows the service account to access any secret in the project. It should be scoped to the specific secrets required by the application.

Consider parameterizing the specific resource names (services, secrets) and applying IAM roles on those resources directly (e.g., using google_cloud_run_v2_service_iam_member or google_secret_manager_secret_iam_member) instead of using project-level google_project_iam_member.