19.4. Configuring identity providers
19.4.1. Configuring Okta Identity Cloud as a SAML 2.0 identity provider 링크 복사링크가 클립보드에 복사되었습니다!
You can use Okta as a single sign-on (SSO) provider for Red Hat Advanced Cluster Security for Kubernetes (RHACS).
19.4.1.1. Creating an Okta app 링크 복사링크가 클립보드에 복사되었습니다!
Before you can use Okta as a SAML 2.0 identity provider for Red Hat Advanced Cluster Security for Kubernetes, you must create an Okta app.
Okta’s Developer Console does not support the creation of custom SAML 2.0 applications. If you are using the Developer Console, you must first switch to the Admin Console (Classic UI). To switch, click Developer Console in the top left of the page and select Classic UI.
Prerequisites
- You must have an account with administrative privileges for the Okta portal.
Procedure
- On the Okta portal, select Applications from the menu bar.
- Click Add Application and then select Create New App.
- In the Create a New Application Integration dialog box, leave Web as the platform and select SAML 2.0 as the protocol that you want to sign in users.
- Click Create.
- On the General Settings page, enter a name for the app in the App name field.
- Click Next.
On the SAML Settings page, set values for the following fields:
Single sign on URL
-
Specify it as
https://<RHACS_portal_hostname>/sso/providers/saml/acs. - Leave the Use this for Recipient URL and Destination URL option checked.
- If your RHACS portal is accessible at different URLs, you can add them here by checking the Allow this app to request other SSO URLs option and add the alternative URLs using the specified format.
-
Specify it as
Audience URI (SP Entity ID)
- Set the value to RHACS or another value of your choice.
- Remember the value you choose; you will need this value when you configure Red Hat Advanced Cluster Security for Kubernetes.
Attribute Statements
- You must add at least one attribute statement.
Red Hat recommends using the email attribute:
- Name: email
- Format: Unspecified
- Value: user.email
- Verify that you have configured at least one Attribute Statement before continuing.
- Click Next.
- On the Feedback page, select an option that applies to you.
- Select an appropriate App type.
- Click Finish.
After the configuration is complete, you are redirected to the Sign On settings page for the new app. A yellow box contains links to the information that you need to configure Red Hat Advanced Cluster Security for Kubernetes.
After you have created the app, assign Okta users to this application. Go to the Assignments tab, and assign the set of individual users or groups that can access Red Hat Advanced Cluster Security for Kubernetes. For example, assign the group Everyone to allow all users in the organization to access Red Hat Advanced Cluster Security for Kubernetes.
19.4.1.2. Configuring a SAML 2.0 identity provider 링크 복사링크가 클립보드에 복사되었습니다!
Use the instructions in this section to integrate a Security Assertion Markup Language (SAML) 2.0 identity provider with Red Hat Advanced Cluster Security for Kubernetes (RHACS).
Prerequisites
- You must have permissions to configure identity providers in RHACS.
- For Okta identity providers, you must have an Okta app configured for RHACS.
Procedure
-
In the RHACS portal, go to Platform Configuration
Access Control. - Click Create auth provider and select SAML 2.0 from the drop-down list.
- In the Name field, enter a name to identify this authentication provider; for example, Okta or Google. The integration name is shown on the login page to help users select the correct sign-in option.
-
In the ServiceProvider issuer field, enter the value that you are using as the
Audience URIorSP Entity IDin Okta, or a similar value in other providers. Select the type of Configuration:
- Option 1: Dynamic Configuration: If you select this option, enter the IdP Metadata URL, or the URL of Identity Provider metadata available from your identity provider console. The configuration values are acquired from the URL.
Option 2: Static Configuration: Copy the required static fields from the View Setup Instructions link in the Okta console, or a similar location for other providers:
- IdP Issuer
- IdP SSO URL
- Name/ID Format
- IdP Certificate(s) (PEM)
Assign a Minimum access role for users who access RHACS using SAML.
작은 정보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.
- Click Save.
If your SAML identity provider’s authentication response meets the following criteria:
-
Includes a
NotValidAfterassertion: The user session remains valid until the time specified in theNotValidAfterfield has elapsed. After the user session expires, users must reauthenticate. -
Does not include a
NotValidAfterassertion: The user session remains valid for 30 days, and then users must reauthenticate.
Verification
-
In the RHACS portal, go to Platform Configuration
Access Control. - Select the Auth Providers tab.
- Click the authentication provider for which you want to verify the configuration.
- Select Test login from the Auth Provider section header. The Test login page opens in a new browser tab.
Sign in with your credentials.
-
If you logged in successfully, RHACS shows the
User IDandUser Attributesthat the identity provider sent for the credentials that you used to log in to the system. - If your login attempt failed, RHACS shows a message describing why the identity provider’s response could not be processed.
-
If you logged in successfully, RHACS shows the
Close the Test login browser tab.
참고Even if the response indicates successful authentication, you might need to create additional access rules based on the user metadata from your identity provider.
19.4.2. Configuring Google Workspace as an OIDC identity provider 링크 복사링크가 클립보드에 복사되었습니다!
You can use Google Workspace as a single sign-on (SSO) provider for Red Hat Advanced Cluster Security for Kubernetes.
19.4.2.1. 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
- Create a new Google Cloud project, see the Google documentation topic creating and managing projects.
- After you have created the project, open the Credentials page in the Google API Console.
- Verify the project name listed in the upper left corner near the logo to make sure that you are using the correct project.
-
To create new credentials, go to Create Credentials
OAuth client ID. - Choose Web application as the Application type.
- In the Name box, enter a name for the application, for example, RHACS.
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 port443, you can omit the port number.
-
replace
- Click Create. This creates an application and credentials and redirects you back to the credentials page.
- An information box opens, showing details about the newly created application. Close the information box.
-
Copy and save the Client ID that ends with
.apps.googleusercontent.com. You can check this client ID by using the Google API Console. 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.
On the OAuth consent screen page:
- Choose the Application type as Internal. If you select Public, anyone with a Google account can sign in.
- 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.
- 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.
19.4.2.2. 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 Hat 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.
19.4.2.3. Configuring an OIDC identity provider 링크 복사링크가 클립보드에 복사되었습니다!
You can configure Red Hat Advanced Cluster Security for Kubernetes (RHACS) 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 RHACS.
Procedure
-
In the RHACS portal, go to Platform Configuration
Access Control. - Click Create auth provider and select OpenID Connect from the drop-down list.
Enter information in the following fields:
- Name: A name to identify your authentication provider; for example, Google Workspace. The integration name is shown on the login page to help users select the correct sign-in option.
Callback mode: Select Auto-select (recommended), which is the default value, unless the identity provider requires another mode.
참고Fragmentmode is designed around the limitations of Single Page Applications (SPAs). Red Hat only supports theFragmentmode for early integrations and does not recommended using it for later integrations.Issuer: The root URL of your identity provider; for example,
https://accounts.google.comfor Google Workspace. See your identity provider documentation for more information.참고If you are using RHACS version 3.0.49 and later, for Issuer you can perform these actions:
-
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=value2along with the root URL. RHACS appends the value of Issuer as you entered it 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 thehdparameter, or preselect an authentication method inPingFederateby using thepfidpadapteridparameter.
-
Prefix your root URL with
- Client ID: The OIDC Client ID for your configured project.
- Client Secret: Enter the client secret provided by your identity provider (IdP). If you are not using a client secret, which is not recommended, select Do not use Client Secret.
Assign a Minimum access role for users who access RHACS 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.
To add access rules for users and groups accessing RHACS, click Add new rule in the Rules section. For example, to give the Admin role to a user called
administrator, you can use the following key-value pairs to create access rules:Key
Value
Name
administrator
Role
Admin
- Click Save.
Verification
-
In the RHACS portal, go to Platform Configuration
Access Control. - Select the Auth providers tab.
- Select the authentication provider for which you want to verify the configuration.
- Select Test login from the Auth Provider section header. The Test login page opens in a new browser tab.
Log in with your credentials.
-
If you logged in successfully, RHACS shows the
User IDandUser Attributesthat the identity provider sent for the credentials that you used to log in to the system. - If your login attempt failed, RHACS shows a message describing why the identity provider’s response could not be processed.
-
If you logged in successfully, RHACS shows the
- Close the Test Login browser tab.
19.4.3. Configuring OpenShift Container Platform OAuth server as an identity provider 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform includes a built-in OAuth server that you can use as an authentication provider for Red Hat Advanced Cluster Security for Kubernetes (RHACS).
19.4.3.1. Configuring OpenShift Container Platform OAuth server as an identity provider 링크 복사링크가 클립보드에 복사되었습니다!
To integrate the built-in OpenShift Container Platform OAuth server as an identity provider for RHACS, use the instructions in this section.
Prerequisites
-
You must have the
Accesspermission to configure identity providers in RHACS. - You must have already configured users and groups in OpenShift Container Platform OAuth server through an identity provider. For information about the identity provider requirements, see Understanding identity provider configuration.
The following procedure configures only a single main route named central for the OpenShift Container Platform OAuth server.
Procedure
-
In the RHACS portal, go to Platform Configuration
Access Control. - Click Create auth provider and select OpenShift Auth from the drop-down list.
- Enter a name for the authentication provider in the Name field.
Assign a Minimum access role for users that access RHACS using the selected identity provider. A user must have the permissions granted to this role or a role with higher permissions to log in to RHACS.
작은 정보For security, Red Hat recommends first setting the Minimum access role to None 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.
Optional: To add access rules for users and groups accessing RHACS, click Add new rule in the Rules section, then enter the rule information and click Save. You will need attributes for the user or group so that you can configure access.
작은 정보Group mappings are more robust because groups are usually associated with teams or permissions sets and require modification less often than users.
To get user information in OpenShift Container Platform, you can use one of the following methods:
-
Click User Management
Users <username> YAML. -
Access the
k8s/cluster/user.openshift.io~v1~User/<username>/yamlfile and note the values forname,uid(useridin RHACS), andgroups. - Use the OpenShift Container Platform API as described in the OpenShift Container Platform API reference.
The following configuration example describes how to configure rules for an Admin role with the following attributes:
-
name:administrator -
groups:["system:authenticated", "system:authenticated:oauth", "myAdministratorsGroup"] -
uid:12345-00aa-1234-123b-123fcdef1234
You can add a rule for this administrator role using one of the following steps:
-
To configure a rule for a name, select
namefrom the Key drop-down list, enteradministratorin the Value field, then select Administrator under Role. -
To configure a rule for a group, select
groupsfrom the Key drop-down list, entermyAdministratorsGroupin the Value field, then select Admin under Role. -
To configure a rule for a user name, select
useridfrom the Key drop-down list, enter12345-00aa-1234-123b-123fcdef1234in the Value field, then select Admin under Role.
-
Click User Management
- If you use a custom TLS certificate for OpenShift Container Platform OAuth server, you must add the root certificate of the CA to Red Hat Advanced Cluster Security for Kubernetes as a trusted root CA. Otherwise, Central cannot connect to the OpenShift Container Platform OAuth server.
To enable the OpenShift Container Platform OAuth server integration when installing Red Hat Advanced Cluster Security for Kubernetes using the
roxctlCLI, set theROX_ENABLE_OPENSHIFT_AUTHenvironment variable totruein Central:$ oc -n stackrox set env deploy/central ROX_ENABLE_OPENSHIFT_AUTH=true-
For access rules, the OpenShift Container Platform OAuth server does not return the key
Email.
19.4.3.2. Creating additional routes for OpenShift Container Platform OAuth server 링크 복사링크가 클립보드에 복사되었습니다!
When you configure OpenShift Container Platform OAuth server as an identity provider by using Red Hat Advanced Cluster Security for Kubernetes portal, RHACS configures only a single route for the OAuth server. However, you can create additional routes by specifying them as annotations in the Central custom resource.
Prerequisites
- You must have configured Service accounts as OAuth clients for your OpenShift Container Platform OAuth server.
Procedure
If you installed RHACS using the RHACS Operator:
Create a
CENTRAL_ADDITIONAL_ROUTESenvironment variable that contains a patch for the Central custom resource:$ CENTRAL_ADDITIONAL_ROUTES=' spec: central: exposure: loadBalancer: enabled: false port: 443 nodePort: enabled: false route: enabled: true persistence: persistentVolumeClaim: claimName: stackrox-db customize: annotations: serviceaccounts.openshift.io/oauth-redirecturi.main: sso/providers/openshift/callback serviceaccounts.openshift.io/oauth-redirectreference.main: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"central\"}}" serviceaccounts.openshift.io/oauth-redirecturi.second: sso/providers/openshift/callback serviceaccounts.openshift.io/oauth-redirectreference.second: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"second-central\"}}" 'where:
spec.customize.annotations.serviceaccounts.openshift.io/oauth-redirecturi.main- Specifies the redirect URI for setting the main route.
spec.customize.annotations.serviceaccounts.openshift.io/oauth-redirectreference.main- Specifies the redirect URI reference for the main route.
spec.customize.annotations.serviceaccounts.openshift.io/oauth-redirecturi.second- Specifies the redirect for setting the second route.
spec.customize.annotations.serviceaccounts.openshift.io/oauth-redirectreference.second- Specifies the redirect reference for the second route.
Apply the
CENTRAL_ADDITIONAL_ROUTESpatch to the Central custom resource:$ oc patch centrals.platform.stackrox.io \ -n <namespace> \ <custom-resource> \ --patch "$CENTRAL_ADDITIONAL_ROUTES" \ --type=mergewhere:
<namespace>- Specifies the name of the project that contains the Central custom resource.
<custom-resource>- Specifies the name of the Central custom resource.
Or, if you installed RHACS using Helm:
Add the following annotations to your
values-public.yamlfile:customize: central: annotations: serviceaccounts.openshift.io/oauth-redirecturi.main: sso/providers/openshift/callback serviceaccounts.openshift.io/oauth-redirectreference.main: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"central\"}}" serviceaccounts.openshift.io/oauth-redirecturi.second: sso/providers/openshift/callback serviceaccounts.openshift.io/oauth-redirectreference.second: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"second-central\"}}"where:
customize.central.annotations.serviceaccounts.openshift.io/oauth-redirecturi.main- Specifies the redirect for setting the main route.
customize.central.annotations.serviceaccounts.openshift.io/oauth-redirectreference.main- Specifies the redirect reference for the main route.
customize.central.annotations.serviceaccounts.openshift.io/oauth-redirecturi.second- Specifies the redirect for setting the second route.
customize.central.annotations.serviceaccounts.openshift.io/oauth-redirectreference.second- Specifies the redirect reference for the second route.
Apply the custom annotations to the Central custom resource by using
helm upgrade:$ helm upgrade -n stackrox \ stackrox-central-services rhacs/central-services \ -f <path_to_values_public.yaml>where:
<path_to_values_public.yaml>-
Specifies the path of the
values-public.yamlconfiguration file.
19.4.4. Connecting Azure AD to RHACS using SSO configuration 링크 복사링크가 클립보드에 복사되었습니다!
To connect an Azure Active Directory (AD) to RHACS using Sign-On (SSO) configuration, you need to add specific claims (for example, group claim to tokens) and assign users, groups, or both to the enterprise application.
19.4.4.1. Adding group claims to tokens for SAML applications using SSO configuration 링크 복사링크가 클립보드에 복사되었습니다!
Configure the application registration in Azure AD to include group claims in tokens. For instructions, see Add group claims to tokens for SAML applications using SSO configuration.
Verify that you are using the latest version of Azure AD. For more information on how to upgrade Azure AD to the latest version, see Azure AD Connect: Upgrade from a previous version to the latest.