gcloud project id in node.js error is different from gcloud set project id? - google-cloud-platform

I'm trying to get Google Cloud Vision to work with node.js by following their documentation here. Although I keep getting:
PERMISSION_DENIED: Cloud Vision API has not been used in project 5678.. before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/vision.googleapis.com/overview?project=5678.. then retry
To note though the project number is very different from what I see in gcloud's output when I gather information from the following commands:
gcloud info |tr -d '[]' | awk '/project:/ {print $2}'
'my-set-project' <=== set project id in use
gcloud projects list
which outputs:
PROJECT_ID='my-set-project' // <=== Same id as "gcloud info" command
NAME='my-project-name'
PROJECT_NUMBER=1234.. // <===== Different number from Node.js Error
I have already enabled the api, downloaded a service key and setup the export GOOGLE_APPLICATION_CREDENTIALS=[path/to/my/service/key]. But right now I believe that the service key linkup is not the issue yet as I have not yet really have had gcloud pointing to 'my-set-project'.
I have also found a default.config at
cat /Users/My_Username/.config/gcloud/application_default_credentials.json
which has:
{
"client_id": "5678..-fgrh // <=== same number id as node.js error
So how can I get gcloud-cli to switch to project "1234" which has the API enabled there? I thought doing the command:
gcloud config set project 'my-set-project'
would get running node apps using gcp to use the project of '1234' instead of the default '5678'. Any help will be appreciated as I'm still getting used to the gcloud-cli. Thanks

Try:
gcloud auth activate-service-account --key-file=/path/to/your/service_account.json

Related

Issue on GCP Kubernetes cluster connectivity from local (Windows 10)

I have two projects in GCP i.e. Project A and Project B. Project A has Cluster CA and Project B has Cluster CB. Now I have configured my local environment [ Windows 10 ] with Gcloud CLI and Kubetel to connect to environment. Usigng "gcloud init" command I am able to initialize context and able to connect to Project A and Cluster CA. and on executing "kubectl get pods" showing the pods in cluster CA.
Now I am trying to connect Cluster CB in project B. I am doing "gcloud init" re-configuration and selecting Project B. but now when I am executing "kubectl get pods", system is showing pods from cluster CA not from cluster CB.
Could you please help me with the steps to connect and get the details from cluster CB
C:\Program Files (x86)\Google\Cloud SDK>gcloud init
Welcome! This command will take you through the configuration of gcloud.
Settings from your current configuration [default] are:
accessibility:
screen_reader: 'True'
core:
account: ajoy.sinha#abc.com
disable_usage_reporting: 'True'
project: Project B
Pick configuration to use:
[1] Re-initialize this configuration [default] with new settings
[2] Create a new configuration
Please enter your numeric choice: 1
Your current configuration has been set to: [default]
You can skip diagnostics next time by using the following flag:
gcloud init --skip-diagnostics
Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
Reachability Check passed.
Network diagnostic passed (1/1 checks passed).
Choose the account you would like to use to perform operations for this configuration:
[1] ajoy.sinha#abc.com
[2] Log in with a new account
Please enter your numeric choice: 1
You are logged in as: [ajoy.sinha#abc.com].
Pick cloud project to use:
[1] PROJECT A
[2] PROJECT B
[3] Enter a project ID
[4] Create a new project
Please enter numeric choice or text value (must exactly match list item): 2
Your current project has been set to: [PROJECT B].
Do you want to configure a default Compute Region and Zone? (Y/n)? n
Your Google Cloud SDK is configured and ready to use!
* Commands that require authentication will use ajoy.sinha#abc.com by default
* Commands will reference project `PROJECT B` by default
Run `gcloud help config` to learn how to change individual settings
This gcloud configuration is called [default]. You can create additional configurations if you work with multiple accounts and/or projects.
Run `gcloud topic configurations` to learn more.
Some things to try next:
* Run `gcloud --help` to see the Cloud Platform services you can interact with. And run `gcloud help COMMAND` to get help on any gcloud command.
* Run `gcloud topic --help` to learn about advanced features of the SDK like arg files and output formatting
* Run `gcloud cheat-sheet` to see a roster of go-to `gcloud` commands.
C:\Program Files (x86)\Google\Cloud SDK>kubectl get pods
NAME READY STATUS RESTARTS AGE
metabase 1/1 Running 0 3d19h
mongodb 1/1 Running 0 4d
C:\Program Files (x86)\Google\Cloud SDK>
Kubernetes get auth by .kube/config file, what you are updating is gcloud auth or changing the project but not changing the context for the kubectl
This command will list the available cluster to connect if added any
kubectl config get-contexts
Change the context to another cluster
kubectl config use-context <cluster-name or context shown above>
If context is not available after gcloud auth you did you have to run the command to set/add kubeconfig file
gcloud container clusters get-credentials <cluster-name>
refer doc for more

Migrate Secrets from SecretManager in GCP

Hi I have my secrets in Secretmanager in one project and want to know how to copy them or migrate them to other project.
Is there a mechanism to do it smoothly.
As of today there is no way to have GCP move the Secret between projects for you.
It's a good feature request that you can file here: https://b.corp.google.com/issues/new?component=784854&pli=1&template=1380926
edited according to John Hanley's comment
I just had to deal with something similar myself, and came up with a simple bash script that does what I need. I run Linux.
there are some prerequisites:
download the gcloud cli for your OS.
get the list of secrets you want to migrate (you can do it by setting up the gcloud with the source project gcloud config set project [SOURCE_PROJECT], and then running gcloud secrets list)
then once you have the list, convert it textually to a list in
format "secret_a" "secret_b" ...
the last version of each secret is taken, so it must not be in a "disabled" state, or it won't be able to move it.
then you can run:
$(gcloud config set project [SOURCE_PROJECT])
declare -a secret_array=("secret_a" "secret_b" ...)
for i in "${secret_array[#]}"
do
SECRET_NAME="${i}_env_file"
SECRET_VALUE=$(gcloud secrets versions access "latest" --secret=${SECRET_NAME})
echo $SECRET_VALUE > secret_migrate
$(gcloud secrets create ${SECRET_NAME} --project [TARGET_PROJECT] --data-file=secret_migrate)
done
rm secret_migrate
what this script does, is set the project to the source one, then get the secrets, and one by one save it to file, and upload it to the target project.
the file is rewritten for each secret and deleted at the end.
you need to replace the secrets array (secret_array), and the project names ([SOURCE_PROJECT], [TARGET_PROJECT]) with your own data.
I used this version below, which also sets a different name, and labels according to the secret name:
$(gcloud config set project [SOURCE_PROJECT])
declare -a secret_array=("secret_a" "secret_b" ...)
for i in "${secret_array[#]}"
do
SECRET_NAME="${i}"
SECRET_VALUE=$(gcloud secrets versions access "latest" --secret=${SECRET_NAME})
echo $SECRET_VALUE > secret_migrate
$(gcloud secrets create ${SECRET_NAME} --project [TARGET_PROJECT] --data-file=secret_migrate --labels=environment=test,service="${i}")
done
rm secret_migrate
All "secrets" MUST be decrypted and compiled in order to be processed by a CPU as hardware decryption isn't practical for commercial use. Because of this getting your passwords/configuration (in PLAIN TEXT) is as simple as logging into one of your deployments that has the so called "secrets" (plain text secrets...) and typing 'env' a command used to list all environment variables on most Linux systems.
If your secret is a text file just use the program 'cat' to read the file. I haven't found a way to read these tools from GCP directly because "security" is paramount.
GCP has methods of exec'ing into a running container but you could also look into kubectl commands for this too. I believe the "PLAIN TEXT" secrets are encrypted on googles servers then decrypted when they're put into your cluser/pod.

Error while trying to authenticate with `gcloud init`

I am trying to athenticate to the gcloud sdk using : gcloud init.
I get a URL I'm supposed to access in order to copy a token and return it to the CLI... but instead of a token, I get this error :
Erreur d'autorisation
Erreur 400 : invalid_request
Missing required parameter: redirect_uri
Is this a bug?
gcloud version info:
Google Cloud SDK 377.0.0
alpha 2022.03.10
beta 2022.03.10
bq 2.0.74
bundled-python3-unix 3.8.11
core 2022.03.10
gsutil 5.8
I am running gcloud init on wsl2 (Ubuntu 18.04). This error occurs right after the installation of gcloud with sudo apt install google-cloud-sdk.
I had the same problem and gcloud has slightly changed the way their auth flow works.
Run gcloud auth login and then copy the whole output (not just the URL) to a terminal on a computer that has both a web browser and gcloud CLI installed. The command you should copy looks like
gcloud auth login --remote-bootstrap="https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=****.apps.googleusercontent.com&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=****&access_type=offline&code_challenge=****&code_challenge_method=S256&token_usage=remote"
When you run that on your computer that has a web browser, it will open a browser window and prompt you to log in. Once you authorize your app in the web browser you get a new URL in your terminal that looks like
https://localhost:8085/?state=****&code=****&scope=email%20openid%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/cloud-platform%20https://www.googleapis.com/auth/appengine.admin%20https://www.googleapis.com/auth/compute%20https://www.googleapis.com/auth/accounts.reauth&authuser=0&hd=****&prompt=consent
Paste this new URL back into the prompt in your headless machine after Enter the output of the above command: (in your case, this would be in your WSL2 terminal). Press enter and you get the output
You are now logged in as [****].
Your current project is [None]. You can change this setting by running:
$ gcloud config set project PROJECT_ID
[8]+ Done code_challenge_method=S256
Try
gcloud init --console-only
Then you will get the url which will work.
You must log in to continue. Would you like to log in (Y/n)? y
WARNING: The --[no-]launch-browser flags are deprecated and will be removed on June 7th 2022 (Release 389.0.0). Use --no-browser to replace --no-launch-browser.
Go to the following link in your browser:
https://accounts.google.com/o/o....
update 2022-06-20. option console-only is removed for version 389.0.0.
So instead use
gcloud init --no-browser
There are some workarounds and they depend on your particular Windows environment.
In this post and in this one you can check the most related issues with respect to gcloud running in WSL.
Here you can find some Google groups related threads that might be helpful.
Finally, you could check some related Windows troubleshootings that can help in issues related to WSL2 on your own environment.
EDIT:
it seems this answer and the one from #K.I. give other commands that don't rely on implementation details. I've tested those 3 commands:
gcloud init --console-only
gcloud auth login --no-launch-browser
gcloud init --no-launch-browser
Original answer, another workaround (17/07/2022):
DISPLAY=":0" gcloud auth login
is a workaround mentioned in this issue. Instead of requiring you to install gcloud CLI outside WSL2, it pretends there is a browser.
A link is printed, click it, login on your browser, and you're authenticated with the CLI.
Then run again gcloud init.
You can do it without error by using another method of gcloud installation :
curl https://sdk.cloud.google.com | bash
exec -l $SHELL #restart shell
gcloud init

gcloud beta functions deploy ha COMMAND not update HA (home automation) function URL

I stay trying do this.
(two weeks ago)
In my first gcloud beta functions deploy ha COMMAND I put XXXX project ID.
Now I stay trying put YYYY project ID, But the result only comes with XXXX project ID. Look at the photo, please.
Does anybody know how to solve this?
gcloud beta functions deploy ha issue command:
As Previously stated by Neuber, this is because the correct SDK Configuration was not set properly. Just trying to expand on Neuber's comment.
1) For getting the current project ID, run the following command:
$ gcloud config configurations list
gcloud lists the configurations and shows which configuration is currently active.
2) If more than one SDK configuration was found you should choose which one would be suitable for the job. You can switch between configurations with the next instrucction:
gcloud config configurations activate [NAME]
3) If the configuration needs to set the project properly, you may use the next command:
gcloud config set project [PROJECT]
Finally you may execute the ha command in question.
For more information on this, refer to [1].
[1] https://cloud.google.com/sdk/docs/configurations

