Truffle Security recently reported that, depending on certain GCP configurations, existing public keys can now be used to access the Gemini API, potentially allowing access to sensitive data or allowing financial DOS attacks:
https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules
This issue happens when:
1 – A GCP Project has at least one existing key that is published somewhere (E.g., firebase or google maps key)
2 – That key is not restricted to any specific APIs
3 – The Gemini API is enabled in that project
If you have a large GCP organization, it is not feasible to manually check every project for these conditions. To automate this task, I created a small script that will list all keys that belong to projects with the Gemini API enabled.
It does not filter by key restriction configurations, but these are shown. It is then up to you to analyze if the restrictions are enough to prevent gemini usage, and where/how each key is being used.
You can run this script directly from GCP’s cloud shell. Just put it into a file (touch script.sh, then nano script.sh and paste it, then chmod +x script.sh) and run it (./script.sh). Ah, and don’t forget to replace ORG_ID_HERE with your organization’s ID.
ORG_ID=<ORG_ID_HERE>
PROJECTS=$(gcloud alpha projects list --format="value(projectId)" --organization=$ORG_ID)
for PROJECT in $PROJECTS; do
geminienabled=$(gcloud services list --enabled --project=$PROJECT | grep "generative")
if [[ -n "$geminienabled" ]]; then
keys=$(gcloud services api-keys list --project=$PROJECT --format=json)
if [[ -n "$keys" && "$keys" != "[]" ]]; then
echo "=== Project $PROJECT has Gemini enabled and at least one API key ==="
echo "$geminienabled"
echo "$keys"
fi
echo ""
fi
done
Have fun!
Views: 1