I have no idea why, but I am running gcloud auth login, I have tried beta and application-default. All of them do not create the file: ~/.config/gcloud/credentials, instead I can find ~/.config/gcloud/legacy_credentials.
The issue I am having is that the library I am using does not want legacy_credentials, and renaming the folder did not work.
Here are my settings:
Google Cloud SDK 183.0.0
alpha 20
17.12.08
beta 2017.12.08
bq 2.0.27
core 2017.12.08
gsutil 4.28
Also I am using Ubuntu 16.04.3 LTS on digitalocean. I will be glad to supply any other information I can think of.
The credentials in the legacy folder contain:
" ============================================================================
" Netrw Directory Listing (netrw v155)
" /root/.config/gcloud/legacy_credentials/matt#mindbrainhive.org
" Sorted by name
" Sort sequence: [\/]$,\<core\%(\.\d\+\)\=\>,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
" Quick Help: <F1>:help -:go up dir D:delete R:rename s:sort-by x:special
" ==============================================================================
../
./
.boto
adc.json
gcloud no longer uses ~/.config/gcloud/credentials, instead it stores credentials in sqlite3 ~/.config/gcloud/credentials.db.
These credentials files are considered internal to gcloud, they can change at any time. You should not be using them. What you likely want to use is
gcloud auth application-default login
instead of gcloud auth login. The former will create ~/.config/gcloud/application_default_credentials.json key file for user logged in account.
That said depending what you trying to do you probably want use service accounts (instead of user account). You can create the key file via
gcloud iam service-accounts keys create
See documentation for more info. Or you can use Google Cloud Platform Console to create key file.
Once you obtain json key file you can use it in your application as application default credentials, see https://developers.google.com/identity/protocols/application-default-credentials#howtheywork
You can also use this key in gcloud by using gcloud auth activate-service-account command.
Related
The problem: we have several servers that need to reference the same Google Cloud SDK credentials and we want to reference those credentials from a central location. What is the easiest way to share these credentials between several servers?
What we tried: we tried to create soft and hard symbolic links to the gcloud directory but we did not have success, in both cases we received the following error message:
C:\Users\Redacted\AppData\Local\Google\Cloud SDK> bq ls
WARNING: Could not open the configuration file: [C:\Users\Redacted\AppData\Roaming\gcloud\configurations\config_default].
ERROR: (bq) You do not currently have an active account selected.
Found the answer... use the below commands for the two files below to make a soft symbolic link to centralize credential files, not the gcloud directory itself:
mklink access_tokens.db
mklink credentials.db
I have installed the Cloud SDK for Google Cloud. I've logged in using auth which redirected me to the gmail-login. Created the SSH key and even logged in by SFTP using Filezilla.
The problem is, when I log in using the gmail auth, SDK shell (or putty?) logs me into an account that is not admin. It has created another SSH user account (named 'Acer', after my pc) and logs me into it. Due to this, FTP starts at the /home/Acer folder. I want access to the /home/admin/web folder, but I don't have it now.
How can I create a SSH key for the admin account so that I can gain access to the folder mentioned above? Otherwise, is it possible to grant 'Acer' the permissions to access all the folders?
I have a few suggestions.
First a bit of background. If you run this command on your home workstation:
sudo find / -iname gcloud
You'll discover a gcloud configuration folder for each user on your home workstation. You'll probably see something like this:
/root/.config/gcloud
/home/Acer/.config/gcloud
If you change directory into /home/Acer/.config/gcloud/configurations you'll see a file named 'config_default'. This file will contain the default account to use for that user ('Acer').
Because you have performed gcloud auth login as that user, and during that process selected your gmail account, it will contain that gmail ID/account within the config file for that user. If you would like a user named 'admin' to log into your project, you could try adding a user named 'admin' to your home workstation, and then before attempting to use gcloud auth login, ensure you switch user on your home workstation to user 'admin'. This will generate a gcloud configuration on your home workstation for user admin, and propagate SSH keys etc.
If you want to create ssh keys manually there's some useful info here.
(For what it's worth, if you decide to use gcloud compute ssh to log into your instance home workstation, you can specify the user in the command you would like to log in as. For example gcloud compute ssh admin#INSTANCE_NAME).
I want access to the /home/admin/web folder, but I don't have it now.
Even if you are logged into the machine as a different user (in this case 'Acer'), the folder /home/admin/web should still exist on the instance if it existed previously. If you land in folder /home/Acer have you tried changing directory to the folder above and then listing the folders to see if /home/admin/ exists?
For example, from /home/Acer run:
$ cd ..
then
$ ls
You should be able to see /home/admin/.
Otherwise, is it possible to grant 'Acer' the permissions to access
all the folders?
Yes this is also possible. If you access the instance as the project owner (the easiest way would be to log into the Console as the owner of the project and use the SSH functionality in the console to access the instance). Now you can run this command:
$ sudo chown Acer.Acer -R /home/admin/web
This will make user 'Acer' owner of directory /home/admin/web and all files/directories below it (thanks to the -R switch).
Now when you next access the instance as user 'Acer' you'll be able to access /home/admin/web by running the following and you'll also have read/write capabilities:
$ cd /home/admin/web
gsutil was working as a stand-alone on my system.
Then I installed SDK, including some authentication stuff.
Now gsutil says my credentials are invalid.
$ gcloud auth login wolfvolpi#gmail.com
WARNING: `gcloud auth login` no longer writes application default credentials.
If you need to use ADC, see:
gcloud auth application-default --help
You are now logged in as [redacted].
Your current project is [redacted]. You can change this setting by running:
$ gcloud config set project PROJECT_ID
$ gsutil ls
Your credentials are invalid. Please run
$ gcloud auth login
How to set my credentials so that gsutil runs again?
$ gcloud version
Google Cloud SDK 146.0.0
core 2017.02.28
core-nix 2017.02.28
gcloud
gcloud-deps 2017.02.28
gcloud-deps-linux-x86_64 2017.02.28
gsutil 4.22
gsutil-nix 4.22
If you previously had gsutil configured with credentials, it is possible that it is picking up those old credentials that will no longer work in the Cloud SDK mode. Take a look in your boto file (typically at ~/.boto) and remove any credentials found in there.
You can see the list of the valid fields in the boto file here: https://cloud.google.com/storage/docs/gsutil/commands/config#additional-configuration-controllable-features
The marked solution did not work sometimes. But You can create a new configure setting by using the
gcloud init
Welcome! This command will take you through the configuration of gcloud.
Settings from your current configuration [old config file's name] are:
core:
account: [account]
disable_usage_reporting: 'True'
project: [projectname]
Pick configuration to use:
[1] Re-initialize this configuration [old config file's name] with new settings
[2] Create a new configuration
[3] Switch to and re-initialize existing configuration: [default]
Please enter your numeric choice:
Then you can use option 2 to create new configuration. Try this will work these who not able to done using the above solution.
Also this will work when someone cannot use gsutil cors set [filename].json gs://[BucketName] command to set CORS.
Then try again.
As anyone who has ever had the misfortune of having to interact with the panoply of Google CLI binaries programmatically will have realised, authenticating with the likes of gcloud, gsutil, bq, etc. is far from intuitive or trivial, especially when you need to work across different projects.
I am running various cron jobs that interact with Google Cloud Storage and BigQuery for different projects. Since the cron jobs may overlap, renaming config files is clearly not an option, and nor would any sane person take that approach.
There must surely be some sort of method of passing a path to a service account's key pair file to these CLI binaries, but bq help yields nothing.
The Google documentation, while verbose, is largely useless, taking one on a tour of how OAuth2 works, etc, instead of explaining what must surely be a very common requirement, vis-a-vis, how to actually authenticate a service account without running commands that modify central config files.
Can any enlightened being tell me whether the engineers at Google decided to add a feature as simple as passing the path to a service account's key pair file to the likes of gsutil and bq? Or perhaps I could simply export some variable so they know which key pair file to use for authentication?
I realise these simplistic approaches may be an insult to the intelligence, but we aren't concerning ourselves with harnessing nuclear fusion, so we needn't even consider what Amazon got so right with their approach to authentication in comparison...
Configuration in the Cloud SDK is global for the user, but you can specify what aspects of that config to use on a per command basis. To accomplish what you are trying to do you can:
gcloud auth activate-service-account foo#developer.gserviceaccount.com --key-file ...
gcloud auth activate-service-account bar#developer.gserviceaccount.com --key-file ...
At this point, both sets of credentials are in your global credentials store.
Now you can run:
gcloud --account foo#developer.gserviceaccount.com some-command
gcloud --account bar#developer.gserviceaccount.com some-command
in parallel, and each will use the given account without interfering.
A larger extension of this is 'configurations' which do the same thing, but for your entire set of config (including settings like account and project).
# Create first configuration
gcloud config configurations create myconfig
gcloud config configurations activate myconfig
gcloud config set account foo#developer.gserviceaccount.com
gcloud config set project foo
# Create second configuration
gcloud config configurations create anotherconfig
gcloud config configurations activate anotherconfig
gcloud config set account bar#developer.gserviceaccount.com
gcloud config set project bar
And you can say which configuration to use on a per command basis.
gcloud --configuration myconfig some-command
gcloud --configuration anotherconfig some-command
You can read more about configurations by running: gcloud topic configurations
All properties have corresponding environment variables that allow you to set that particular property for a single command invocation or for a terminal session. They take the form:
CLOUDSDK_<SECTION>_<PROPERTY>
for example: CLOUDSDK_CORE_ACCOUNT
You can see all the available config settings by running: gcloud help config
The equivalent of the --configuration flag is: CLOUDSDK_ACTIVE_CONFIG_NAME
If you really want complete isolation, you can also change the Cloud SDK's config directory by setting CLOUDSDK_CONFIG to a directory of your choosing. Note that if you do this, the config is completely separate including the credential store, all configurations, logs, etc.
we had configured standalone gsutil on a remote server, however we do not have access to the server anymore. How do we revoke access provided to gsutil on that server. The .boto file will have the refresh Oauth2.0 token.
we do not have access to the server and so cannot remove .boto file.
The project configured is active in our console but we cannot see any specific access in permissions section.
A standalone gsutil script was installed (not gcloud).
Use gcloud auth revoke.
https://cloud.google.com/sdk/gcloud/reference/auth/revoke
The .gsutil directory just gets recreated within 10 seconds for me.
OK we can revoke access to gsutil from account permissions through this link:
https://security.google.com/settings/security/permissions
screenshot for Google Security Permissions Page
Just remove credstore files.
rm -rf ~/.gsutil/