Restrict list of projects shown in project picker based on user access

[elamcheliyan]

trafficstars

Description:

The API returns sensitive data to the client by design. This data is filtered on the client side before being presented to the user. An attacker can easily sniff the traffic and see the sensitive data.

Excessive data exposure occurs when the API retrieves more data than what seems to be required by the GUI or when an unusual amount of data is retrieved beyond what appears to be required.

Endpoint: /api/projects The above endpoint retrieves and lists all the projects on the front end rather than listing only the relevant projects for which the user has any role bindings. Is there a way to restrict the data and provide only the relevant projects_id to the front end based on the user-eligible role for the projects?

Code investigation: @Override public SortedSet<ProjectId> listProjects( UserId user ) throws AccessException, IOException { if (Strings.isNullOrEmpty(this.options.availableProjectsQuery)) { // // Find projects for which the user has any role bindings (eligible // or regular bindings). This method is slow, but accurate. // return this.repository.findProjectsWithEntitlements(user); } else { // // List all projects that the application's service account // can enumerate. This method is fast, but almost certainly // returns some projects that the user doesn't have any // entitlements for. Depending on the nature of the projects, // this might be acceptable or considered information disclosure. // return this.resourceManagerClient.searchProjectIds( this.options.availableProjectsQuery); } }

//--------------------------------------------------------------------------- // ProjectRoleRepository. //---------------------------------------------------------------------------

@Override public @NotNull SortedSet<ProjectId> findProjectsWithEntitlements( @NotNull UserId user ) { // // Not supported. // throw new IllegalStateException( "Feature is not supported. Use search to determine available projects");

[jpassing]

The behvior difffers based on which catalog you're using.

• If you use the PolicyAnalyzer catalog, the project picker (and underlying listProjects endpoint) defaults to only returning projects that the user actually has access to.

  As the comment in the code suggests, quering the Policy Analyzer API to determine those projects is accurate, but slow. That's why you can opt out of that behavior by configuring the AVAILABLE_PROJECTS_QUERY option.

  One caveat of using the PolicyAnalyzer catalog is that it requires an SCC subscription.

• If you use the AssetInventory catalog, then the behavior is equivalent to using the PolicyAnalyzer catalog with the AVAILABLE_PROJECTS_QUERY option.

There's a trade-off, but you do have the option to restrict output to relevant projects for which the user has the necessary role bindings.

[elamcheliyan]

Thanks for the information. Let us configure this and test. We will get back to you in case we need any further support.

On Tue, 23 Jul 2024, 04:37 Johannes Passing, @.***> wrote:

The behvior difffers based on which catalog you're using https://googlecloudplatform.github.io/jit-access/configure-catalogs/.

If you use the PolicyAnalyzer catalog, the project picker (and underlying listProjects endpoint) defaults to only returning projects that the user actually has access to.

As the comment in the code suggests, quering the Policy Analyzer API to determine those projects is accurate, but slow. That's why you can opt out of that behavior by configuring the AVAILABLE_PROJECTS_QUERY option https://googlecloudplatform.github.io/jit-access/configuration-options/#:~:text=AVAILABLE_PROJECTS_QUERY .

One caveat of using the PolicyAnalyzer catalog is that it requires an SCC subscription.

If you use the AssetInventory catalog, then the behavior is equivalent to using the PolicyAnalyzer catalog with the AVAILABLE_PROJECTS_QUERY option.

There's a trade-off, but you do have the option to restrict output to relevant projects for which the user has the necessary role bindings.

— Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/jit-access/issues/443#issuecomment-2243958720, or unsubscribe https://github.com/notifications/unsubscribe-auth/APUA5IMSNE7BYPE6OPROIT3ZNWGCHAVCNFSM6AAAAABLID3KMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBTHE2TQNZSGA . You are receiving this because you authored the thread.Message ID: @.***>

[elamcheliyan]

Hi @jpassing

If we configure RESOURCE_CATALOG: "PolicyAnalyzer" then listing projects is looking in the policy analyzer repository(jit-access/sources/src/main/java/com/google/solutions/jitaccess/core/catalog/project/PolicyAnalyzerRepository.java)

I have a question. We have been using 1.6 and setup was done with AssetInventory catalog. I changed to PolicyAnalyzer without changing service account bindings(roles/resourcemanager.projectIamAdmin and roles/cloudasset.viewer). Will there be any deviation in the listing project and other functionalities?

[jpassing]

You don't need to change any role bindings when switching catalogs.

The only significant functional difference between the two is that the PolicyAnalyzer catalog supports nested group memberships, while the AssetInventory catalog ignores nested groups. So the PolicyAnalyzer catalog is actually slightly more capable. The only reason the PolicyAnalyzer catalog isn't the default anymore is the SCC dependency.

[jpassing]

I guess this is resolved? Otherwise please reopen the issue.