# 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](). ### 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](). 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](). 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. Verify that Dex is configured as the OIDC provider in the `/var/lib/rancher/k3s/server/manifests/axoflow.yaml` file: * `chalco.oidc.enabled: true` * `chalco.oidc.provider: "dex"` For example: ``` oidc: enabled: true provider: "dex" ``` 2. Configure authentication by editing the `spec.dex.config` section of the `/var/lib/rancher/k3s/server/manifests/axoflow.yaml` file. 1. (Optional) If you’ve used our [earlier example](../../../../docs/axoflow/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: ``` 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](). * `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](../../../../docs/axoflow/deploy/onprem/authentication/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](../../../../docs/axoflow/deploy/onprem/authentication/google/index.md#google-group-membership) prerequisites. ``` # 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.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. * `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](). 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](../../../../docs/axoflow/deploy/onprem/authentication/google/index.md#google-group-membership). ``` 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](../../../../docs/axoflow/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. ``` 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](../../../../docs/axoflow/deploy/onprem/authentication/google/index.md#google-group-membership). ``` kubectl -n axoflow create secret dex-google-service-account --from-file ``` Expected output: ``` secret/dex-google-service-account created ``` 3. Edit the `/var/lib/rancher/k3s/server/manifests/axoflow.yaml` file and set the `dex.googleServiceAccount.create` option to `false`. 6. Restart the dex deployment after changing the connector: ``` kubectl rollout restart deployment/dex -n axoflow ``` Expected output: ``` 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]().