Navigation :

External auth with Google example

Use a Google account to log in to the Gloo Mesh UI. First, you set up your OAuth app and credentials in Google. Then, you use those credentials to configure Google as the external auth provider for the Gloo Mesh UI.

Before you begin

This guide assumes that you use the same names for components like clusters, workspaces, and namespaces as in the getting started. If you have different names, make sure to update the sample configuration files in this guide.

Complete the multicluster getting started guide to set up the following testing environment.
- Three clusters along with environment variables for the clusters and their Kubernetes contexts.
- The Gloo Platform CLI, meshctl, along with other CLI tools such as kubectl and istioctl.
- The Gloo management server in the management cluster, and the Gloo agents in the workload clusters.
- Istio installed in the workload clusters.
- A simple Gloo workspace setup.
Install Bookinfo and other sample apps.
Optional: Review the information about how authentication and authorization work with the Gloo Mesh UI.

Set up OAuth in Google

Set up Google to accept external auth requests from the Gloo Mesh UI. You get credentials that you can use to set up Google as an identity provider (IdP) in Gloo Mesh UI.

Log in to the Google Developer Console.
Optional: For first-time users, or to separate your resources from others in your cloud, create a project.
Configure your OAuth consent screen details. If you have an existing consent screen that you want to use, skip to the next step.
1. From the menu, click OAuth consent screen.
2. Select the Internal user type, and click Create.
3. From the OAuth consent screen tab, enter the details of your app.
  - In the App information section, enter a name and email for your app.
  - You can skip the App domain and Authorized domain sections.
  - In the Developer contact information section, enter your email.
  - Click Save and continue.
4. Optional: From the Scopes tab, you can restrict permissions to particular APIs in your app. For testing purposes, you can skip this section. Click Save and continue.
5. Review the summary and click Back to dashboard.
Create the credentials to use Google as an OAuth client.
1. From the menu, click Credentials.
2. From the Credentials menu bar, click + Create credentials, and then OAuth client ID.
3. From the Application type dropdown, select Web application. You can optionally rename the client.
4. In the Authorized redirect URIs section, click + Add URI.
5. Enter the URL for users to access the Gloo Mesh UI. For example, if you expose the UI locally, enter http://localhost:8090/oidc-callback.
6. Click Create.
Store the Client ID and Client secret values as environment variables. You can also download the client information as a JSON file.
```
export CLIENT_ID=<client-id>
export CLIENT_SECRET=<client-secret>
```

Configure the dashboard settings for authentication

Configure the Gloo Mesh UI to use Google authentication.

Create a Kubernetes secret with the client secret from your Google credentials. Note that the client secret value is base64-encoded.

kubectl apply --context ${MGMT_CONTEXT} -f - <<EOF
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: dashboard
  namespace: gloo-mesh
data:
  oidc-client-secret: $(echo -n ${CLIENT_SECRET} | base64)
EOF

Create a Dashboard custom resource.

kubectl apply --context ${MGMT_CONTEXT} -f - <<EOF
apiVersion: admin.gloo.solo.io/v2
kind: Dashboard
metadata:
  name: settings
  namespace: gloo-mesh
spec:
  authn:
    oidc:
      appUrl: http://localhost:8090/
      clientId: ${CLIENT_ID}
      clientSecretName: dashboard
      issuerUrl: https://accounts.google.com
EOF

Review the following table to understand this configuration. For more information, see the API reference.

Setting	Description
`namespace`	Create the dashboard settings in the same namespace as the Gloo Mesh UI deployment (`gloo-mesh`) in the management cluster.
`authn.oidc`	Configure the details to set up authentication via an OIDC provider, in this case Google.
`appURL`	The URL to send the user to after successful authentication: `http://localhost:8090/`
`clientId`	The client ID token that you got when you registered your app with the identity provider. In this example, you set the client ID as an environment variable on your local machine in the previous section.
`clientSecretRef`	The Kubernetes secret that has the client secret that you got when you registered your app with the identity provider. The secret must exist on the same cluster as the ExtAuthServer resource that this policy refers to. In this example, you created the secret in the previous step.
`issuerUrl`	The URL of the OpenID Connect identity provider. Gloo Mesh automatically discovers the OIDC configuration by querying the `.well-known/openid-configuration` endpoint on the `issuer_url`. In this example, Gloo Mesh expects to find OIDC discovery information at `https://accounts.google.com`.

Test that the Gloo Mesh UI requires authentication by opening the login URL and clicking Sign in to Gloo Mesh. This URL matches the Authorized redirect URIs that you configured in your Google credentials, such as http://localhost:8090/welcome.

Set up authorization with RBAC

You can modify your dashboard settings and RBAC resources so that Google can also be used for authorization. For more information, see RBAC for resources in the UI.

Update the dashboard settings to add the authz option for multicluster RBAC and the authn user mapping. Gloo Mesh extracts the usernameClaim from the Google tokens to map the user to the cluster role binding in RBAC. For more information, see the API reference.

kubectl apply --context ${MGMT_CONTEXT} -f - <<EOF
apiVersion: admin.gloo.solo.io/v2
kind: Dashboard
metadata:
  name: settings
  namespace: gloo-mesh
spec:
  authz:
     multiClusterRbac: {}
  authn:
    oidc:
      userMapping:
        usernameClaim: "email"
      appUrl: http://localhost:8090/
      clientId: ${CLIENT_ID}
      clientSecretName: dashboard
      issuerUrl: https://accounts.google.com
      scopes:
      - openid
      - profile
      - email
EOF

In your workload cluster, configure RBAC cluster roles for the Gloo Mesh resources that you want your user to have. For example, you might add Gloo Mesh resources to existing cluster-admin, edit, and view cluster roles. The following example role gives only view access to the workspace resource.

kubectl apply --context ${REMOTE_CONTEXT} -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    test: "true"
  name: test-auth
rules:
- apiGroups:
  - admin.gloo.solo.io/v2
  resources:
  - workspaces
  verbs:
  - get
  - list
  - watch
EOF

Update the cluster role bindings to add the Google account email addresses for the users that you want to give access to.

kubectl apply --context ${REMOTE_CONTEXT} -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: test-auth
  labels:
    test: "true"
subjects:
- kind: User
  name: <user-email@google-org.com>
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: test-auth
  apiGroup: rbac.authorization.k8s.io
EOF

Repeat the previous RBAC steps for each cluster.
Ask the user to test the Gloo Mesh UI authorization by opening the login URL, such as http://localhost:8090/welcome. If prompted, sign in again. The user sees only the resources that are permitted by the RBAC rules.

Next steps

Great job on setting up external authentication to the Gloo Mesh UI! Now, Gloo Mesh extracts the username in the format expected from the AuthN user mapping from the Google tokens. Then, it matches the username to the cluster role binding in RBAC for authorization.

Next, review this guide to:

Configure your OIDC settings by using a Helm values file and use that file to install Gloo Mesh. Setting up OIDC by using Helm ensures that your settings are not overwritten, even after you upgrade Gloo Mesh.
Persist UI sessions by storing the Google tokens in Redis instead of only in the user's browser.