1. Documentation
    2. history
×

Getting started with RHACS Cloud Service

Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) provides security services for your Kubernetes clusters on different platforms.

This topic provides instructions to get started using RHACS Cloud Service on Red Hat OpenShift, including OpenShift Container Platform, OpenShift Kubernetes Engine (OKE), Red Hat OpenShift Dedicated (OSD), Azure Red Hat OpenShift (ARO), and Red Hat OpenShift Service on Amazon Web Services (ROSA). See the inline notes for information that differs for RHACS Cloud Service on other Kubernetes platforms.

This installation example shows you how to set up RHACS Cloud Service on OpenShift Container Platform using the Operator. It does not cover installations using Helm charts or the roxctl CLI.

Prerequisites

  • Ensure that you can access the Advanced Cluster Security menu option from the Red Hat Hybrid Cloud Console.

Accessing the ACS Console

  1. In the Red Hat Hybrid Cloud Console, from the navigation menu, select Advanced Cluster Security → ACS Instances, and then select the instance that you want connected to your secured clusters.

    • In the Instance Details section, note the Central API Endpoint. You use this address when creating secured clusters.

  2. Click Open ACS Console. You need your Red Hat Single Sign-On (RH-SSO) credentials, or credentials for another identity provider if that has been configured.

Creating an RHACS Cloud Service project

  • In your OpenShift Container Platform cluster, navigate to Home → Projects and create a project for RHACS Cloud Service. Red Hat suggests using stackrox as the project Name.

Generating an init bundle

  1. In the ACS console, navigate to Platform Configuration → Integrations.

  2. Navigate to the Authentication Tokens section and click on Cluster Init Bundle.

  3. Click Generate bundle.

  4. Enter a name for the cluster init bundle and click Generate.

  5. Click Download Kubernetes Secret File to download the generated bundle.

    Store this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.

Applying an init bundle by creating resources

  1. Using a terminal window, log in to your OpenShift Container Platform cluster, and using the Red Hat OpenShift CLI, run the following command to create the resources:

    $ oc create -f <init_bundle>.yaml \ (1)
  -n <stackrox> (2)
    1 Specify the file name of the init bundle containing the secrets.
    2 Specify the name of the project you created on your OpenShift Container Platform cluster (for example, stackrox).

For non-OpenShift Kubernetes clusters, enter the comparable kubectl commands to create the resources.

Installing secured cluster resources on each cluster

These steps assume that you are installing resources by using the Operator.

For installation on non-OpenShift Kubernetes clusters, you must use Helm charts or the roxctl CLI to install secured cluster resources.

Installing the Operator on the cluster

  1. On your cluster, in the web console, go to the Operators → OperatorHub page.

  2. If Red Hat Advanced Cluster Security for Kubernetes is not displayed, enter Advanced Cluster Security into the Filter by keyword box to find the Red Hat Advanced Cluster Security for Kubernetes Operator.

  3. Select the Red Hat Advanced Cluster Security for Kubernetes Operator to view the details page.

  4. Read the information about the Operator and click Install.

  5. On the Install Operator page:

    • Keep the default value for Installation mode as All namespaces on the cluster.

    • Choose a specific namespace for the Installed namespace field. Red Hat recommends installing the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operator namespace.

    • Select automatic or manual updates for Update approval. Red Hat recommends that you select automatic updates and choose the latest option for the Operator channel.

  6. Click Install.

Verification

  • After the installation completes, navigate to Operators → Installed Operators to verify that the Red Hat Advanced Cluster Security for Kubernetes Operator is listed with the status of Succeeded.

Creating Secured Cluster resources

  1. On your cluster, navigate to Operators → Installed Operators.

  2. Click the Project menu and select the stackrox namespace.

  3. Under Provided APIs, select Secured Cluster.

  4. In the SecuredClusters page, click Create SecuredCluster.

  5. Select Form view.

  6. Enter the new project name by accepting or editing the default name. The default value is stackrox-secured-cluster-services.

  7. Optional: Add any labels for the cluster.

  8. Enter a unique name for your SecuredCluster custom resource.

  9. Enter the Central API Endpoint, including the address and the port number. You can view this information again in the Red Hat Hybrid Cloud Console console by choosing Advanced Cluster Security → ACS Instances, and then clicking the ACS instance you created.

  10. Click Create.

Verifying RHACS Cloud Service installation

To verify installation, access your ACS Console from the Red Hat Hybrid Cloud Console. The Dashboard displays the number of clusters that RHACS Cloud Service is monitoring, along with information about nodes, deployments, images, and violations.

If no data appears in the ACS Console:

  • Ensure that at least one secured cluster is connected to your RHACS Cloud Service instance. For more information, see the "Installing secured cluster resources on each cluster" section.

  • Examine your Sensor pod logs to ensure that the connection to your RHACS Cloud Service instance is successful.

  • In the OCP cluster, navigate to Platform Configuration → Clusters to verify that the components are healthy and view additional operational information.

  • Examine the values in the SecuredCluster API in the Operator on your local cluster to ensure that the Central API Endpoint has been entered correctly. This value should be the same value as shown in the ACS instance details in the Red Hat Hybrid Cloud Console.

Default access to 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.

To learn how authentication providers work in ACS, visit 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 ACSCS 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.

To gain more control over access to your ACS Console, configure another identity provider instead of relying on the Red Hat SSO authentication provider. You can set up your own identity provider after provisioning by using one of the guides under Operating → Managing user access.

To configure this 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 ACSCS 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, by using email as a key.