This article is written by Rik Pauwels, Senior Data Architect at Devoteam G Cloud
Data Studio just released a long-awaited feature to use service accounts for authentication. With the release of this feature, it seems like a good time to cover all the different authentication methods, the pros, cons and advice on when to use which one. We will start with the two options that were already available: credentials of the viewer and credentials of the owner.
Use the credentials of the viewer
When using the credentials of the viewer you can leverage access policies applied on the source database or Google Sheet. This means that you don’t have to worry about sharing info that the viewer of the dashboard is not allowed to see. Specifically in BigQuery it also makes it possible to further analyse who is using the dashboard and who is not since you can see who queried the data in the BigQuery Access logs. This puts you in a position to check which employee or client might need more training to work with the new dashboard.
Example use case: you can make a BigQuery authorized view (see <other blog post>) that makes sure all your clients can see their own data but not anything else. If you then make a data studio dashboard that uses the credentials of the viewer to get the data, you can share the dashboard with all your clients without having to worry about them sharing the dashboard with other people. The people that can not see the data according to the access policies of the database will just see an empty dashboard.
This sounds very great but there is a small caveat when you combine this together with BigQuery. This setup requires you to give access to people to run BigQuery jobs on a project on Google Cloud. In theory, this means that people can abuse this privilege to run other queries with their newly acquired privileges. It is not straightforward but it is possible so keep this in mind!
| Pro | Con |
| Viewers can see exactly what (s)he is allowed to see according to data access policies created in the source database. | BigQuery Job User permissions are required on a certain project to get data from BigQuery. |
| You can track who is using the data and at what time to analyse how your dashboard is used. |
Use the credentials of the owner
Using the credentials of the owner was used in the past to make sure data studio viewers don’t need access to the source data because it might have too many details in it. For example, seeing all the cost details might be more sensitive than seeing the overall cost of a department.
Even though there were some valid use cases in the past, because viewers did not need the BigQuery job user role for example, now it is more than ever a sign of a bad data security setup. If viewers didn’t have access to the data in the first place, is this dashboard really a reason to suddenly give them access to it? If your answer is similar to: “I’m using this because I can for some reason not give the required access to my viewers even though they are allowed to see the data” then the new service account option is totally what you need!
Another reason why this option is bad is that when people transfer departments or leave the company all dashboards that connect to data with their credentials will break. And on top of that, when you are working with multiple editors it might not be straightforward to predict which connections are using who’s credentials because they use the credentials of the editor that created the data source. This will make it very difficult to estimate what dashboards will break when access is revoked from people.
| Pro | Con |
| You can quickly generate and share insights. | A real risk of sharing data with people that are not allowed to see it. |
| A dashboard will break if the owner loses permission when changing departments or leaving the company. | |
| You can not see who is actually using the dashboard and on top of that: it seems like the owner is heavily querying the database all the time since their credentials are logged whenever people use the dashboard. |
Use the credentials of a service account
To better explain the added value of this feature let’s first see what a service account actually is. You can consider a service account as a robot user that has one specific task and is only used for that task. You can create as many service accounts as you want on Google Cloud and you can give them precisely the roles they need and nothing more.
Once set up correctly, the service account will work forever. It will never change departments, leave the company, promote or become ill. This means that your dashboard will also keep on fetching data as long as you would like it, even when you change the owner of the dashboard or change the permissions of the editors.
On a bit more technical side: don’t forget to give the Data Studio Service Agent (you can find it here: https://datastudio.google.com/serviceAgentHelp) the Service Account Token Creator role on your newly created service account. This role is needed for Data Studio to impersonate your service account and fetch the data.
| Pro | Con |
| You can quickly generate and share insights. | Real risk of sharing data with people that are not allowed to see it. |
| Dashboards will never break when access is revoked from people. | You can not see who is actually using the dashboard. |
Conclusion
Out of the three available options I would advise using viewer credentials as much as possible so you never have to worry about unintentionally leaking too much data to people that are not allowed to see it. When you can not use viewer credentials because some permissions are lacking but you know for a fact that your viewers can see the data then it is best to authenticate your data sources with a service account so you know they will work forever. Only use owner credentials if you are quickly putting a dashboard together that will not serve a long lifetime.
Ready to get started or do you prefer to talk to one of our experts?
