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
The last time I looked into this it's because you obviously need an actual key to sign, but Google Cloud's "Application Default Credentials" mechanism does not provide a "standard" way to fetch/generate a key for use by the clients of the metadata server.
This makes sense, and GCP likely never will implement this. It would require caching and regenerating keys constantly on their end, and just sounds like it would be a pain to maintain. It likely would not make people more secure anyway, and just lead to cached keys being reused by client applications, issuing signed URLs with invalidated keys :(
But that's fine, you're meant to use Service Account keys and manage them with Secrets Manager (or whatever system you choose for secrets) for that anyway. Signing is delegating access permissions in time and space, so any mechanism someone uses w/ goth will always rely on a Service Account key to do signing.
So we probably need to either accept an option called :signing_key, or explicitly call out that we're relying on the :json config key in goth to sign.
The docs for this should be specific on the permissions necessary to sign (storage.objects.get), and point people to Google's docs on limiting permissions to a service account w/ only those permissions.
Maybe we add an example "app" or two that use the "ADC" approach w/ a SA JSON Key for signing, and another for people using GCS, but not actually hosted w/ GCP? (not sure how many that is)
The last time I looked into this it's because you obviously need an actual key to sign, but Google Cloud's "Application Default Credentials" mechanism does not provide a "standard" way to fetch/generate a key for use by the clients of the metadata server.
This makes sense, and GCP likely never will implement this. It would require caching and regenerating keys constantly on their end, and just sounds like it would be a pain to maintain. It likely would not make people more secure anyway, and just lead to cached keys being reused by client applications, issuing signed URLs with invalidated keys :(
But that's fine, you're meant to use Service Account keys and manage them with Secrets Manager (or whatever system you choose for secrets) for that anyway. Signing is delegating access permissions in time and space, so any mechanism someone uses w/
goth
will always rely on a Service Account key to do signing.So we probably need to either accept an option called
:signing_key
, or explicitly call out that we're relying on the:json
config key ingoth
to sign.The docs for this should be specific on the permissions necessary to sign (
storage.objects.get
), and point people to Google's docs on limiting permissions to a service account w/ only those permissions.Maybe we add an example "app" or two that use the "ADC" approach w/ a SA JSON Key for signing, and another for people using GCS, but not actually hosted w/ GCP? (not sure how many that is)
Related:
The text was updated successfully, but these errors were encountered: