Teleport Workload Identity with SPIFFE: Achieving Zero Trust in Modern Infrastructure
May 23
Virtual
Register Today
Teleport logoTry For Free

Configuring Grafana with Google Workspace SSO Access

Posted 5th Apr 2023 by Kenny DuMez

Configuring Grafana with Google Workspace SSO Access

In this tutorial we will show you how to configure identity-based access to a self-hosted Grafana instance using Google Workspace SSO, Teleport Enterprise and JWT tokens. In today’s technology landscape, with employees working remotely all across the globe, simple perimeter security is no longer good enough. Accessing infrastructure resources with long-lived credentials is a security nightmare waiting to happen. It’s not a question of if, but when, these credentials will eventually be leaked or stolen.

With Google Workspace and Teleport Enterprise, however, you can configure access to applications like Grafana based on strict identity-based RBAC access controls, so you know exactly who is accessing what on your network.

Key takeaways:

  • How to host a Teleport-managed Grafana instance
  • How to configure Google Workspace SSO for accessing Teleport
  • How to map Teleport RBAC roles to Google Workspace group aliases
  • Configure Teleport RBAC roles to adhere to the principle of least privilege
  • Enable Passwordless access to your Grafana application

Grafana architecture

Above is a high-level diagram of the setup we’re going to be implementing. Instead of using a Grafana username and password to access our application, first users will authenticate with the Teleport platform using Google Workspace SSO. In this case Teleport will act as a gateway and a proxy, gating access to your Grafana application, enforcing RBAC roles, all the while ensuring that all traffic between your users and the private application are fully encrypted and audited.

The first step is to spin up a Grafana instance inside your Teleport cluster. You can follow the guide here in our docs to start up a containerized Grafana instance that will be managed by the Teleport cluster. As a prerequisite remember that this requires Teleport Enterprise edition.

Once you have followed the steps listed in the docs, you should see your Grafana application listed here under the “Applications” Tab in your Teleport web UI. This will allow all users with the `access` role to access your Grafana application. We’re going to more finely tune these RBAC controls in the next sections.

Configuring Google Workspace SSO access for Teleport and Grafana

Now that we have our Grafana instance managed by our Teleport cluster, we’re going to configure Google Workspace access for our cluster. We will also map our Google Workspace group aliases to our Teleport roles allowing us to maintain a chain of custody for our users tied to their identities in Google Workspace.

In order to configure Google Workspace SSO to integrate with our Teleport, please follow Steps 1 and 2 in our guide here. Please note the differences in the two versions of the Google Workspace API as the Teleport OIDC connector works differently depending on the resource version.

Once you have configured a Teleport SSO service account, you should be able to see its details in the Google Workspace dashboard:

We can now start configuring our Teleport cluster to use Google Workspace as an IDP provider.

We will now map our various Google Workspace group aliases to separate Teleport RBAC roles ensuring that we are following the principle of least privilege. This mapping will ensure that our users only have the minimum permissions that they need in order to do their jobs.

  1. Creating the Teleport OIDC connector

First update the auth_service field in your Teleport configuration file, which is located by default at `/etc/teleport.yaml`. We’re going to configure Teleport to use OIDC authentication as the default instead of the local user database:

auth_service:
  authentication:
    type: oidc

Then restart the Teleport daemon.

Once Teleport has been updated with the new OIDC authentication scheme, we’re going to add an OIDC connector Teleport resource.

Define an OIDC connector resource in a local file named `gworkspace-connector.yaml`:

kind: oidc
metadata:
  name: google
spec:
  claims_to_roles:
  - claim: groups
     roles:
       - auditor
       value: <auditor@google-workspace-group-email>
  - claim: groups
     roles:
     - grafana-dev
     value: [email protected]
  client_id: <GOOGLE_WORKSPACE_CLIENT_ID>.apps.googleusercontent.com
  client_secret: <OAUTH_CLIENT_SECRET>
  display: google
  google_admin_email: <GOOGLE_WORKSPACE_ADMIN_EMAIL>
  google_service_account_uri: file:///var/lib/teleport/gworkspace-creds.json
  issuer_url: https://accounts.google.com
  redirect_url: https://<cluster-url>:3080/v1/webapi/oidc/callback
  scope:
  - openid
  - email
