Chapter 4. Getting started with RHACS Cloud Service Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) provides security services for your Red Hat OpenShift and Kubernetes clusters. See the Red Hat Advanced Cluster Security for Kubernetes Support Matrix for information about supported platforms for secured clusters. Prerequisites Ensure that you can access the Advanced Cluster Security menu option from the Red Hat Hybrid Cloud Console. Note To access the RHACS Cloud Service console, you need your Red Hat Single Sign-On (SSO) credentials, or credentials for another identity provider if that has been configured. See Default access to the ACS console . 4.1. High-level overview of installation steps The following sections provide an overview of installation steps and links to the relevant documentation. 4.1.1. Securing Red Hat OpenShift clusters You can secure Red Hat OpenShift clusters by using the RHACS Operator, Helm charts, or the roxctl CLI. 4.1.1.1. Securing Red Hat OpenShift clusters by using the Operator Procedure Verify that the clusters you want to secure meet the default requirements . In the Red Hat Hybrid Cloud Console, create an ACS Instance . On each Red Hat OpenShift cluster you want to secure, create a project named stackrox . This project will contain the resources for RHACS Cloud Service secured clusters. Create the mechanism that the Central instance, also called Central, uses to set up communication with the secured clusters. You can either create an init bundle or a cluster registration secret (CRS). Perform one of these actions: In the ACS Console, generate an init bundle . The init bundle contains secrets that allow communication between RHACS Cloud Service secured clusters and Central. Log in to Central and use the roxctl CLI to generate an init bundle . Log in to Central and use the roxctl CLI to generate a CRS . On each Red Hat OpenShift cluster, apply the init bundle or CRS . On each Red Hat OpenShift cluster, install the RHACS Operator . On each Red Hat OpenShift cluster, install secured cluster resources in the stackrox project by using the Operator. Verify installation by ensuring that your secured clusters can communicate with the ACS instance. 4.1.1.2. Securing Red Hat OpenShift clusters by using Helm charts Procedure Verify that the clusters you want to secure meet the default requirements . In the Red Hat Hybrid Cloud Console, create an ACS Instance . On each Red Hat OpenShift cluster you want to secure, create a project named stackrox . This project will contain the resources for RHACS Cloud Service secured clusters. Create the mechanism that the Central instance, also called Central, uses to set up communication with the secured clusters. You can either generate an init bundle or a cluster registration secret (CRS). Perform only one of these actions: In the ACS Console, generate an init bundle . The init bundle contains secrets that allow communication between RHACS Cloud Service secured clusters and Central. Log in to Central and use the roxctl CLI to generate an init bundle . Log in to Central and use the roxctl CLI to generate a CRS . On each Red Hat OpenShift cluster, run the helm install command to install RHACS by using Helm charts , specifying the path of the init bundle or CRS. Verify installation by ensuring that your secured clusters can communicate with the ACS instance. 4.1.1.3. Securing Red Hat OpenShift clusters by using the roxctl CLI, also called the manifest method Procedure Verify that the clusters you want to secure meet the default requirements . In the Red Hat Hybrid Cloud Console, create an ACS Instance . On each Red Hat OpenShift cluster you want to secure, create a project named stackrox . This project will contain the resources for RHACS Cloud Service secured clusters. Perform one of the following actions: In the ACS console, use the legacy installation method to create a cluster bundle. From a system that has access to the monitored cluster, generate the configuration and extract and run the sensor script from the cluster bundle . Verify installation by ensuring that your secured clusters can communicate with the ACS instance. 4.1.2. Securing Kubernetes clusters You can secure Kubernetes clusters by using Helm charts or the roxctl CLI. 4.1.2.1. Securing Kubernetes clusters by using Helm charts Verify that the clusters you want to secure meet the default requirements . In the Red Hat Hybrid Cloud Console, create an ACS Instance . Create the mechanism that the Central instance, also called Central, uses to set up communication with the secured clusters. You can either create an init bundle or a cluster registration secret (CRS). Perform only one of these actions: In the ACS Console, generate an init bundle . The init bundle contains secrets that allow communication between RHACS Cloud Service secured clusters and Central. Log in to Central and use the roxctl CLI to generate an init bundle . Log in to Central and use the roxctl CLI to generate a CRS . On each Kubernetes cluster, run the helm install command to install by using Helm charts , specifying the path of the init bundle or CRS. Verify installation by ensuring that your secured clusters can communicate with the ACS instance. 4.1.2.2. Securing Kubernetes clusters by using the roxctl CLI, also called the manifest method Verify that the clusters you want to secure meet the default requirements . In the Red Hat Hybrid Cloud Console, create an ACS Instance . On each cluster you want to secure, create a namespace named stackrox . This namespace will contain the resources for RHACS Cloud Service secured clusters. Perform one of the following steps: In the ACS console, use the legacy installation method to create a cluster bundle. From a system that has access to the monitored cluster, generate the configuration and extract and run the sensor script from the cluster bundle . Verify installation by ensuring that your secured clusters can communicate with the ACS instance. 4.2. Default access to the ACS Console By default, the authentication mechanism available to users is authentication by using Red Hat Single Sign-On (SSO). You cannot delete or change the Red Hat SSO authentication provider. However, you can change the minimum access role and add additional rules, or add another identity provider. Note To learn how authentication providers work in ACS, see Understanding authentication providers . A dedicated OIDC client of sso.redhat.com is created for each ACS Console. All OIDC clients share the same sso.redhat.com realm. Claims from the token issued by sso.redhat.com are mapped to an ACS-issued token as follows: realm_access.roles to groups org_id to rh_org_id is_org_admin to rh_is_org_admin sub to userid The built-in Red Hat SSO authentication provider has the required attribute rh_org_id set to the organization ID assigned to account of the user who created the RHACS Cloud Service instance. This is the ID of the organizational account the user is a part of. This can be thought of as the "tenant" the user is under and owned by. Only users with the same organizational account can access the ACS console by using the Red Hat SSO authentication provider. Note To gain more control over access to your ACS Console, configure another identity provider instead of relying on the Red Hat SSO authentication provider. For more information, see Understanding authentication providers . To configure the other authentication provider to be the first authentication option on the login page, its name should be lexicographically smaller than Red Hat SSO . The minimum access role is set to None . Assigning a different value to this field gives access to the RHACS Cloud Service instance to all users with the same organizational account. Other rules that are set up in the built-in Red Hat SSO authentication provider include the following: Rule mapping your userid to Admin Rules mapping administrators of the organization to Admin You can add more rules to grant access to the ACS Console to someone else with the same organizational account. For example, you can use email as a key.

Commands: