You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately Pigeon.FCM currently expects the service_account_json to exist and contain a service account key file (containing a private key, and other sensitive info). To support this when running in Google Compute Engine, we'll have to then generate a service account key file with limited access to FCM only, and propagate it onto the hosts (to reuse the same service account as the host VM would be dangerous as it has more permissions). This could make the service accounts susceptible to file traversal/exfil issues, as opposed to the metadata approach, which would require Remote Code Exec on the host to steal.
Describe the solution you'd like
I'd like to be able to pass something like MyApp.Goth or MyApp.GothFCM to Pigeon that I've configured and initialized with goth for the service account and scopes necessary for Pigeon.
Pigeon could then pass it to Goth.fetch to gather the required token (since the Goth genserver handles refreshing by itself)
This would potentially simplify the Pigeon.FCM code significantly, and let it focus just on notifications, leaning on goth for the logic around the ways GCP auth has changed in the last couple years.
What are your thoughts? If you think this sounds neat, I can take a crack at a first-pass/proof-of-concept <3
The text was updated successfully, but these errors were encountered:
I have a working implementation of this if you'd like. It still requires some docs changes, and I wanted to chat about the scope of the change, but let me know if you have time to chat
If it works how I want in our production instance, I can open a PR w/ a checklist of things I'd need to do (docs, migration guide?, etc.) and questions we'd want to discuss (e.g. should service_account_json be supported still? if so, how? if not, do we need a migration guide, or an example? should the tests be made to be able to run without a real, live FCM auth setup, and then some integration tests?)
Hello! Thank you for your work on Pigeon. We appreciate it <3
(Note: This is in regards to 2.0.0-rc.1)
Skip to "Describe the solution you'd like" for the TL;DR
Is your feature request related to a problem? Please describe
We are in the process of cleaning up some application security things in Google Cloud, and are trying to eliminate the usage of the
GOOGLE_APPLICATION_CREDENTIALS
env var, and just rely on the metadata server accessible by the GCP VMs to get an access token (https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances#applications).goth
v1.3+ handles this as part of its initialization, or if called directly:and handles refreshing the token w/ scopes at init, and on a schedule:
it actually seems like the
goth
implementation may have been inspired from thepigeon
implementation:pigeon/lib/pigeon/fcm.ex
Line 220 in e5ca4be
Unfortunately
Pigeon.FCM
currently expects theservice_account_json
to exist and contain a service account key file (containing a private key, and other sensitive info). To support this when running in Google Compute Engine, we'll have to then generate a service account key file with limited access to FCM only, and propagate it onto the hosts (to reuse the same service account as the host VM would be dangerous as it has more permissions). This could make the service accounts susceptible to file traversal/exfil issues, as opposed to the metadata approach, which would require Remote Code Exec on the host to steal.Describe the solution you'd like
I'd like to be able to pass something like
MyApp.Goth
orMyApp.GothFCM
to Pigeon that I've configured and initialized withgoth
for the service account and scopes necessary for Pigeon.Pigeon could then pass it to
Goth.fetch
to gather the required token (since theGoth
genserver handles refreshing by itself)This would potentially simplify the
Pigeon.FCM
code significantly, and let it focus just on notifications, leaning ongoth
for the logic around the ways GCP auth has changed in the last couple years.What are your thoughts? If you think this sounds neat, I can take a crack at a first-pass/proof-of-concept <3
The text was updated successfully, but these errors were encountered: