> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-gcp-117.md).

# Project level utilization of basic roles misconfiguration detected in code

## Rule Details

|                        |                           |
| ---------------------- | ------------------------- |
| Cortex AppSec Rule ID  | APPSEC\_GCP\_117          |
| Category - Subcategory | IAM - Overly Permissive   |
| Provider               | GCP                       |
| Severity               | HIGH                      |
| Framework              | Terraform, Terraform Plan |

## Impact

This rule, identified as APPSEC\_GCP\_117, belongs to the IAM (Identity and Access Management) category and is named "Ensure basic roles are not used at project level." This rule tries to ensure that basic roles, which are broad, pre-defined roles in Google Cloud Platform, are not being used at a project level.

This rule tries to enforce more granular, least privilege principles for policy making. Basic roles could allow for overly broad permissions, potentially enabling unauthorized access or actions within the project. Over granting permissions through the use of basic roles could lead to potential breaches in security and unnecessary vulnerabilities may be exploited by malicious users. Thus, it is bad practice to use these basic roles at the project level. It’s always a better security strategy to custom define roles with the least privileges necessary, and applying them to the appropriate users or groups.

## How to Fix

*Resource:* 'google\_project\_iam\_member', 'google\_project\_iam\_binding'

To fix this issue, you need to replace any use of basic roles at the project level with predefined or custom roles. Predefined roles cover all the possible services and actions that might be needed, while custom roles can be defined with the exact set of permissions necessary.

## The above code is secure because it follows the principle of least privilege, a key security concept which means giving a user the minimum levels of access necessary to complete his/her job functions. As a result, potential damage is limited even in the case of a breach. \[source,go]

## resource "google\_project\_iam\_member" "project" { project = "your-project-id" role = "roles/logging.viewer" # replace basic roles (e.g., roles/editor) with predefined or custom roles member = "user:<jdoe@example.com>" }


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://cortex-docs.paloaltonetworks.com/appsec-rules/iac-security/iam/appsec-gcp-117.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.