[Bug]: Error fetching GCP Access Token - java.net.UnknownHostException: Host not allowed

[ravir2m2]

Is there an existing issue for this?

• I have searched the existing issues

Description

Context

We are evaluating Appsmith for building a custom solution for a customer. This will be a self-hosted installation with Appsmith deployed on GCP. It will use Postgres Database for storing the customers' objects which will be connected as datasource. We have a requirement to store, fetch, update some documents (Images, PDFs etc) in GCS.

Problem

To enable interaction with GCP Cloud Storage, I tried to create a simple curl-import API to fetch the access token from GCP's metadata server. What I have observed is that it throws a "java.net.UnknownHostException: Host not allowed" error. I have also tried this with a simple REST API database connector with no luck.

I ran a simple test with a curl command as shown below from the GCE VM as well as also the AppSmith container running on the same GCE VM; it seems to work fine. This only appears to be an issue from Appsmith application.

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Doing a code search on the repository, I found this PR #34250 which appears to disallow access to GCP's Metadata Server.

Could you please advise if there is a way to workaround this perhaps with an environment variable. Please note that is critical for us as this blocking the deployment of Appsmith. Could you please let us know if S3 data source connector is supported with GCS and has been tested.

Alternatively, we'd be forced to probably create a proxy REST API which seems to be an overkill and will increase the development time for us.

Environment

We are using the Docker container of appsmith/appsmith-ee:latest with image ID df6aca35b499. Additional details from Appsmith container logs are below for your reference

{
  "commitSha": "cc81d5df34d5109b317cf6703dc365d0a54aa20d",
  "commitUrl": "https://github.com/appsmithorg/appsmith-ee/commit/cc81d5df34d5109b317cf6703dc365d0a54aa20d",
  "githubRef": "refs/tags/v1.50",
  "githubRunUrl": "https://github.com/appsmithorg/appsmith-ee/actions/runs/12078597533/attempts/1",
  "version": "v1.50",
  "imageBuiltAt": "2024-11-29T03:51:08+00:00",
  "isCI": true
}

Please let me know if you need any further information

Steps To Reproduce

1. Deploy Appsmith on GCP using Docker-compose environment
2. Create a simple curl-import API to fetch the access token from GCP's metadata server with the following URL

curl -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

3. Same can be tried with a REST API as well

Public Sample App

No response

Environment

Release

Severity

High (Blocker to building or releasing)

Issue video log

No response

Version

Self Hosted - v1.50

[sharat87]

@ravir2m2, thanks for reaching out. This is by design. Requests to metadata.google.internal are blocked prevent SSRF attacks. The S3 datasource works with GCP and would be the recommended option to talk to GCS.

[ravir2m2]

@sharat87 - Thanks for your prompt response. Could you clarify if a specific SSRF vulnerability related to GCP necessitated this design decision? I understand that Google Cloud API authentication would occur server-side in Appsmith, not client-side via the browser—is that correct?

Additionally, I am exploring alternative methods for accessing Google Cloud APIs from Appsmith within a containerized setup, such as Kubernetes or Docker Compose on GCE VMs. Could you provide your insights on these options?
I can think of the following, can you please share your thoughts?

1. Workload identity on Kubernetes: This is the recommended security practice on GCP, but it seems to require access to the metadata server, which might be restricted as per the current design.
2. Using GCP's application default credentials: This approach involves setting the GOOGLE_APPLICATION_CREDENTIALS environment variable and mounting a service account key, which might be less secure.

Your input on these would be greatly appreciated.

[sharat87]

Hey, sorry for the delay, just seeing this.

Could you clarify if a specific SSRF vulnerability related to GCP necessitated this design decision?

An SSRF was identified and fixed for AWS' metadata service, and as part of that effort we identified this for GCP as well, and added it to the block list.

I am exploring alternative methods for accessing Google Cloud APIs from Appsmith

Which APIs do you have in mind? If it's a native integration, like Firestore, I'd recommend using that integration directly. If you want to call generic GCP's HTTP APIs directly from Appsmith, I'd recommend using an API key method to do this. Like AWS' Access key and secret access key.

I'm not very familiar with GCP, but from what I gather, they are methods to give the Kubernetes Node, permissions to hit the GCP APIs, right? That means any process on the node can now access those APIs. Correct?

If that is right, it is important to note that, that means any user on your Appsmith can now access those APIs. GCP can't differentiate an API call from one Appsmith application from another. This authentication method cannot give workspace-specific permissions. That's why an API key way of authentication (un-intuitively) ends up being more secure for Appsmith.