Google SSO Setup
Follow this Google guide to create an OAuth application at Google. As you follow the guide to create the OAuth app, use the following inputs when you are asked for it:
The following configurations are based on the assumption that you want to host Redpanda Console so that it would be accessible using
Application name: Any descriptive name for your specific Console deployment (for example Console Analytics Prod)
Application type: Web application
Authorized redirect URI:
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. While you must use a minimum of # 10 characters, 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 into Redpanda Console will be logged out and will have # to log in again. jwtSecret: "" google: enabled: true clientId: "" # ClientSecret is sensitive. You can provide this config also via the # the environment variable LOGIN_GOOGLE_CLIENTSECRET clientSecret: "" # The directory config is only required if you want to use Google # groups in your role bindings. Described further in the next section. # directory: # serviceAccountFilepath: "" # targetPrincipal: ""
If you want to bind roles to Google groups from a workspace organization you have to set up a service account, so that 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. Make sure to create and download the service account key in JSON format.
You need to make the service account key (a JSON file) available to Console by mounting the file. The Console configuration expects you to specify
the filepath to the JSON file so that 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, it is required that the service account impersonates such a user. Specify which user the service account shall 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: "firstname.lastname@example.org". 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: email@example.com - kind: user provider: Google name: firstname.lastname@example.org 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 memberships, it will be printed in the logs. Group memberships will be cached for 15 minutes before they will be refreshed.|