Authenticate Google Cloud service account on docker image - docker

I'm finding different behavior from within and outside of a docker image for authenticating a google service account.
Outside. Succeeds.
C:\Users\Ben\AppData\Local\Google\Cloud SDK>gcloud auth activate-service-account 773889352370-compute#developer.gserviceaccount.com --key-file C:/Users/Ben/Dropbox/Google/MeerkatReader-d77c0d6aa04f.json --project api-project-773889352370
Activated service account credentials for: [773889352370-compute#developer.gserviceaccount.com]
Run docker container, pass the .json key to tmp directory.
C:\Users\Ben\AppData\Local\Google\Cloud SDK>docker run -it -v C:/Users/Ben/Dropbox/Google/MeerkatReader-d77c0d6aa04f.json:/tmp/MeerkatReader-d77c0d6aa04f.json --rm -p "127.0.0.1:8080:8080" --entrypoint=/bin/bash gcr.io/cloud-datalab/datalab:local-20161227
From within docker, confirm the file is there
root#4a4a9314f15c:/tmp# ls
MeerkatReader-d77c0d6aa04f.json npm-24-b7aa1bcf npm-45-fd13ef7c npm-7-22ec336e
Run the same command as before. Fails.
root#4a4a9314f15c:/tmp# gcloud auth activate-service-account 773889352370-compute#developer.gserviceaccoun
t.com --key-file MeerkatReader-d77c0d6aa04f.json --project api-project-773889352370
ERROR: (gcloud.auth.activate-service-account) Failed to activate the given service account. Please ensure provided key file is valid.
What might cause this error? More broadly, what is the suggested strategy for passing credentials. I've tried this and it fails as well. I'm using the cloudml API and cloud vision, and i'd like to avoid manual gcloud init at the beginning of every run.
EDIT: To show gcloud info
root#7ff49b26484f:/# gcloud info --run-diagnostics
Network diagnostic detects and fixes local network connection issues.
Checking network connection...done.
Reachability Check passed.
Network diagnostic (1/1 checks) passed.
confirmed same behavior
root#7ff49b26484f:/tmp# gcloud auth activate-service-account 773889352370-compute#developer.gserviceaccount.com --key-file MeerkatReader-d77c0d6aa04f.json --project api-project-773889352370
ERROR: (gcloud.auth.activate-service-account) Failed to activate the given service account. Please ensure provided key file is valid.

This is probably due to a clock skew of the docker VM. I debugged the activate-service-account function of the google SDK and got the following error message:
There was a problem refreshing your current auth tokens: invalid_grant:
Invalid JWT: Token must be a short-lived token and in a reasonable timeframe
Please run:
$ gcloud auth login
to obtain new credentials, or if you have already logged in with a different account:
$ gcloud config set account ACCOUNT
to select an already authenticated account to use.
After rebooting the VM, it worked like a charm.

Have you attempted to put the credential in the image from the beginning? Is that a similar outcome?
On the other hand, have you tried using --key-file /tmp/MeerkatReader-d77c0d6aa04f.json? Since it appears you're putting the json file in /tmp.
You might also consider checking the network configuration inside the container and with docker from the outside.

In my case, I was using a workload identity provider, and I made a little mistake, I set the workload provider with the full name of the pool
How it should be: /projects/${project-number}/locations/global/workloadIdentityPools/my-pool/providers/${id-provider}
And I also added the following command:
gcloud config set account ${{GCP_SERVICE_ACCOUNT}}
Before my docker push, because it was required.
In addition, according to the docs https://github.com/google-github-actions/auth#usage, my service account was missing the required roles:
roles/iam.serviceAccountTokenCreator
roles/iam.workloadIdentityUser
Edit: You may also need to grant access for your service account to your Workload Identity Pool, you can do it by command or interface:
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT_EMAIL \
--role=roles/iam.workloadIdentityUser \
--member="MEMBER_ID"
Docs:https://cloud.google.com/iam/docs/using-workload-identity-federation#gcloud

Related

Retake ownership from service account

I've assigned ownership of one of my google sheets to a service account from a gcloud project I am working on (not a smart thing to do, I know...). How can I re-assign ownership of this sheet to my main user account?
If you have permissions on the service account (e.g. you're owner of the GCP project), you can use the command line tools to authenticate as the service account and modify the permissions there.
Step by step process (you might have already some of those steps done):
Download and install the GCP SDK:
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
gcloud init
During the initialization, follow the steps to authenticate with the account owner of the GCP project, and select the project in question. You can ignore the rest of the steps.
Create and download a key for the service account that is the current owner of the file (change the service account in this command):
gcloud iam service-accounts keys create key --iam-account service_account_id#project_id.iam.gserviceaccount.com
Hack the SDK to include the Drive scope:
sed -i 's/\(^CLOUDSDK_SCOPES = (\)/\1"https:\/\/www.googleapis.com\/auth\/drive",/' $(gcloud info --format 'value(installation.sdk_root)')/lib/googlecloudsdk/core/config.py
Activate the service account (change the service account in this command):
gcloud auth activate-service-account service_account_id#project_id.iam.gserviceaccount.com --key-file key
Make a call to the Drive API giving back the ownership (change the drive file ID and the new owner email address in this command):
curl -H"Authorization: Bearer $(gcloud auth print-access-token)" https://www.googleapis.com/drive/v3/files/DRIVE_FILE_ID/permissions?transferOwnership=true -d '{"role":"owner","type":"user","emailAddress":"YOUR_EMAIL#example.com"}' -H'content-type:application/json'
After these steps, your regular email account should be the new owner.
This is a pretty bad solution (hacking the SDK, etc..), but it's barely 7 bash commands, so I think it's likely the fastest/simplest one, at least for a one-off situation.
If this happens often (I guess not), it's likely that a real script would be more useful.

Permission issues while docker push

I'm trying to push my docker image to google container image registry but get an error which says I do not have the needed permission to perform this operation.
I have already tried gcloud auth configure-docker but it doesn't work for me.
I first build the image using:
docker build -t gcr.io/trynew/hello-world-image:v1 .
Then I'm trying to attach a tag and push it:
docker push gcr.io/trynew/hello-world-image:v1
This is my output :
The push refers to repository [gcr.io/trynew/hello-world-image]
e62774cdb1c2: Preparing
0f6265b750f3: Preparing
f82351274ce3: Preparing
31a16430afc8: Preparing
67298499a3ed: Preparing
62d5f39c8fe4: Waiting
9f8566ee5135: Waiting
unauthorized: You don't have the needed permissions to perform this
operation, and you may have invalid credentials.
To authenticate your request, follow the steps in:
https://cloud.google.com/container-registry/docs/advanced-authentication
Google cloud services have specific information how to grant permissions for docker push, this is the first thing you should have a look I think, https://cloud.google.com/container-registry/docs/access-control
After checking that you have sufficient permissions you should proceed with authentication with something like:
gcloud auth configure-docker
See more here: https://cloud.google.com/container-registry/docs/pushing-and-pulling
If you are running docker as root (i.e. with sudo docker), then make sure to configure the authentication as root. You can run for example:
sudo -s
gcloud auth login
gcloud auth configure-docker
...that will create (or update) a file under /root/.docker/config.json.
(Are there any security implications of gcloud auth login as root? Let me know in the comments.)
In order to be able to push images to the private registry you need two things: API Access Scopes and Authenticate your VM with the registry.
For the API Access Scopes (https://cloud.google.com/container-registry/docs/using-with-google-cloud-platform) we can read in the official documentation:
For GKE:
By default, new Google Kubernetes Engine clusters are created with
read-only permissions for Storage buckets. To set the read-write
storage scope when creating a Google Kubernetes Engine cluster, use
the --scopes option.
For GCE:
By default, a Compute Engine VM has the read-only access scope
configured for storage buckets. To push private Docker images, your
instance must have read-write storage access scope configured as
described in Access scopes.
So first, verify if your GKE cluster or GCE instance actually has the proper scopes set.
The next is to authenticate to the registry:
a) If you are using a Linux based image, you need to use "gcloud auth configure-docker" (https://cloud.google.com/container-registry/docs/advanced-authentication).
b) For Container-Optimized OS (COS), the command is “docker-credential-gcr configure-docker” (https://cloud.google.com/container-optimized-os/docs/how-to/run-container-instance#accessing_private_google_container_registry)
Windows / Powershell
I got this error on Windows when I was trying to run docker push from a normal powershell window after authenticating in the google cloud shell that had opened when I installed the SDK.
The solution was simple:
Start a new powershell window to run docker push after running the gcloud auth configure-docker command.
Make sure you've activated the registry too:
gcloud services enable containerregistry.googleapis.com
Also Google has a tendency to jump to a default account (maybe your personal gmail) which may or may not be the one you want (your business email). Make sure if you're opening any links in a browser that you're in the correct Google account.
I'm not exactly sure what's going on yet because I'm brand new to docker, but something got refreshed when starting a new Powershell instance.
as noted https://stackoverflow.com/a/59799035/26283371 there appears to be a bug in the Linux version of cloud sdk where authentication fails using the standard authentication method (gcloud auth configure-docker). Instead, create a JSON keyfile per this and that tends to work.
I still can't get the gcloud auth configure-docker helper to work. What did was authenticating with an access token, like so
gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://HOSTNAME
where HOSTNAME is gcr.io, us.gcr.io, eu.gcr.io, or asia.gcr.io. (Be sure to include https://, otherwise it won't work).
You can view options for print-access-token here.
First thing, Make sure you covered all points listed in the following official documentation
https://cloud.google.com/container-registry/docs/advanced-authentication
This error occurs mostly due to docker config update, which you can check using command cat .docker/config.json
Now update with gcr with following command
gcloud auth configure-docker
Just in case anyone else is banging their head against a wall my PIA VPN caused this behavior.
"unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication"
Turn my VPN off and it works fine. Turn it back on and it breaks again.
This is the only way that worked for me. I found it in a kubernetes/kompose Github issue.
Remove the credsStore key in ~/.docker/config.json
This will force docker to write the auth into the json when you use docker login. You can't untick Securely store Docker logins in macOS keychain in the docker desktop any more -- and the current credStore is no longer macOS keychain, it's desktop.
gcloud auth login Auth with gcloud (just to be explicit)
gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://eu.gcr.io
You should see this:
WARNING! Your password will be stored unencrypted in /Users/andrew/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
Source: https://github.com/kubernetes/kompose/issues/1043#issuecomment-609019141
The fix is as follows: run gcloud auth login (the browser will open and allow you to authenticate) then run gcloud auth configure-docker and select Y - then redo push. It should work like charm.
I also have the same issue in the Linux environment. So I just set the Docker to run as a non-root user, (https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user), and it works.
In my case DOCKER_CONFIG env variable was defined with an invalid value (not pointing to a docker config json).
I had the same issue, but for me, the problem was with internal users in my Linux system. I authenticated with gcloud my personal Linux user and when pushing, I was doing with root. So I had to authenticate my root user with gcloud as well:
sudo gcloud init
This issue happens to me when i switch service account which is pointing to different GCP Projects. Even though the service account has permission to push it says it does not have the permission. To resolve this by deleting config.json file which is present in .docker
Once this is done run the below commands and you should be able to push the image.
gcloud auth configure-docker
gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://HOSTNAME
Where HOSTNAME= gcr.io , asia.gcr.io etc

Deploying to Cloud Run with a custom service account failed with iam.serviceaccounts.actAs error

I have created a custom service account travisci-deployer#PROJECT_ID.iam.gserviceaccount.com on my project and gave it the Cloud Run Admin role:
gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
--member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
--role="roles/run.admin"
Then I set this service account as the identity for my gcloud commands:
gcloud auth activate-service-account --key-file=google-key.json
But when I ran gcloud beta run deploy command, I got an error about the "Compute Engine default service account" not having iam.serviceAccounts.actAs permission:
gcloud beta run deploy -q "${SERVICE_NAME}" \
--image="${CONTAINER_IMAGE}" \
--allow-unauthenticated
Deploying container to Cloud Run service [$APP_NAME] in project [$PROJECT_ID] region [us-central1]
Deploying...
Deployment failed
ERROR: (gcloud.beta.run.deploy) PERMISSION_DENIED: Permission 'iam.serviceaccounts.actAs'
denied on service account 1075231960084-compute#developer.gserviceaccount.com
This seems weird to me (because I'm not using the GCE default service account identity, although it's used by Cloud Run app once the app is deployed).
So the 1075231960084-compute#developer.gserviceaccount.com account is being used for the API call, and not my travisci-deployer#PROJECT_ID.iam.gserviceacount service account configured on gcloud?
How can I address this?
TLDR: Add Cloud Run Admin and Service Account User roles to your service account.
If we read the docs in detail for the IAM Reference page for Cloud Run which is found here, we find the following text:
A user needs the following permissions to deploy new Cloud Run
services or revisions:
run.services.create and run.services.update on the project level.
Typically assigned through the roles/run.admin role. It can be changed
in the project permissions admin page.
iam.serviceAccounts.actAs for
the Cloud Run runtime service account. By default, this is
PROJECT_NUMBER-compute#developer.gserviceaccount.com. The permission
is typically assigned through the roles/iam.serviceAccountUser role.
I think these extra steps explain the story as you see it.
Adding Cloud Run Admin and Service Account User roles to my own service account fixed this for me. See step 2 in the docs here:
https://cloud.google.com/run/docs/continuous-deployment#continuous
For the best practice, you should only allow specific permission for the cloud run instance.
Reference: https://cloud.google.com/run/docs/reference/iam/roles#additional-configuration
Assuming you have two service accounts in your GCP.
One is the Clound Run identity service account/runtime service account.
Let it as identity-cloudrun#project-id.iam.gserviceaccount.com and this service account doesn't need to assign any permission to it because it is just as a identiy for the cloud run. If you need this cloud run instance access other GCP resource, you may add some permission for this service account.
Another one is the Deployment Service account which is used to deploy your Cloud Run.
Let it as deploy-cloudrun#project-id.iam.gserviceaccount.com
For the Deployment Service account, you need to grant Cloud Run Admin permissions to it specific to your-cloudrun-instance. So, it cannot access other cloud run instance.
gcloud run services add-iam-policy-binding your-cloudrun-instance \
--member="serviceAccount:deploy-cloudrun#project-id.iam.gserviceaccount.com" \
--role="roles/run.admin" \
--region=europe-west1
Also, you need to grant iam.serviceAccounts.actAs permission of identity service account to your deployment service account. This is mentioned by the documentation.
gcloud iam service-accounts add-iam-policy-binding \
identity-cloudrun#project-id.iam.gserviceaccount.com \
--member="serviceAccount:deploy-cloudrun#project-id.iam.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
So, you can deploy your cloud run like below by your deployment service account.
Note: In practice, you should use workload identity federation instead using your deployment service account directly.
gcloud run deploy your-cloudrun-instance \
--image="us-docker.pkg.dev/cloudrun/container/hello" \
--service-account="identity-cloudrun#project-id.iam.gserviceaccount.com"
Though you can resolve this particular error by granting the account permission to act as the Compute Engine default service account, it goes against the "best practices" advice:
By default, Cloud Run services run as the default Compute Engine service account. However, Google recommends using a user-managed service account with the most minimal set of permissions. Learn how to deploy Cloud Run services with user-managed service accounts in the Cloud Run service identity documentation.
You can indicate which service account identity the Cloud Run deployment will assume like so:
gcloud run deploy -q "${SERVICE_NAME}" \
--image="${CONTAINER_IMAGE}" \
--allow-unauthenticated \
--service-account "${SERVICE_ACCOUNT_EMAIL}"
Currently, in beta, all Cloud Run services run as the default compute account (The same as the Google Compute Engine default service account).
The ability to run services as a different service account will be available in a future release.

How to use gcloud auth list in python

We could run "gcloud auth list" to get our credentialed account, and now I want to do the same thing in my python code, that is checking the credential account by API in python. But I didn't fine it..... Any suggestion?
More information is:
I want to check my account name before I create credentials
CREDENTIALS = GoogleCredentials.from_stream(ACCOUNT_FILE)
CREDENTIALS = GoogleCredentials.get_application_default()
gcloud stores credentials obtained via
gcloud auth login
gcloud auth activate-service-account
in its internal local database. There is no API besides gcloud auth list command to query them. Note that this is different (usually a subset) from the list of credentials in GCP.
Credentials used by gcloud are meant to be separate from what you use in your python code.
Perhaps you want to use
https://cloud.google.com/sdk/gcloud/reference/iam/service-accounts/keys/list, there is also API for that https://cloud.google.com/iam/docs/creating-managing-service-accounts.
For application default credentials you would download json key file using developer console https://console.cloud.google.com/iam-admin/serviceaccounts/project?project=YOUR_PROJECT or use gcloud iam service-accounts keys create command.
There is also gcloud auth application-default login command, which will create application default credential file in well known location, but you should not use it for anything serious except perhaps developing/testing. Note that credentials obtained via this command do not show up in gcloud auth list.

Docker-Machine do not work with Google Cloud service account

I Create a google compute instance with service account
gcloud --project my-proj compute instances create test1 \
--image-family "debian-9" --image-project "debian-cloud" \
--machine-type "g1-small" --network "default" --maintenance-policy "MIGRATE" \
--service-account "gke-build-robot#myproj-184015.iam.gserviceaccount.com" \
--scopes "https://www.googleapis.com/auth/cloud-platform" \
--tags "gitlab-runner" \
--boot-disk-size "10" --boot-disk-type "pd-standard" --boot-disk-device-name "$RESOURCE_NAME" \
--metadata register_token=mytoken,config_bucket=gitlab_config,runner_name=test1,gitlab_uri=myuri,runner_tags=backend \
--metadata-from-file "startup-script=startup-scripts/prepare-runner.sh"
Log to instance though ssh: gcloud compute --project "myproj" ssh --zone "europe-west1-b" "gitlab-shared-runner-pool"
After install and configure docker machine. i try create instance:
docker-machine create --driver google --google-project myproj test2
Running pre-create checks...
(test2) Check that the project exists
(test2) Check if the instance already exists
Creating machine...
(test2) Generating SSH Key
(test2) Creating host...
(test2) Opening firewall ports
(test2) Creating instance
(test2) Waiting for Instance
Error creating machine: Error in driver during machine creation: Operation error: {EXTERNAL_RESOURCE_NOT_FOUND The resource '1045904521672-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found. []}
1045904521672-compute#developer.gserviceaccount.com is my default account.
I don;t understand why it used. Because activated is gke-build-robot#myproj-184015.iam.gserviceaccount.com
gcloud config list
[core]
account = gke-build-robot#myproj-184015.iam.gserviceaccount.com
disable_usage_reporting = True
project = novaposhta-184015
Your active configuration is: [default]
gcloud auth list
Credentialed Accounts
ACTIVE ACCOUNT
* gke-build-robot#myproj-184015.iam.gserviceaccount.com
Can some one explain me, what i do wrong?
There was double problem.
First of all, docker-machine can't work with specific service account, at least in 0.12 and 0.13 version.
Docker+Machine google driver have only scope parameter and can't get specific one.
So Instance where docker+machine was installed is work fine with specified sa. But instance that was created with docker+machine, must have default service account.
And when during debug, I turn off it.
I've got this error as a result.
A similar issue (bosh-google-cpi-release issue 144) suggests somehow the
This error message is unclear, particularly because the credentials which also need to be specified in the manifest may be associated with another account altogether.
The default service_account for the bosh-google-cpi-release is set to "default" if it is not proactively set by the bosh manifest, so this will happen anytime you use service_scopes instead of a service_account.
While you are not using bosh-google-cpi-release, the last sentence made me double-check the gcloud reference page, in particular gcloud compute instance create.
A service account is an identity attached to the instance. Its access tokens can be accessed through the instance metadata server and are used to authenticate applications on the instance.
The account can be either an email address or an alias corresponding to a service account. You can explicitly specify the Compute Engine default service account using the 'default' alias.
If not provided, the instance will get project's default service account.
It is as if your service account is either ignored or incorrect (and falls back to the project default's one)
See "Creating and Enabling Service Accounts for Instances" to double-check its value:
Usually, the service account's email is derived from the service account ID, in the format:
[SERVICE-ACCOUNT-NAME]#[PROJECT_ID].iam.gserviceaccount.com
Or try setting first the service scope and account.

Resources