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.
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.
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.
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
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
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.
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.
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!