Google SSO Setup
You must create an OpenID Connect (OIDC) application for your Google account.
Follow this Google guide to create an OAuth application. Provide the following inputs when you are asked for them:
Application name: Choose a descriptive name for your specific Redpanda Console deployment (for example Console Analytics Prod)
Application type: Web application
Authorized redirect URI:
The redirect URI is based on the assumption that you want to host Redpanda Console so it is accessible from
Edit the console configuration file associated with your deployment method and incorporate the details from your client application. For example, Kubernetes deployments use the
values.yaml file. Linux deployments use the
redpanda-console-config.yaml file, which is in
login: enabled: true # jwtSecret is the secret key you must use to sign and encrypt the JSON # web token used to store user sessions. This secret key is # critical for the security of Redpanda Console's authentication and # authorization system. Use a long, complex key with a combination of # numbers, letters, and special characters. The minimum number of # characters is 10, but Redpanda recommends using more than 32 # characters. For additional security, use a different secret key for # each environment. jwtSecret can be securely generated with the following # command: LC_ALL=C tr -dc '[:alnum:]' < /dev/random | head -c32 # # If you update this secret key, any users who are # already logged in to Redpanda Console will be logged out and will have # to log in again. jwtSecret: "" google: enabled: true clientId: "" # ClientSecret is sensitive. You can also provide this config by setting # the environment variable LOGIN_GOOGLE_CLIENTSECRET. clientSecret: "" # The directory config is only required if you want to use Google # groups in your role bindings. This is described further in the next section. # directory: # serviceAccountFilepath: "" # targetPrincipal: ""
To bind roles to Google groups from a workspace organization, you must set up a service account so Redpanda Console can retrieve groups and their memberships using the Google Workspace API. Follow this guide to create the required service account and to delegate domain-wide authority to it. Create and download the service account key in JSON format and mount the JSON file so it is available to Console. Specify the filepath to the JSON file in the Redpanda Console configuration file so it can be loaded at startup.
Because only Google users with access to the Admin APIs have access to Google’s
Admin SDK Directory API, the service account must impersonate this user. Specify which user the service account will impersonate
by setting the
targetPrincipal to this user’s email address.
login: google: # The directory config is only required if you want to use Google # groups in your role bindings. directory: # Path to service account key in JSON format # For example: "/etc/mounts/google-sa.json" serviceAccountFilepath: "" # TargetPrincipal is the user that shall be impersonated by the # service account. For example: "email@example.com". targetPrincipal: ""
When you set up the Google login configuration, you can bind Google users or groups to roles. Following is a sample role binding:
roleBindings: - metadata: name: Developers subjects: - kind: group provider: Google name: firstname.lastname@example.org - kind: user provider: Google name: email@example.com roleName: editor
|Group memberships will be resolved proactively in order to support nested groups. If the service account doesn’t have permissions to resolve a certain group membership, a message is printed in the logs. Group memberships are cached for 15 minutes before they are refreshed.|