0

I have a very similar question to this one. @cherba already gave a very rich and helpful dissection of the gcloud init command which has been very helpful.

So what I really want to do, automating gcloud init is:

  • Front load my interactive input: I want the users to supply all input at the beginning and not be prompted again.
  • Request a token, before gcloud is even installed, probably from a static perma-link, the resulting token should be usable only once, probably with a limited lifetime, maybe an hour. This is very similar to how gcloud init —-console-only already works, except with an unchanging initial URL.
  • I specifically want this to be for a user account, not a service account.

This would allow me to prompt the user, upfront, for all configuration input, and build the fully configured system automatically, over lunch or a long coffee break; not needing additional babysitting.

The goal here is distinct development environments, not deploying to an array of boxes.

How can I accomplish this?

Loren Osborn
  • 131
  • 6
  • I understand you want a fully automated process provided by Google. In the meantime, one way of doing this for your local team would be to create custom script that asks for all config input, create config based on input, have the developer use that config whenever using gcloud. This would remove the need to do this for every installation. You have probably thought of this yourself, but thought I would post for everyone. – ZUKINI Jan 08 '20 at 16:41

2 Answers2

2

This is not supported officially and is not recommended. Service accounts are meant for this kind of thing. You should use service accounts as explained in the earlier answer.

What the SDK is essentially doing is submitting a token request to https://accounts.google.com/o/oauth2/auth with following scopes:

'https://www.googleapis.com/auth/userinfo.email'
'https://www.googleapis.com/auth/cloud-platform'
'https://www.googleapis.com/auth/appengine.admin'
'https://www.googleapis.com/auth/compute'
'https://www.googleapis.com/auth/accounts.reauth'

For this to succeed you need to provide the regular oauth parameters like client_id, client_secret. To generate these you will need to register your app as an oauth app in the developer console.

This may not work if third party authorizations are not supported. I have not tried it.

Kunal Deo
  • 2,248
  • 2
  • 18
  • 27
  • While I may capture user credentials for setting up something like an email client (which I agree is a bad idea), I had no intention of requesting a user’s gcloud credentials. If you’ve used `gcloud init —console-only` you’ll see its workflow is roughly: Generate a URL that the user opens in their browser. I presume this includes a nonce or something similar. The user goes to this URL, authenticates and gets a single-use token to setup their `~/.config/gcloud` directory. This token is them pasted back to `gcloud init`. As this token is useless after ingestion, I see no risk from retention. – Loren Osborn Nov 22 '19 at 15:39
  • I see. Let me modify my answer. – Kunal Deo Nov 22 '19 at 15:50
  • Kunal, thank you for your quick reply. I look forward to reading your updated answer. – Loren Osborn Nov 22 '19 at 15:52
1

You said "Front load my interactive input:" and also "Request a token, before gcloud is even installed". The problem with your request above, is that you will need to install gcloud at some point in time and gcloud will use its own authentication methods to connect, meaning that authentication should happen after gcloud is installed because you will always use the command “gcloud ….” to somehow connect. The previous post that you linked explains this.

Due to this, I'm suspecting that you need a workflow where simultaneous gcloud commands will run on multiple users/projects at the same time, by running gcloud many times in parallel. As you know, Linux runs one command at a time and "front loading" the authentication (as you call it) can either be the "screen" command inside one SSH session or running multiple SSH sessions at the same time. If that's not what you need, then a simple shell script should do. The shell script will run commands one after the other rather than in parallel.

For example, let's say that you want to install a package that will take a long time and be able to run another command at the same time, then you could do the following:

$ screen 
$ sudo apt-get install [package-name]

Press Ctrl-A” and “d“ to temporarily exit this session

$ … (do another process here)
$ screen -r (re-attaches screen to continue on previous process on line 2)

The example above is somewhat the equivalent of having multiple SSH sessions open at the same time. You could maybe open multiple “screens” and launch multiple authentications at the same time, thereby also controlling when you want to stop a session. Keep in mind that if you run things in parallel, you will definitely need to load the authentication file as mentioned in the post you linked. Otherwise, you can use simple shell scripting and pass arguments. Since i'm not sure of the process that comes before/after your authentication, it's hard for me to provide a more precise example. There's a lot to consider and many unknowns about your workflow. I've included references below that show all the possibilities.

References: - https://www.linode.com/docs/networking/ssh/using-gnu-screen-to-manage-persistent-terminal-sessions/ - https://www.geeksforgeeks.org/screen-command-in-linux-with-examples/ - https://www.lifewire.com/pass-arguments-to-bash-script-2200571 - https://cloud.google.com/sdk/gcloud/reference/auth/activate-service-account - https://cloud.google.com/sdk/gcloud/reference/auth/login - https://cloud.google.com/sdk/docs/scripting-gcloud

Alexis
  • 26
  • 5
  • I will try and respond with more depth later, but your understanding of my use cases is incorrect: 1. In most cases, I have no intention of running this tool in parallel. 2. The only plausible exception to this would be multiple engineers joining our project at the same time, and they would each be signing in with their own IDs and authentications 3. Besides a new engineer joining our project, the primary use of this automation would be for an engineer to discard and recreate a dev environment that may have gotten stale or corrupt. – Loren Osborn Dec 08 '19 at 19:19
  • To put it in perspective, let's imagine gcloud being a website. Your request is like saying that you want to log outside the website somehow and then pass the connection to the website even if the website doesn't exist (because gcloud hasn't been installed yet). And to do this for multiple users. Meanwhile, the design of the website requires you to login after it exists only, without external input. You will have to work with the gcloud installation (view last link I posted), in order to switch different users. You may or may not use screen, depending on your workflow for "front-loading". – Alexis Dec 09 '19 at 14:14
  • Yes, I understand *WHY* this workflow isn’t currently supported, and why it isn’t obvious how to do it, but I think I have shown a practical use case of why this makes sense to support, and it isn’t very different from what is already supported. If the user’s script generates their own nonce, passed as a GET parameter to google’s authentication mechanism (possibly with a regex for expected usernames) I see no negative security implications to GCloud authenticating with a one-time use token with a < 1 hour TTL, that `gcloud init` could redeem after gcloud is installed. – Loren Osborn Dec 09 '19 at 14:38
  • ... especially since `gcloud init —console-only` already does something so similar. – Loren Osborn Dec 09 '19 at 14:39
  • I understand your point of view. You sort of want to "hack" the gcloud SDK and make it go above and beyond it's regular functionality. Don't get me wrong, I really like the innovative mindset you have. And even though I cannot help you with that, I am merely pointing out, that even under that mindset, you would still need to have gcloud installed. This is the major block in your workflow. You cannot alter gcloud functions, without having it installed. The screen command is just there to juggle multiple logins at the same time (if that's what's needed, but that's a second issue). – Alexis Dec 10 '19 at 13:16
  • ... unless gcloud allowed me to supply a nonce that I generated myself. It’s somewhat of a nitch case, but something gcloud **could** support. Of course, someone on the gcloud team would have to **add** support for it. – Loren Osborn Dec 11 '19 at 15:14
  • 1
    Thanks Loren. This is definitely a feature idea! The original post started the conversation a bit differently and I didn't think about the specific possibility of a nonce. I just noticed that you also mentioned "nonce" in another response outside my answer. This is definitely a valid idea and there is an article for that process of feature requests located here: https://cloud.google.com/support/docs/issue-trackers – Alexis Dec 12 '19 at 17:01