Skip to content
This repository has been archived by the owner on Dec 11, 2022. It is now read-only.

Unable to detect the right GCE Service Account #326

Closed
daquinoaldo opened this issue Apr 23, 2021 · 0 comments · Fixed by #332
Closed

Unable to detect the right GCE Service Account #326

daquinoaldo opened this issue Apr 23, 2021 · 0 comments · Fixed by #332
Labels
duplicate This issue or pull request already exists
Milestone

Comments

@daquinoaldo
Copy link

daquinoaldo commented Apr 23, 2021

Bug Report

The datasource is not able to detect a service account different from the project default one.

Actual Behavior and Steps to Reproduce the Problem

I'm using a dedicated service account for the Grafana instance, which is grafana@project-id.iam.gserviceaccount.com.
This service account has the bigquery.jobUser role.

Using the GCE Default Service Account Authentication Type, I get the following error.

BigQuery: Invalid project ID ''. 
Project IDs must contain 6-63 lowercase letters, digits, or dashes.
Some project IDs also include domain name separated by a colon.
IDs must start with a letter and may not end with a dash.

Using a JSON key of the same service account, it connects correctly. Moreover, if I switch back to the GCE Default Service Account Authentication Type when the key is set, it connects correctly. It connects even if I delete the key on GCP, which means it is not using the key to connect.

This means, in my opinion, that the data source is not able to detect either the Project or Client Email when the service account is not the default one.

Expected Behavior

Being able to use the instance service account even if it isn't the project one.
Reason: having multiple service accounts enables a more granularity of permissions.
Possible solution: explicitly asking for the project id and the service account email.

Specifications

  • Version: latest (2.0.1, I suppose), but also 2.0.0 is affected.
  • Platform: Google COS inside GCE on GCP
  • Grafana Version: 7.5.4 (latest)

Related to #198. Tagging @avivl which managed the previous issue.

@ofir5300 ofir5300 added the duplicate This issue or pull request already exists label May 2, 2021
@ofir5300 ofir5300 added this to the 2.0.2 milestone May 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants