Menu Close
Settings Close

Language and Page Formatting Options

Chapter 13. Managing user access

13.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).

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

Warning

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

  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.

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.

13.1.2. Configuring a SAML 2.0 identity provider in Red Hat Advanced Cluster Security for Kubernetes

Use the instructions in this section to integrate a SAML 2.0 identity provider with Red Hat Advanced Cluster Security for Kubernetes.

Prerequisites

  • You must have permissions to configure identity providers in Red Hat Advanced Cluster Security for Kubernetes.
  • You must have an Okta app configured for Red Hat Advanced Cluster Security for Kubernetes.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess 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.
Important

If your SAML identity provider’s authentication response:

  • Includes a NotValidAfter assertion, the user session remains valid until the time specified in the NotValidAfter field has elapsed. After its expiry, users must re-authenticate.
  • Does not include a NotValidAfter assertion, the user session remains valid for 30 days, after which, the users must re-authenticate.

Verification

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

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

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

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

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

Note
  • 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 Hats 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.

13.2.3. Configuring an OIDC identity provider in Red Hat Advanced Cluster Security for Kubernetes

You can configure Red Hat Advanced Cluster Security for Kubernetes 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 Red Hat Advanced Cluster Security for Kubernetes.

Procedure

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

13.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).

13.3.1. Configuring OpenShift Container Platform OAuth server as an identity provider in Red Hat Advanced Cluster Security for Kubernetes

To integrate the built-in OpenShift Container Platform OAuth server as an identity provider for Red Hat Advanced Cluster Security for Kubernetes (RHACS) use the instructions in this section.

Prerequisites

  • You must have the AuthProvider permission 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.
Note

The following procedure configures only a single main route named central for the OpenShift Container Platform OAuth server.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess 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 ManagementUsers<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.
Important
  • 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 roxctl CLI, set the ROX_ENABLE_OPENSHIFT_AUTH environment variable to true in 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.

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

Procedure

  • If you installed RHACS using the RHACS Operator:

    1. Create a CENTRAL_ADDITIONAL_ROUTES environment 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 1
            serviceaccounts.openshift.io/oauth-redirectreference.main: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"central\"}}" 2
            serviceaccounts.openshift.io/oauth-redirecturi.second: sso/providers/openshift/callback 3
            serviceaccounts.openshift.io/oauth-redirectreference.second: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"second-central\"}}" 4
      '
      1
      The redirect URI for setting the main route.
      2
      The redirect URI reference for the main route.
      3
      The redirect for setting the second route.
      4
      The redirect reference for the second route.
    2. Apply the CENTRAL_ADDITIONAL_ROUTES patch to the Central custom resource:

      $ oc patch centrals.platform.stackrox.io \
        -n <namespace> \ 1
        <custom-resource> \ 2
        --patch "$CENTRAL_ADDITIONAL_ROUTES" \
        --type=merge
      1
      Replace <namespace> with the name of the project that contains the Central custom resource.
      2
      Replace <custom-resource> with the name of the Central custom resource.
  • Or, if you installed RHACS using Helm:

    1. Add the following annotations to your values-public.yaml file:

      customize:
        central:
          annotations:
            serviceaccounts.openshift.io/oauth-redirecturi.main: sso/providers/openshift/callback 1
            serviceaccounts.openshift.io/oauth-redirectreference.main: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"central\"}}" 2
            serviceaccounts.openshift.io/oauth-redirecturi.second: sso/providers/openshift/callback 3
            serviceaccounts.openshift.io/oauth-redirectreference.second: "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"second-central\"}}" 4
      1
      The redirect for setting the main route.
      2
      The redirect reference for the main route.
      3
      The redirect for setting the second route.
      4
      The redirect reference for the second route.
    2. 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> 1
      1
      Specify the path of the values-public.yaml configuration file using the -f option.

13.4. Managing RBAC in Red Hat Advanced Cluster Security for Kubernetes

Red Hat Advanced Cluster Security for Kubernetes (RHACS) comes with role-based access control (RBAC) that you can use to configure roles and grant various levels of access to Red Hat Advanced Cluster Security for Kubernetes for different users.

Red Hat Advanced Cluster Security for Kubernetes 3.63 includes a scoped access control feature that enables you to configure fine-grained and specific sets of permissions that define how a given Red Hat Advanced Cluster Security for Kubernetes user or a group of users can interact with Red Hat Advanced Cluster Security for Kubernetes, which resources they can access, and which actions they can perform.

  • Roles are a collection of permission sets and access scopes. You can assign roles to users and groups by specifying rules. You can configure these rules when you configure an authentication provider. There are two types of roles in Red Hat Advanced Cluster Security for Kubernetes:

    • System roles that are created by Red Hat and cannot be changed.
    • Custom roles, which Red Hat Advanced Cluster Security for Kubernetes administrators can create and change at any time.

      Note
      • If you assign multiple roles for a user, they get access to the combined permissions of the assigned roles.
      • If you have users assigned to a custom role, and you delete that role, all associated users transfer to the minimum access role that you have configured.
  • Permission sets are a set of permissions that define what actions a role can perform on a given resource. Resources are the functionalities of Red Hat Advanced Cluster Security for Kubernetes for which you can set view (read) and modify (write) permissions. There are two types of permission sets in Red Hat Advanced Cluster Security for Kubernetes:

    • System permission sets, which are created by Red Hat and cannot be changed.
    • Custom permission sets, which Red Hat Advanced Cluster Security for Kubernetes administrators can create and change at any time.
  • Access scopes are a set of Kubernetes and OpenShift Container Platform resources that users can access. For example, you can define an access scope that only allows users to access information about pods in a given project. There are two types of access scopes in Red Hat Advanced Cluster Security for Kubernetes:

    • System access scopes, which are created by Red Hat and cannot be changed.
    • Custom access scopes, which Red Hat Advanced Cluster Security for Kubernetes administrators can create and change at any time.

13.4.1. System roles

Red Hat Advanced Cluster Security for Kubernetes includes some default system roles that you can apply to users when you create rules. You can also create custom roles as required.

System roleDescription

Admin

This role is targeted for administrators. Use it to provide read and write access to all resources.

Analyst

This role is targeted for a user who cannot make any changes, but can view everything. Use it to provide read-only access for all resources.

Continuous Integration

This role is targeted for CI (continuous integration) systems and includes the permission set required to enforce deployment policies.

None

This role has no read and write access to any resource. You can set this role as the minimum access role for all users.

Sensor Creator

Red Hat Advanced Cluster Security for Kubernetes uses this role to automate new cluster setups. It includes the permission set to create Sensors in secured clusters.

Scope Manager

This role includes the minimum permissions required to create and modify access scopes.

13.4.1.1. Viewing the permission set and access scope for a system role

You can view the permission set and access scope for the default system roles.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select Roles.
  3. Click on one of the roles to view its details. The details page shows the permission set and access scope for the slected role.
Note

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

13.4.1.2. Creating a custom role

You can create new roles from the Access Control view.

Prerequisites

  • You must have the Admin role, or a role with the permission set with read and write permissions for the AuthProvider and Role resources to create, modify, and delete custom roles.
  • You must create a permissions set and an access scope for the custom role before creating the role.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select the Roles tab.
  3. Click Add 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.

13.4.1.3. Assigning a role to a user or a group

You can use the RHACS portal to assign roles to a user or a group.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess 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 group.
  6. For Value, enter the value of the user ID, name, email address or group based on the key you selected.
  7. Click the Role drop-down menu and select the role you want to assign.
  8. Click Save.

You can repeat these instructions for each user or group and assign different roles.

13.4.2. System permission sets

Red Hat Advanced Cluster Security for Kubernetes includes some default system permission sets that you can apply to roles. You can also create custom permission sets as required.

Permission setDescription

Admin

Provides read and write access to all resources.

Analyst

Provides read-only access for all resources.

Continuous Integration

This permission set is targeted for CI (continuous integration) systems and includes the permissions required to enforce deployment policies.

None

No read and write permissions are allowed for any resource.

Sensor Creator

Provides permissions for resources that are required to create Sensors in secured clusters.

13.4.2.1. Viewing the permissions for a system permission set

You can view the permissions for a system permission set in the RHACS portal.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select Permission sets.
  3. Click on 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 modify permissions for a system permission set.

13.4.2.2. Creating a custom permission set

You can create new permission sets from the Access Control view.

Prerequisites

  • You must have the Admin role, or a role with the permission set with read and write permissions for the AuthProvider and Role resources to create, modify, and delete permission sets.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select the Permission sets tab.
  3. Click Add 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, 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
      • Policy
      • Secret
    • These permissions are pre-selected 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.

13.4.3. System access scopes

Red Hat Advanced Cluster Security for Kubernetes includes some default system access scopes that you can apply on roles. You can also create custom access scopes as required.

Acces scopeDescription

Unrestricted

Provides access to all clusters and namespaces that Red Hat Advanced Cluster Security for Kubernetes monitors.

Deny All

Provides no access to any Kubernetes and OpenShift Container Platform resources.

13.4.3.1. Viewing the details for a system access scope

You can view the Kubernetes and OpenShift Container Platform resources that are allowed and not allowed for an access scope in the RHACS portal.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select Access scopes.
  3. Click on 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 modify allowed resources for a system access scope.

13.4.3.2. Creating a custom access scope

You can create new access scopes from the Access Control view.

Prerequisites

  • You must have the Admin role, or a role with the permission set with read and write permissions for the AuthProvider and Role resources to create, modify, and delete permission sets.

Procedure

  1. On the RHACS portal, navigate to Platform ConfigurationAccess control.
  2. Select the Access scope tab.
  3. Click Add 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 boxes to filter the list of clusters and namespaces visible in the list.
    • Expand the <Cluster_name> to see the list of namespaces in that cluster.
    • Turn on the toggle under the Manual selection column for a cluster to allow access to all namespaces in that cluster.

      Note

      Access to a specific cluster provides users with 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
    • Turn on the toggle under the Manual selection column for a namespace to allow access to that namespace.

      Note

      Access to a specific namespace gives 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
  6. 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 rules to specify Key and Value pairs for the label selector. You can specify labels for clusters and namespaces.
  7. Click Save.

13.4.4. Resource definitions

Red Hat Advanced Cluster Security for Kubernetes includes multiple resources. The following table lists the resources and describes the actions that users can perform with the read or write permission.

ResourceRead permissionWrite permission

APIToken

List existing API tokens.

Create new API tokens or revoke existing tokens.

Alert

View existing policy violations.

Resolve or edit policy violations.

AuthPlugin

View existing Authentication plug-ins

Modify these configurations. (Local administrator only.)

AuthProvider

View existing configurations for single sign-on.

Modify these configurations.

BackupPlugins

View existing integrations with automated backup systems such as AWS S3.

Modify these configurations.

CVE

Internal use only

Internal use only

Cluster

View existing secured clusters.

Add new secured clusters and modify or delete existing clusters.

Compliance

View compliance standards and results.

N/A

ComplianceRunSchedule

View scheduled compliance runs.

Create, modify, or delete scheduled compliance runs.

ComplianceRuns

View recent compliance runs and their completion status.

Trigger compliance runs.

Config

View options for data retention, security notices, and other related configurations.

Modify these configurations.

DebugLogs

View the current logging verbosity level in Red Hat Advanced Cluster Security for Kubernetes components.

Modify the logging level.

Deployment

View deployments (workloads) in secured clusters.

N/A

Detection

Check build-time policies against images or deployment YAML.

N/A

Group

View the existing RBAC rules that match user metadata to Red Hat Advanced Cluster Security for Kubernetes roles.

Create, modify, or delete configured RBAC rules.

Image

View images, their components, and their vulnerabilities.

N/A

ImageComponent

Internal use only

Internal use only

ImageIntegration

List existing image registry integrations.

Create, edit, or delete image registry integrations.

ImbuedLogs

Internal use only

Internal use only

Indicator

View process activity in deployments.

N/A

K8sRole

View roles for Kubernetes role-based access control in secured clusters.

N/A

K8sRoleBinding

View role bindings for Kubernetes role-based access control in secured clusters.

N/A

K8sSubject

View users and groups for Kubernetes role-based access control in secured clusters.

N/A

Licenses

View the status of the existing license for Red Hat Advanced Cluster Security for Kubernetes.

Upload a new license key.

Namespace

View existing Kubernetes namespaces in secured clusters.

N/A

NetworkGraph

View active and allowed network connections in secured clusters.

N/A

NetworkPolicy

View existing network policies in secured clusters and simulate changes.

Apply network policy changes in secured clusters.

Node

View existing Kubernetes nodes in secured clusters.

N/A

Notifier

View existing integrations for notification systems like email, Jira, or webhooks.

Create, modify, or delete these integrations.

Policy

View existing system policies.

Create, modify, or delete system policies.

ProbeUpload

Read manifests for the uploaded probe files.

Upload support packages to Central.

ProcessWhitelist

View process baselines.

Add or remove processes from baselines.

Risk

View Risk results.

N/A

Role

View existing Red Hat Advanced Cluster Security for Kubernetes RBAC roles and their permissions.

Add, modify, or delete roles and their permissions.

ScannerBundle

Download the scanner bundle.

N/A

ScannerDefinitions

List existing image scanner integrations.

Create, modify, or delete image scanner integrations.

Secret

View metadata about secrets in secured clusters.

N/A

SensorUpgradeConfig

Check the status of automatic upgrades.

Disable or enable automatic upgrades for secured clusters.

ServiceAccount

List Kubernetes service accounts in secured clusters.

N/A

ServiceIdentity

View metadata about Red Hat Advanced Cluster Security for Kubernetes service-to-service authentication.

Revoke or reissue service-to-service authentication credentials.

User

View users that have accessed your Red Hat Advanced Cluster Security for Kubernetes instance, including the metadata that the authentication provider provides about them.

N/A

13.5. Enabling PKI authentication

If you use an enterprise certificate authority (CA) for authentication, you can configure Red Hat Advanced Cluster Security for Kubernetes (RHACS) to authenticate users by using their personal certificates.

After you configure PKI authentication, users and API clients can log in using their personal certificates. Users without certificates can still use other authentication options, including API tokens, the local administrator password, or other authentication providers. PKI authentication is available on the same port number as the Web UI, gRPC, and REST APIs.

When you configure PKI authentication, by default, Red Hat Advanced Cluster Security for Kubernetes uses the same port for PKI, web UI, gRPC, other single sign-on (SSO) providers, and REST APIs. You can also configure a separate port for PKI authentication by using a YAML configuration file to configure and expose endpoints.

13.5.1. Configuring PKI authentication by using the RHACS portal

You can configure PKI authentication by using the RHACS portal.

Procedure

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

13.5.2. Configuring PKI authentication by using the roxctl CLI

You can configure PKI authentication by using the roxctl CLI.

Procedure

  • Run the following command:

    $ roxctl -e <hostname>:<port_number> central userpki create -c <ca_certificate_file> -r <default_role_name> <provider_name>

13.5.3. Updating authentication keys and certificates

You can update your authentication keys and certificates by using the RHACS portal.

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.

13.5.4. Logging in by using a client certificate

After you configure PKI authentication, users see a certificate prompt on the RHACS portal login page. The prompt only shows up if a client certificate trusted by the configured root CA is installed on the user’s system.

Use the procedure described in this section to log in by using a client certificate.

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

Once you use a client certificate to log into the RHACS portal, you cannot log in with a different certificate unless you restart your browser.