Chapter 18. Managing user access

Procedure

1. In the RHACS portal, go to Platform Configuration Access control.
2. Select Roles.

3. Click one of the roles to view its details. The details page shows the permission set and access scope for the selected role.

   Note

   You cannot change permission set and access scope for the default system roles.

Procedure

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Select Roles.
3. Click Create role.
4. Enter a Name and Description for the new role.
5. Select a Permission set for the role.
6. Select an Access scope for the role.
7. Click Save.

Procedure

1. In the RHACS portal, go to Platform Configuration Access Control.
2. From the list of authentication providers, select the authentication provider.
3. Click Edit minimum role and rules.
4. Under the Rules section, click Add new rule.
5. For Key, select one of the values from userid, name, email, or groups. The available choices depend on the authentication provider.
6. For Value, enter the value of the user ID, name, email address, or group based on the key you selected. For example, to assign the Analyst role to a user by email, after selecting email for the Key field, enter the email address of the user.
7. Click the Role drop-down menu and select the role you want to assign. For example, to assign the Analyst role to a user whose email you have entered, select Analyst.

8. Click Save.

   You can repeat these instructions for each user or group and assign different roles. For role aggregation, you can use the same key/value pair with many roles. For example, you can create a rule that assigns the Analyst role to the user jsmith@example.com, and then add another rule to assign the Vulnerability Report Creator role to the same user. For more information about roles, see "System roles".

Procedure

1. In the RHACS portal, go to Platform Configuration Access control.
2. Select Permission sets.

3. Click one of the permission sets to view its details. The details page shows a list of resources and their permissions for the selected permission set.

   Note

   You cannot change permissions for a system permission set.

Procedure

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Select Permission sets.
3. Click Create permission set.
4. Enter a Name and Description for the new permission set.

5. For each resource, under the Access level column, select one of the permissions from No access, Read access, or Read and Write access.

   Warning

   • If you are configuring a permission set for users, you must grant read-only permissions for the following resources:

     • Alert
     • Cluster
     • Deployment
     • Image
     • NetworkPolicy
     • NetworkGraph
     • WorkflowAdministration
     • Secret
   • The system preselects these permissions when you create a new permission set.
   • If you do not grant these permissions, users will experience issues with viewing pages in the RHACS portal.
6. Click Save.

Procedure

1. In the RHACS portal, go to Platform Configuration Access control.
2. Select Access scopes.

3. Click one of the access scopes to view its details. The details page shows a list of clusters and namespaces, and which ones are allowed for the selected access scope.

   Note

   You cannot change allowed resources for a system access scope.

Procedure

1. In the RHACS portal, go to Platform Configuration Access control.
2. Select Access scopes.
3. Click Create access scope.
4. Enter a Name and Description for the new access scope.
5. Under the Allowed resources section, use the Cluster filter and Namespace filter fields to filter the list of clusters and namespaces visible in the list.
6. Expand the Cluster name to see the list of namespaces in that cluster.

7. To allow access to all namespaces in a cluster, toggle the switch in the Manual selection column.

   Note

   Access to a specific cluster grants users access to the following resources within the scope of the cluster:

   • OpenShift Container Platform or Kubernetes cluster metadata and security information
   • Compliance information for authorized clusters
   • Node metadata and security information
   • Access to all namespaces in that cluster and their associated security information

8. To allow access to a namespace, toggle the switch in the Manual selection column for a namespace.

   Note

   Access to a specific namespace grants access to the following information within the scope of the namespace:

   • Alerts and violations for deployments
   • Vulnerability data for images
   • Deployment metadata and security information
   • Role and user information
   • Network graph, policy, and baseline information for deployments
   • Process information and process baseline configuration
   • Prioritized risk information for each deployment
9. If you want to allow access to clusters and namespaces based on labels, click Add label selector under the Label selection rules section. Then click Add rule to specify Key and Value pairs for the label selector. You can specify labels for clusters and namespaces.
10. Click Save.

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. In the RHACS portal, go to Platform Configuration Access Control.
2. Click Create auth provider and select SAML 2.0 from the drop-down list.
3. In the Name field, enter a name to identify this authentication provider; for example, Okta or Google. The login page shows the integration name to help users select the correct sign-in option.
4. In the ServiceProvider issuer field, enter the value that you are using as the Audience URI or SP Entity ID in Okta, or a similar value in other providers.

5. 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 system acquires the configuration values 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)

6. Assign a Minimum access role for users who access RHACS using SAML.

   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.

7. Click Save.

   Important

   If your SAML identity provider’s authentication response meets the following criteria:

   • Includes a NotValidAfter assertion: The user session remains valid until the time specified in the NotValidAfter field has elapsed. After the user session expires, users must reauthenticate.
   • Does not include a NotValidAfter assertion: The user session remains valid for 30 days, and then users must reauthenticate.

Verification

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Select the Auth Providers tab.
3. Click the authentication provider for which you want to verify the configuration.
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.

   • If you logged in successfully, RHACS shows the User ID and User Attributes that the identity provider sent for the credentials that you used to log in to the system.
   • If your login try failed, RHACS shows a message describing why the system could not process the identity provider’s response.

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 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 earlier 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 displayed 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. Single sign-on requires only these scopes. If you grant additional scopes it increases the risk of exposing sensitive data.

Procedure

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Click Create auth provider and select OpenID Connect from the drop-down list.

3. Enter information in the following fields:

   • Name: A name to identify your authentication provider; for example, Google Workspace. The integration name is displayed 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.

     Note

     Fragment mode works around the limitations of Single Page Applications (SPAs). Red Hat only supports the Fragment mode 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.com for Google Workspace. See your identity provider documentation for more information.

     Note

     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=value2 along 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 the hd parameter, or preselect an authentication method in PingFederate by using the pfidpadapterid parameter.
   • 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.

4. Assign a Minimum access role for users who access RHACS 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. 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

6. Click Save.

Verification

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Select the Auth providers tab.
3. Select the authentication provider for which you want to verify the configuration.
4. Select Test login from the Auth Provider section header. The Test login page opens in a new browser tab.

5. Log in with your credentials.

   • If you logged in successfully, RHACS shows the User ID and User Attributes that the identity provider sent for the credentials that you used to log in to the system.
   • If your login failed, RHACS shows a message describing why it could not process the identity provider’s response.
6. Close the Test Login browser tab.

Procedure

1. In the RHACS portal, go to Platform Configuration Access Control.
2. Click Create auth provider and select OpenShift Auth from the drop-down list.
3. Enter a name for the authentication provider in the Name field.

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

   Tip

   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.

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 by 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. In the RHACS portal, select Platform Configuration Access Control.
2. Select Permission Sets.
3. Click Create permission set.
4. Enter a Name and Description for the permission set.

5. Select the following resources and access level and click Save:

   • READ Alert
   • READ Deployment
   • READ DeploymentExtension
   • READ Image
   • READ K8sRole
   • READ K8sRoleBinding
   • READ K8sSubject
   • READ NetworkGraph
   • READ NetworkPolicy
   • READ Secret
   • READ ServiceAccount
6. Select Access Scopes.
7. Click Create access scope.
8. Enter a Name and Description for the access scope.
9. In the Allowed resources section, select the namespace you want to use for scoping and click Save.
10. Select Roles.
11. Click Create role.
12. Enter a Name and Description for the role.
13. Select the Permission Set and Access scope that you created before for the role and click Save.

14. Assign the role to your required user or group.

    Note

    The RHACS dashboard options for users with the sample role are minimal compared to options available to an administrator. Only relevant pages are visible for the user.