-
Notifications
You must be signed in to change notification settings - Fork 373
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Is it possible to use impersonated service account? #1861
Comments
I found a few problems with this issue:
|
Hey @blue-hope Thank you for your feature request and the PR! I am looking into this now. Thank you for your patience! |
@lahirumaramba Are there any updates? |
Hello, any chance to get that reviewed ? It will helps a lot to reduce the risk of generating a json key. |
This is fixed in #1862 and now included in the v11.5.0 release. Thanks folks for your patience on this! Try out the new feature if you get a chance and let us know what you think. |
Hi @blue-hope ! Thanks for working on this! Could you let me know what your I'm initializing firebase like this:
But I get the following error:
|
+1 |
Hello, you need to authenticate as a service account, not an end-user. Of course your end-user will need specific permission like Service Account User on the impersonated service account |
Hey @Klaitos , that's what i have been doing but without luck. I'm impersonating the firebase service account that has the following permissions: |
Hum yes you're right, it does not simply work on my local computer either. |
@blue-hope i think we might need your help on this one. I tried some code on my laptop, it works when we tweak the function const auth = new GoogleAuth({
scopes: 'https://www.googleapis.com/auth/cloud-platform',
});
const client = await auth.getClient();
const json = await client.getAccessToken()
if (!json.token || !json.res?.data.expireTime) {
throw new FirebaseAppError(
AppErrorCodes.INVALID_CREDENTIAL,
`Unexpected response while fetching impersonated access token: ${JSON.stringify(json)}`,
);
}
return {
access_token: json.token,
expires_in: new Date(json.res.data.expireTime).valueOf() - new Date().valueOf()
} but i'm not aware of unexpected consequences |
It looks like we are not handling the token creation for impersonated accounts correctly here:
Looking at the implementation in The proper fix for this is to migrate Admin SDK credentials handling logic to use This is part of the reason for @Klaitos's workaround above to work, as it creates a new We are currently doing the initial planning for credentials migration to |
Sorry for my naive approach for getting access token. |
It's not that simple because you need to call the route |
Folks, is there an open issue tracking this? It seems like a huge problem that firebase doesn't work out of the box with Google's Recommended Security Practices for Service Accounts. |
Can we re-open this please? |
I implemented a workaround to do service account impersonation in https://gist.github.com/lox/8bff5607c3e713c92a03a631796ab3f3. |
Any updates on this? Is @lox workaround still the only way? gcloud's documentation goes into incredible depth of why service accounts are risky but there's no official implementation for service account impersonation in firebase admin. |
Hey @velocd we have made some changes internally to migrate credentials handling to use |
Is your feature request related to a problem? Please describe.
maybe related to #1703
I think It is not natural for the client to always have the service account json file, and I want to access the firebase admin through impersonate service account generated by
gcloud auth application-default login --impersonate-service-account=
which the service account has permission for generating custom token.However, when I use the service account which now stored in ADC, firebase admin throws an error
message: 'Refresh token must contain a "client_id" property.'
.In fact, the impersonate service account does not have a client_id itself, but it is contained in source_credentials like:
Describe the solution you'd like
When checking ADC's service account, if type is
impersonated_service_account
, then checksource_credentials
.Describe alternatives you've considered
I can manually get my service account from ADC and use 'source_credentials'. But is it really the only solution for checking impersonated service account?
Additional context
No additional context
The text was updated successfully, but these errors were encountered: