WIP: Improve authentication instructions in provider documentation #156
Conversation
The current instructions (using `gcloud auth login`) do not seem to work : the application seems unable to pick it, and leads to the following error : ``` Error: failed to load config: failed to create client: google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information. ``` Instead, using `gcloud auth application-default login` uses a similar login process (open a browser window to allow the login, etc), but instead sets the resulting creds as ADC.
toadjaune
changed the title
|
After further testing, it seems authenticating with I see 2 options there :
Could someone who got it working at some point please provide an example configuration for this setup ? :) |
| `GOOGLE_KEYFILE_JSON`, `GOOGLE_APPLICATION_CREDENTIALS` environment variables. | ||
| You can also use [application default credentials](https://cloud.google.com/docs/authentication/production) | ||
| by letting all of those empty. To test using your personal account, you can | ||
| set it as application default credentials with `gcloud auth application-default login` |
There was a problem hiding this comment.
I think it's better to use the same wording as hashicorp/terraform-provider-google, not the test premise.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
DeviaVir
added
enhancement
|
@sioncojp as mentioned in the text above, the proposed change doesn't actually work (I initially thought it did though), I'll have to figure out how to make it work before updating the docs. |
|
Can anyone who got the authentication working with a user account (not a service account) please provide an example configuration ? I was unable to get it working on my side. @DeviaVir maybe ? |
|
@toadjaune what error message did you hit RE:
|
|
Unfortunately I don't have my test setup anymore, I'll set it up again in the weeks to come, to provide detailed config examples and corresponding error messages. |
|
Hi again, here is a minimal example : According to the documentation, this should work. Instead, I get this : I tried various other configurations (notably, with OAuth scopes), with the same result. This error tends to make me believe that the gsuite provider is not able to leverage the user auth configured by Next try, I logged in using Now, the plan works as expected, but an apply fails : By setting TF_LOG=DEBUG, we can get some interesting information : Interestingly, we get the required scopes for this request (scope="https://www.googleapis.com/auth/admin.directory.user https://www.googleapis.com/auth/directory.user"), but even retrying explicitly specifying those scopes, with a super-admin user, gives the same result. I tried a few other operations (importing an existing user, for example) with the same result. One last interesting log I had in debug mode : before creating the user, we check if it exists. Here is the corresponding log : I don't know what to make of this. Is it even possible to make any modification through the API with a user ? Or do we have to use a service account ? Or maybe I just failed to configure my quota project ? At this point I'm thinking of creating a user through the console, and capture the corresponding traffic. |
|
In the error you post above it says:
I'm curious if Otherwise, using a service account (as suggested above) is probably easier, this is what I know other customers use successfully. |
|
I tried various ways of setting the quota project, such as :
None of them seem to change anything. It would seem that this API is indeed not usable at all from a user account. I guess I'll switch to using a service account, which is cleaner on the principle anyway. The only issue I have with this setup is that permissions given to terraform allow taking over the entire organization (by impersonating a super-admin and resetting their password), which I'd rather avoid. I'll check if it is indeed the case. Now, regarding this issue. If we agree that using this provider with a user account is apparently impossible, how about reflecting it in the documentation ? I don't think any API change is required, since both |
|
Actually, we're gonna need to make changes bigger than that, as I have great news : It's now possible to give admin permissions directly to a service account in GSuite \o/ I just started testing this new setup, but it seems to work just fine so far (letting Extra testing will be required, but so far I tend to believe that we should make the following changes :
What do you think ? |
The current instructions (using
gcloud auth login) do not seem to work : the application seems unable to pick it, and leads to the following error :Instead, using
gcloud auth application-default loginuses a similar login process (open a browser window to allow the login, etc), but instead sets the resulting creds as ADC.If the code in its current state is meant to be able to pick user credentials set with
gcloud auth login, I was not able to understand how. In this case, I suppose the documentation would benefit on extra details on this setup.