Google Cloud - Wrong project id being used from different email address

Despite running gcloud auth application-default login and gcloud config set core/project CORRECT_PROJECT_ID the project keeps defaulting to an incorrect project id:
gcloud config list
[core]
account = CORRECT_EMAIL
disable_usage_reporting = True
project = CORRECT_PROJECT_ID
Your active configuration is: [default]
I can successfully run the sample code from the tutorial (below) if I run in the terminal
export GOOGLE_APPLICATION_CREDENTIALS="[PATH]"
However, I didn't want to have to do this every time, so I ran the command:
gcloud auth application-default login
This opened a browser with a list of my gmail accounts, and even though I selected the correct account, the success window went to a different gmail account. So then I tried it in an incognito window, and it worked.
However, running npm start resulted in the following error:
ERROR: { Error: 7 PERMISSION_DENIED: Cloud Natural Language API has not been used in project WRONG_PROJECT_ID before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/language.googleapis.com/overview?project=WRONG_PROJECT_ID then retry.
Then I ran gcloud config set core/project CORRECT_PROJECT_ID and got the message Updated property [core/project].
When I run npm start I get the same message:
ERROR: { Error: 7 PERMISSION_DENIED: Cloud Natural Language API has not been used in project WRONG_PROJECT_ID before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/language.googleapis.com/overview?project=WRONG_PROJECT_ID then retry.
I tried gcloud auth login and got the following message (after I authenticated in an incognito window):
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 [CORRECT EMAIL ADDRESS].
Your current project is [CORRECT_PROJECT_ID]. You can change this setting by running:
$ gcloud config set project PROJECT_ID
I have a few suggestions that may correct this behaviour.
1) Clear your web browser cache & cookies. Then run "gcloud auth application-default login"
2) Try re-installing the gcloud toolkit.
3) Try unsetting the project in your config first, then set the project to the correct project. i.e.
gcloud config unset project WRONG_PROJECT_ID
gcloud config set project CORRECT_PROJECT_ID
4) Check the “CLOUDSDK_CORE_PROJECT” environment variable. Set it to the correct project if it is not already.
5) Try re-running “gcloud init”
6) You can find your application default credentials in
Linux: ~/.config/gcloud/application_default_credentials.json
Windows: C:\Users\%username%\AppData\Roaming\gcloud\credentials
You can delete the file, & regenerate it using commands you had mentioned in your question such as “gcloud auth default-credentials login”
We need to find where npm start is getting its credentials from. Once we figure that out, we can figure out how to change it, & understand why it’s looking there etc.
Are you able to find the config file to see where it is looking for credentials?
Is npm start the entire command? I’m not too familiar with Node JS. I’m not sure why it is trying to use Natural Language API.
You also mentioned a tutorial but I think you may have forgotten to include it in your question. Which tutorial are you referring to?