Chapter 13. Managing user access

Procedure

1. On the Okta portal, select Applications from the menu bar.
2. Click Add Application and then select Create New App.
3. 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.
4. Click Create.
5. On the General Settings page, enter a name for the app in the App name field.
6. Click Next.

7. On the SAML Settings page, set values for the following fields:

   1. 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.

   2. 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.

   3. Attribute Statements

      • You must add at least one attribute statement.

      • Red Hat recommends using the email attribute:

        • Name: email
        • Format: Unspecified
        • Value: user.email
8. Verify that you have configured at least one Attribute Statement before continuing.
9. Click Next.
10. On the Feedback page, select an option that applies to you.
11. Select an appropriate App type.
12. Click Finish.

Procedure

1. On the RHACS portal, navigate to Platform Configuration → Access Control.
2. Open the Add an Auth Provider menu and select SAML 2.0.

3. Fill out the details for:

   • Integration Name: 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 right sign-in option.
   • ServiceProvider Issuer: The value you are using as the Audience URI or SP Entity ID in Okta, or a similar value in other providers.
   • IdP Metadata URL: Use the URL of Identity Provider metadata available from your identity provider console. If you do not want to use the IdP Metadata URL, you can instead copy the required static fields from the View Setup Instructions link in the Okta console, or a similar location for other providers.

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

   Tip

   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 Configuration → Access 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.

   Note

   Even if the response indicates successful authentication, you might need to create additional access rules based on the user metadata from your identity provider.

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 Credentials → OAuth 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.

    Note

    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.

Procedure

1. On the RHACS portal, navigate to Platform Configuration → Access 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.

     Note

     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.

   Tip

   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 Configuration → Access 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.

Procedure

1. On the RHACS portal, navigate to Platform Configuration → Access Control.
2. Open the Add an Auth Provider menu and select OpenShift Auth.
3. Enter a name for the authentication provider in the Name field.

4. Choose a Minimum access role for users accessing RHACS by using the selected identity provider.

   Tip

   For security, Red Hat recommends 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.

5. 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.

   Tip

   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>/yaml file and note the values for name, uid (userid in RHACS), and groups.
   • 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 name from the Key drop-down list, enter administrator in the Value field, then select Administrator under Role.
   • To configure a rule for a group, select groups from the Key drop-down list, enter myAdministratorsGroup in the Value field, then select Admin under Role.
   • To configure a rule for a user name, select userid from the Key drop-down list, enter 12345-00aa-1234-123b-123fcdef1234 in the Value field, then select Admin under Role.

Procedure

1. On the RHACS portal, navigate to Platform Configuration → Access Control.
2. Click Add an Auth Provider, and then select User Certificates.
3. In the Name box, specify a name for this authentication provider.
4. Paste your root CA certificate in PEM format into the text box.
5. Optional: Change the Minimum access role and add role mappings by attributes.
6. Click Save.

Procedure

1. Create a new authentication provider.
2. Copy the role mappings from your old authentication provider to the new authentication provider.
3. Rename or delete the old authentication provider with the old root CA key.

Procedure

1. Open the RHACS portal.
2. Select a certificate in the browser prompt.
3. On the login page, select the authentication provider name option to log in with a certificate. If you do not want to log in by using the certificate, you can also log in by using the administrator password or another login method.