This is a cache of https://docs.openshift.com/acs/3.66/operating/manage-user-access/configure-google-workspace-identity.html. It is a snapshot of the page at 2024-11-23T17:20:25.615+0000.
Configuring Google Workspace as an OIDC identity provider - Managing <strong>user</strong> access | Operating | Red Hat Advanced Cluster Security for Kubernetes 3.66
×

Setting up OAuth 2.0 credentials for your GCP project

To configure Google Workspace as an identity provider for Red Hat Advanced Cluster Security for Kubernetes, you must first configure OAuth 2.0 credentials for your GCP project.

Prerequisites
  • You must have administrator-level access to your organization’s Google Workspace account to create a new project, or permissions to create and configure OAuth 2.0 credentials for an existing project. Red Hat recommends that you create a new project for managing access to Red Hat Advanced Cluster Security for Kubernetes.

Procedure
  1. Create a new Google Cloud Platform (GCP) project, see the Google documentation topic creating and managing projects.

  2. After you have created the project, open the Credentials page in the Google API Console.

  3. Verify the project name listed in the upper left corner near the logo to make sure that you are using the correct project.

  4. To create new credentials, go to Create CredentialsOAuth client ID.

  5. Choose Web application as the Application type.

  6. In the Name box, enter a name for the application, for example, RHACS.

  7. In the Authorized redirect URIs box, enter https://<stackrox_hostname>:<port_number>/sso/providers/oidc/callback.

    • replace <stackrox_hostname> with the hostname on which you expose your Central instance.

    • replace <port_number> with the port number on which you expose Central. If you are using the standard HTTPS port 443, you can omit the port number.

  8. Click Create. This creates an application and credentials and redirects you back to the credentials page.

  9. An information box opens, showing details about the newly created application. Close the information box.

  10. Copy and save the Client ID that ends with .apps.googleusercontent.com. You can check this client ID by using the Google API Console.

  11. Select OAuth consent screen from the navigation menu on the left.

    The OAuth consent screen configuration is valid for the entire GCP project, and not only to the application you created in the previous steps. If you already have an OAuth consent screen configured in this project and want to apply different settings for Red Hat Advanced Cluster Security for Kubernetes login, create a new GCP project.

  12. On the OAuth consent screen page:

    1. Choose the Application type as Internal. If you select Public, anyone with a Google account can sign in.

    2. Enter a descriptive Application name. This name is shown to users on the consent screen when they sign in. For example, use RHACS or <organization_name> SSO for Red Hat Advanced Cluster Security for Kubernetes.

    3. Verify that the Scopes for Google APIs only lists email, profile, and openid scopes. Only these scopes are required for single sign-on. If you grant additional scopes it increases the risk of exposing sensitive data.

Specifying a client secret

Red Hat Advanced Cluster Security for Kubernetes version 3.0.39 and newer supports the OAuth 2.0 Authorization Code Grant authentication flow when you specify a client secret. When you use this authentication flow, Red Hat Advanced Cluster Security for Kubernetes uses a refresh token to keep users logged in beyond the token expiration time configured in your OIDC identity provider.

When users log out, Red Hat Advanced Cluster Security for Kubernetes deletes the refresh token from the client-side. Additionally, if your identity provider API supports refresh token revocation, Red Hat Advanced Cluster Security for Kubernetes also sends a request to your identity provider to revoke the refresh token.

You can specify a client secret when you configure Red Hat Advanced Cluster Security for Kubernetes to integrate with an OIDC identity provider.

  • You cannot use a Client Secret with the Fragment Callback mode.

  • You cannot edit configurations for existing authentication providers.

  • You must create a new OIDC integration in Red Hat Advanced Cluster Security for Kubernetes if you want to use a Client Secret.

Red Hats recommends using a client secret when connecting Red Hat Advanced Cluster Security for Kubernetes with an OIDC identity provider. If you do not want to use a Client Secret, you must select the Do not use Client Secret (not recommended) option.

Configuring an OIDC identity provider in Red Hat Advanced Cluster Security for Kubernetes

You can configure Red Hat Advanced Cluster Security for Kubernetes to use your OpenID Connect (OIDC) identity provider.

Prerequisites
  • You must have already configured an application in your identity provider, such as Google Workspace.

  • You must have permissions to configure identity providers in Red Hat Advanced Cluster Security for Kubernetes.

Procedure
  1. On the RHACS portal, navigate to Platform ConfigurationAccess Control.

  2. Open the Add an Auth Provider menu and select OpenID Connect.

  3. Fill out the details for:

    • Integration Name: A name to identify your authentication provider. For example, Auth0 or Google Workspace". The integration name is shown on the login page to help users select the right sign-in option.

    • Callback Mode: Select HTTP POST (default). An alternative mode called Fragment, designed around the limitations of Single Page Applications (SPAs), is also available. Red Hat only supports the Fragment mode for legacy integrations, and does not recommended using it for new integrations.

    • Issuer: The root URL of your identity provider, for example https://accounts.google.com for Google Workspace. See your identity provider documentation for more information.

      If you are using Red Hat Advanced Cluster Security for Kubernetes version 3.0.49 and newer, for Issuer you can:

      • Prefix your root URL with https+insecure:// to skip TLS validation. This configuration is insecure and Red Hat does not recommended it. Only use it for testing purposes.

      • Specify query strings, for example, ?key1=value1&key2=value2 along with the root URL. Red Hat Advanced Cluster Security for Kubernetes appends the value of Issuer as is to the authorization endpoint. You can use it to customize your provider’s login screen. For example, you can optimize the Google Workspace login screen to a specific hosted domain by using the hd parameter, or pre-select an authentication method in PingFederate by using the pfidpadapterid parameter.

    • Client ID: The OIDC Client ID for your configured project.

  4. Choose a Minimum access role for users accessing Red Hat Advanced Cluster Security for Kubernetes by using the selected identity provider.

    Set the Minimum access role to Admin while you complete setup. Later, you can return to the Access Control page to set up more tailored access rules based on user metadata from your identity provider.

  5. Click Save.

Verification
  1. On the RHACS portal, navigate to Platform ConfigurationAccess Control.

  2. Select the Auth Provider Rules tab.

  3. Under the Auth Providers section, select the authentication provider that you want to verify the configuration for.

  4. Select Test Login from the Auth Provider section header. The Test Login page opens in a new browser tab.

  5. Sign in with your credentials.

    • On success, Red Hat Advanced Cluster Security for Kubernetes shows the user ID and user Attributes the identity provider sent for the credentials you have used to log in.

    • On failure, Red Hat Advanced Cluster Security for Kubernetes shows a message describing why the identity provider’s response could not be processed.

  6. Close the Test Login browser tab.