version: v3

Make sure to replace <cluster-url> with the publicly accessible domain of your Teleport cluster. Also change all of the example emails to your organization’s actual Google Workspace group aliases.

The email that you set for `google_admin_email` must be the email address of a user that has permission to list all groups, users, and group membership in your Google Workspace account. This user will generally need super admin or group admin privileges.

Do not use the email of the service account for `google_admin_email`. The configuration display will look the same, but the service account will not have the required domain-wide delegation.

The `client_id field` must be the unique ID number captured from the Google Cloud Platform UI. An indicator that this is misconfigured is if you see "invalid Google Workspace credentials for scopes [...]" in your log.

Notice the `roles` field under the `claim` section. This is where we map the attributes in the Google Workspace roles to our Teleport RBAC roles. For the `auditor@google-workspace-group-email` Google Workspace role attribute we map it to our Teleport `auditor` role. This will allow users in this Google Workspace group to edit roles and resources in our Teleport cluster.

The `[email protected]` group, on the other hand, only allows access to our Teleport `grafana-dev` role which we’ll create in the next section. This role will be more restrictive and only allow access to our Grafana dashboard.

Once you have defined this connector resource in the yaml file, create it using the `tctl` tool:

$ tctl create gworkspace-connector.yaml


  1. Creating our grafana-dev Teleport role

Next we’ll create our `grafana-dev` role to pull in external information from Google Workspace.

Teleport administrators can configure roles to allow or deny users' access to applications with specific labels using the `app_labels` property.

As an example, here is how you can configure your Grafana application with a “metrics” label:

apps:
- name: "grafana"
   uri: "http://localhost:3000"
   # Static labels.
   labels:
     group: "metrics"
   commands:
   - name: "arch"
      command: ["uname", "-p"]
      period: 1m0s

We’ll use this metrics label to assign our `grafana-dev` role access to applications in the `metrics` group.


Create the local file `grafana-dev-role.yaml`:

kind: role
version: v5
metadata:
  name: grafana-dev
spec:
  options:
    max_session_ttl: 24h
  allow:
    logins: ['{{external.logins}}', ubuntu ]
    app_labels:
        group: "metrics"

Notice the `['{{external.logins}}'` login. It configures Teleport to look at the Google Workspace claim and use that field as an allowed login for each user.

Use `tctl` to create this role in the Teleport Auth Service:

$ tctl create dev.yaml
  1. Configuring JWT authentication to Grafana

Now that we have Google Workspace SSO as our identity provider — configured for our Teleport cluster — and now that we have successfully mapped our Google Workspace user groups to Teleport roles, the final step is to pass the JWT token attributed to our user session to our Grafana application. This will allow a single sign-on flow for Teleport users accessing our Grafana instance.

In your `grafana.ini` configuration file, located on the node where you are hosting your Grafana application, overwrite the `[auth.basic]` section and the `[auth.jwt]` section with the following values:

[auth.basic]
enabled = false

[auth.jwt]
disable_login_form = true
enabled = true
header_name = Teleport-Jwt-Assertion
email_claim = sub
username_claim = sub
auto_sign_up = true

This will allow Grafana to receive the JWT token attributed to the user-section, allowing passwordless access into your Grafana application.

Secure and audited identity-based Grafana access

Now that we have successfully configured Google Workspace SSO authentication to our Teleport cluster, mapped our Google Workspace roles to our Teleport roles, and also configured JWT authentication for our Grafana instance, our users now are able to access Grafana based on the RBAC policies we have in place. This allows us to centralize all of our access to one location, cutting down on silos, reducing overhead and enforcing best security practices across the organization.

  • For further reading on configuring JWT authentication for Grafana, please check out their documentation here.
  • For further information and troubleshooting help for Google Workspace SSO authentication for Teleport, please check out our guide here.

Not a Teleport Enterprise user quite yet? Request a free Enterprise Cloud trial today and get started with identity-native, zero-trust, secure application access!