--- title: "Google" url: "https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/google/" last_modified: "2026-06-18T14:41:23+02:00" --- > For the complete documentation index, see [llms.txt](https://axoflow.com/docs/axoflow/0.86/llms.txt). # Google This section shows you how to use Google OpenID Connect as an authentication backend for AxoConsole. It is assumed that you already have a Google organization and Google Cloud Console access. Complete the following steps. ## Prerequisites - To use Google authentication, AxoConsole must be deployed on a publicly accessible domain name (the `$BASE_HOSTNAME` must end with a valid top-level domain, for example, `.com` or `.io`.) - Configure OpenID Connect and create an OpenID credential for a **Web application**. - Make sure to set the **Authorized redirect URIs** to: `https://auth./callback`, for example, `https://auth.axoflow-console.example.com/callback`. - Save the **Client ID** of the app and the **Client secret** of the application, you’ll need them to configure AxoConsole. For details on setting up OpenID Connect, see the [official documentation](https://developers.google.com/identity/openid-connect/openid-connect). ### Google group membership To use group memberships when assigning your users to AxoConsole user roles, you have to configure a service account to retrieve group memberships. Otherwise, you can use email domains. To set up a proper service account, complete the following steps. 1. Set up a service account with [Domain-Wide Delegation](https://developers.google.com/admin-sdk/directory/v1/guides/delegation). 2. Save the JSON key file that contains the authentication information for the service account. You’ll need it later. 3. Delegate the `https://www.googleapis.com/auth/admin.directory.group.readonly` scope to the service account. Do not delegate any other scope. 4. Enable the [Admin SDK](https://console.developers.google.com/apis/library/admin.googleapis.com/). You’ll also need the email address of a Google Workspace user with a minimum of the Groups Reader Role assigned. The service account will impersonate this user when making calls to the admin API. ## Configuration 1. Configure Dex as the OIDC provider in the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. For example: ```yaml chalco: oidc: enabled: true provider: "dex" axoidp: enabled: false dex: enabled: true ``` 2. Configure authentication by editing the `spec.dex.config` section of the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. 1. (Optional) If you’ve used our [earlier example](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/deployment-guide/index.md), delete the `spec.dex.config.staticPasswords` section. 2. Add the `spec.dex.config.connectors` section to the file, like this: ```yaml connectors: - type: google id: google name: Google config: # Connector config values starting with a "$" will read from the environment. clientID: clientSecret: # Dex's issuer URL + "/callback" redirectURI: # Set the value of `prompt` query parameter in the authorization request # The default value is "consent" when not set. promptType: consent # Google supports whitelisting allowed domains when using G Suite # (Google Apps). The following field can be set to a list of domains # that can log in: # hostedDomains: - # For group membership authorization: #serviceAccountFilePath: "/etc/dex/sa-file/service-account.json" #domainToAdminEmail: #"*": ``` 3. Edit the following fields. For details on the configuration parameters, see the [Dex Google connector documentation](https://dexidp.io/docs/connectors/google/). - `connectors.config.clientID`: The ID of the Google application. - `connectors.config.clientSecret`: The client secret of the Google application. - `connectors.config.redirectURI`: The callback URL of the Google application: `https://auth./callback`, for example, `https://auth.axoflow-console.example.com/callback`. - `connectors.config.hostedDomains`: The domain where AxoConsole is deployed, for example, `example.com`. Your users must have email addresses for this domain at Google. 4. If you’ll use [Google group memberships](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/google/index.md#google-group-membership) for authorization, uncomment the `serviceAccountFilePath` and `domainToAdminEmail` sections. Replace `` with the email address you created in [Google group memberships](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/google/index.md#google-group-membership) prerequisites. ```yaml # For group membership authorization: serviceAccountFilePath: "/etc/dex/sa-file/service-account.json" domainToAdminEmail: "*": ``` 3. Configure authorization in the `kcp.rbac.roles` section of the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file. The following roles are available in AxoConsole by default: - `IAMadmin`: Can manage the roles and permissions to access AxoConsole. Only this role can make changes on the **Settings > Roles** page. Can see the **Identity Provider Admin Panel** link, which points to the authentication and administration page of the identity provider used to authenticate on AxoConsole. (Every user can access their own profile page at the identity provider by selecting ** > Profile** in the top-left.) - `admin`: Has full access to AxoConsole, but has only read access to the **Settings > Roles** page. - `infrastructureManager`: Can manage the infrastructure (without the permissions to view or tap log contents, or to rehydrate data). Has full access to the following pages: **Activity Logs**, **Alerting**, **Routers**, **Sources**, **Flows**, **Provisioning**, **Search Logs**. Can tap into service logs which may contain event payload. - `infrastructureViewer`: Similar to **infrastructure-manager**, but can only view the pages. - `contentManager`: Can view log content and manage content related details like flows (without the permissions to manage infrastructure, but including access to view infrastructure details). - Has full access to the **Rehydration** page. - Can view and modify **Flows**, but can’t create or delete them. - Can view **Routers**, **Sources**, **Search Logs**, **Analytics**. - Can tap into logs. - `contentViewer`: Can view content like analytics, log search, log tapping (without the permissions to manage or view infrastructure details). - Can view **Search Logs**, **Analytics**. - Can tap into logs. If you need other roles, [contact the Axoflow support team](https://axoflow.com/contact?contact_form_subject=support_request). Composing other roles is possible as part of a custom integration. To assign Google groups to AxoConsole roles, add the groups of your users to the related roles under `kcp.rbac.roles..groups`. > **Note:** > Make sure that you’ve completed the prerequisites detailed in [Google group membership](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/google/index.md#google-group-membership). ```yaml rbac: createRoles: true createRoleBindings: true roles: IAMadmin: groups: - groups:iamadmin@example.com admin: groups: - groups:admin@example.com contentViewer: groups: - groups:readonly@example.com ``` - A specific email address, for example, `email:username@example.com` > **Note:** > - The user must be able to authenticate to AxoConsole using this email address, so authentication must be properly set up. > - Multiple identity providers may allow authentication with the same email address, possibly with different level of ownership validation. - An entire email domain, for example, `emaildomain:example.com`. Any user who authenticates with an email address belonging to this email domain will have access to the role. - A user group. The format of the group depends on the OID provider. - If you’re using AxoConsole as a SaaS, specify the group in the following format: `cognito:groups:`, for example, `cognito:groups:ExampleGoogleSaml:Operator`. - If you’re using an on-prem AxoConsole deployment, specify the group in the following format: `groups:` for example, `groups:operator`. - A specific session of an authenticated user, in the following format: `user:`, for example: `user:42c4e962-f077-705f-138f-f01ba1220c44`. - Every authenticated user: `axoflow:user` For details on authorization settings, see [Authorization](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authorization/index.md). 4. Save the file. 5. If you’re using Google groups to assign user roles, complete the following steps. 1. Run the following command to delete the `dex-google-service-account` secret. This is a placeholder secret that you’ll re-create with valid values in the next step. ```shell kubectl -n axoflow delete secret dex-google-service-account ``` 2. Re-create the secret using the JSON key of the Google service account you’ve created in [Google group membership](https://axoflow.com/docs/axoflow/0.86/deploy/onprem/authentication/dex/google/index.md#google-group-membership). ```shell kubectl -n axoflow create secret dex-google-service-account --from-file ``` Expected output: ```shell secret/dex-google-service-account created ``` 3. Edit the `/var/lib/rancher/k3s/server/manifests/axoflow-config.yaml` file and set the `dex.googleServiceAccount.create` option to `false`. 6. Restart the dex deployment after changing the connector: ```shell kubectl rollout restart deployment/dex -n axoflow ``` Expected output: ```shell deployment.apps/dex restarted ``` 7. Open the main page of your AxoConsole deployment in your browser. You’ll be redirected to the Google authentication page. After completing the Google authentication you can access AxoConsole. ## Getting help You can troubleshoot common errors by running `kubectl logs -n axoflow ` If you run into problems setting up the authentication or authorization, [contact our support team](https://axoflow.com/contact?contact_form_subject=support_request).