Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 7. Setting up RHACS Cloud Service with Red Hat OpenShift secured clusters

Access Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) by selecting an instance in the Red Hat Hybrid Cloud Console. An ACS instance contains the RHACS Cloud Service management interface and services that Red Hat configures and manages for you. The management interface connects to your secured clusters, which contain the services that scan and collect information about vulnerabilities. One instance can connect to and monitor many clusters.

7.1.1. Creating an instance in the console
Copy link

In the Red Hat Hybrid Cloud Console, create an ACS instance to connect to your secured clusters.

Procedure

To create an ACS instance:

  1. Log in to the Red Hat Hybrid Cloud Console.
  2. From the navigation menu, select Advanced Cluster Security ACS Instances.

  3. Select Create ACS instance and enter information into the displayed fields or select the appropriate option from the drop-down list:

    • Name: Enter the name of your ACS instance. An ACS instance contains the RHACS Central component, also referred to as "Central", which includes the RHACS Cloud Service management interface and services that are configured and managed by Red Hat. You manage your secured clusters that communicate with Central. You can connect many secured clusters to one instance.
    • Cloud provider: The cloud provider where Central is located. Select AWS.

    • Cloud region: The region for your cloud provider where Central is located. Select one of the following regions:

      • US-East, N. Virginia
      • Europe, Ireland
    • Availability zones: Use the default value (Multi).
  4. Click Create instance.

7.1.2. Next steps
Copy link

  • 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 a project on each Red Hat OpenShift cluster that you want to secure. You then use this project to install RHACS Cloud Service resources by using the Operator or Helm charts.

7.2.1. Creating a project on your cluster
Copy link

Procedure

  • In your OpenShift Container Platform cluster, go to Home Projects and create a project for RHACS Cloud Service. Use stackrox as the project Name.

7.2.2. Next steps
Copy link

In the ACS Console, xref:init-bundle-cloud-ocp-generate[generate a cluster registration secret or an init bundle]. These files contain the secrets that are used to set up the initial secured communication between {product-title-managed-short} secured clusters and Central.

Before you set up a secured cluster, you must generate a cluster registration secret (CRS) or an init bundle that contains secrets for initial authentication with the Central instance, also called Central. Generate a CRS or an init bundle by using either the RHACS portal or the roxctl CLI, and then apply the CRS or the init bundle to the secured cluster.

Note

You must have the Admin user role to generate a CRS or an init bundle. Init bundles are still supported, but using a CRS is the preferred way to set up a secured cluster.

Before you set up a secured cluster, you must generate a CRS or an init bundle. The secured cluster then uses the contained secrets for initial authentication with Central. Central is the specific service that provides the ACS Console, handles all API interactions, and manages data storage and image scanning. Use either the RHACS portal or the roxctl CLI to generate a CRS or an init bundle.

You can then apply the CRS or the init bundle by using the OpenShift Container Platform web console or by using the oc or kubectl CLI. If you install RHACS by using Helm, you provide the CRS or the init bundle when you run the helm install command.

7.3.1. Generating a CRS or an init bundle
Copy link

You can generate a cluster registration secret (CRS) or an init bundle containing secrets by using the RHACS portal, also called the ACS Console.

Note

You must have the Admin user role to generate a CRS or an init bundle.

Procedure

  1. Log in to the RHACS portal. If you do not have secured clusters, or an existing CRS or an init bundle, the Platform Configuration Clusters page appears.

  2. Click Create cluster registration secret or Init bundles installation method.

    Note

    Init bundles are still supported, but using a CRS to secure clusters is the preferred method.

    Complete only one of the following actions:

    • If you chose to generate a CRS, enter a name for the CRS and click Download to generate and download it. The CRS is created in the form of a YAML file and you can use it to secure all of your clusters if you are using the same installation method.

      Important

      Store this file securely because it contains secrets.

    • If you chose to generate an init bundle, complete these steps:

      1. Enter a name for the cluster init bundle.
      2. Select your platform.
      3. Select the installation method you will use for your secured clusters: Operator or Helm chart.

      4. Click Download to generate and download the init bundle, which is created in the form of a YAML file. You can use one init bundle and its corresponding YAML file for all secured clusters if you are using the same installation method.

        Important

        Store this file securely because it contains secrets.

Next steps

  1. Apply the CRS or the init bundle to the secured cluster.
  2. Install secured cluster services on each cluster.

7.3.1.2. Generating a CRS by using the roxctl CLI
Copy link

You can generate a cluster registration secret by using the roxctl CLI.

Note

You must have the Admin user role to generate a CRS.

Prerequisites

  • You have configured the ROX_API_TOKEN and the ROX_CENTRAL_ADDRESS environment variables:

    1. Set the ROX_API_TOKEN by running the following command: 

      $ export ROX_API_TOKEN=<api_token>

    2. Set the ROX_CENTRAL_ADDRESS environment variable by running the following command: 

      $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

In RHACS Cloud Service, when using roxctl commands that require the Central address, use the Central instance address as displayed in the Instance Details section of the Red Hat Hybrid Cloud Console. For example, use acs-ABCD12345.acs.rhcloud.com instead of acs-data-ABCD12345.acs.rhcloud.com.

Procedure

  • To generate a CRS, run the following command: 

    $ roxctl -e "$ROX_CENTRAL_ADDRESS" \
  central crs generate <crs_name> \
  --output <file_name>

    where:

    <crs_name>
    Specifies an identifier or name for the CRS.
    <file_name>
    Specifies a file name. Use - for standard output.

Ensure that you store this file securely because it contains secrets. You can use the same file to set up more than one secured cluster. You cannot retrieve a previously-generated CRS.

Depending on the output that you select, the command might return some INFO messages about the CRS and the YAML file.

Sample output

INFO:	Successfully generated new CRS
INFO:
INFO:	  Name:       test-crs
INFO:	  Created at: 2025-02-26T19:07:21Z
INFO:	  Expires at: 2026-02-26T19:07:00Z
INFO:	  Created By: sample-token
INFO:	  ID:         9214a63f-7e0e-485a-baae-0757b0860ac9
# This is a StackRox Cluster Registration Secret (CRS).
# It is used for setting up StackRox secured clusters.
# NOTE: This file contains secret data that allows connecting new secured clusters to central,
# and needs to be handled and stored accordingly.
apiVersion: v1
data:
  crs: EXAMPLEZXlKMlpYSnphVzl1SWpveExDSkRRWE1pT2xzaUxTMHRMUzFDUlVkSlRpQkRSVkpVU1VaSlEwREXAMPLE=
kind: Secret
metadata:
  annotations:
    crs.platform.stackrox.io/created-at: "2025-02-26T19:07:21.800414339Z"
    crs.platform.stackrox.io/expires-at: "2026-02-26T19:07:00Z"
    crs.platform.stackrox.io/id: 9214a63f-7e0e-485a-baae-0757b0860ac9
    crs.platform.stackrox.io/name: test-crs
  creationTimestamp: null
  name: cluster-registration-secret
INFO:	Then CRS needs to be stored securely, since it contains secrets.
INFO:	It is not possible to retrieve previously generated CRSs.

You can generate an init bundle with secrets by using the roxctl CLI.

Note

You must have the Admin user role to create init bundles.

Prerequisites

  • You have configured the ROX_API_TOKEN and the ROX_CENTRAL_ADDRESS environment variables:

    1. Set the ROX_API_TOKEN by running the following command: 

      $ export ROX_API_TOKEN=<api_token>

    2. Set the ROX_CENTRAL_ADDRESS environment variable by running the following command: 

      $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

In RHACS Cloud Service, when using roxctl commands that require the Central address, use the Central instance address as displayed in the Instance Details section of the Red Hat Hybrid Cloud Console. For example, use acs-ABCD12345.acs.rhcloud.com instead of acs-data-ABCD12345.acs.rhcloud.com.

Procedure

  • To generate a cluster init bundle containing secrets for Helm installations, run the following command: 

    $ roxctl -e "$ROX_CENTRAL_ADDRESS" \
  central init-bundles generate <cluster_init_bundle_name> --output \
  cluster_init_bundle.yaml

  • To generate a cluster init bundle containing secrets for Operator installations, run the following command: 

    $ roxctl -e "$ROX_CENTRAL_ADDRESS" \
  central init-bundles generate <cluster_init_bundle_name> --output-secrets \
  cluster_init_bundle.yaml
    Important

    Ensure that you store this bundle securely because it contains secrets. You can use the same bundle to set up more than one secured cluster.

7.3.2. Next steps
Copy link

Apply the cluster registration secret (CRS) or the init bundle to the secured cluster.

Note

You must have the Admin user role to apply a CRS or an init bundle.

Before you configure a secured cluster, you must apply the CRS to the secured cluster. After you have applied the CRS, the services on the secured cluster can communicate securely with RHACS Cloud Service.

Note

If you are installing by using Helm charts, do not perform this step. Complete the installation by using Helm; See "Installing RHACS on secured clusters by using Helm charts" in the additional resources section.

Prerequisites

  • You must have generated a CRS.

Procedure

To create resources, perform only one of the following steps:

  • Create resources using the OpenShift Container Platform web console:

    1. In the OpenShift Container Platform web console, go to the stackrox project or the project where you want to install the secured cluster services.
    2. In the top menu, click + to open the Import YAML page.
    3. You can drag the CRS file or copy and paste its contents into the editor, and then click Create. When the command is complete, the display shows that the secret named cluster-registration-secret was created.

  • Create resources using the Red Hat OpenShift CLI: Using the Red Hat OpenShift CLI, run the following command to create the resources: 

    $ oc create -f <file_name.yaml> \
  -n <stackrox>

    where:

    <file_name.yaml>
    Specifies the file name of the CRS.
    <stackrox>
    Specifies the name of the project where secured cluster services are installed.

Verification

  • Restart Sensor to pick up the new certificates.

    For more information about how to restart Sensor, see "Restarting the Sensor container" in the "Additional resources" section.

Before you configure a secured cluster, you must apply the init bundle to the secured cluster. Applying the init bundle allows the services on the secured cluster to communicate with RHACS Cloud Service.

Note

If you are installing by using Helm charts, do not perform this step. Complete the installation by using Helm; See "Installing RHACS on secured clusters by using Helm charts" in the additional resources section.

Prerequisites

  • You must have generated an init bundle containing secrets. The preferred way to set up a secured cluster is by using a CRS.
  • You must have created the stackrox project, or namespace, on the cluster where secured cluster services will be installed. Using stackrox for the project is not required, but ensures that vulnerabilities for RHACS processes are not reported when scanning your clusters.

Procedure

To create resources, perform only one of the following steps:

  • Create resources using the OpenShift Container Platform web console:

    1. In the OpenShift Container Platform web console, make sure that you are in the stackrox namespace.
    2. In the top menu, click + to open the Import YAML page.
    3. You can drag the init bundle file or copy and paste its contents into the editor, and then click Create. When the command is complete, the display shows that the collector-tls, sensor-tls, and admission-control-tls resources were created.

  • Create resources using the Red Hat OpenShift CLI: Using the Red Hat OpenShift CLI, run the following command to create the resources: 

    $ oc create -f <init_bundle.yaml> \
  -n <stackrox>

    where:

    <init_bundle.yaml>
    Specifies the file name of the init bundle containing the secrets.
    <stackrox>
    Specifies the name of the project where Central services are installed.

Verification

  • Restart Sensor to pick up the new certificates.

    For more information about how to restart Sensor, see "Restarting the Sensor container" in the "Additional resources" section.

7.4.3. Next steps
Copy link

  • On each Red Hat OpenShift cluster, install the RHACS Operator.
  • Install RHACS secured cluster services in all clusters that you want to monitor.

7.5. Installing the Operator
Copy link

Install the RHACS Operator on your secured clusters.

Using the Software Catalog provided with OpenShift Container Platform is the easiest way to install the RHACS Operator.

Prerequisites

Procedure

  1. In the web console, go to the Ecosystem Software Catalog 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. You might have to select a project first.
  3. Select the Red Hat Advanced Cluster Security for Kubernetes Operator to view the details page.
  4. Read the information about the Operator, and then click Install.

  5. On the Install Operator page:

    • Keep the default value for Installation mode as All namespaces on the cluster.
    • Select a specific namespace in which to install the Operator for the Installed namespace field. Install the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operator namespace.

    • Select automatic or manual updates for Update approval.

      If you select automatic updates, when a new version of the Operator is available, Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator.

      If you select manual updates, when a newer version of the Operator is available, OLM creates an update request. As a cluster administrator, you must manually approve the update request to update the Operator to the latest version.

      Red Hat recommends enabling automatic upgrades for Operator in RHACS Cloud Service. See the Red Hat Advanced Cluster Security for Kubernetes Support Matrix for more information.

  6. Click Install.

Verification

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

To deploy the Red Hat Advanced Cluster Security for Kubernetes (RHACS) Operator on infrastructure nodes, you can modify its subscription YAML to include nodeSelector and tolerations to ensure that its pods are scheduled correctly.

Procedure

  1. Configure the RHACS Operator with the necessary nodeSelector and tolerations for infrastructure nodes before you apply the Operator Lifecycle Manager (OLM) subscription by using the following content, for example: 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  labels:
    operators.coreos.com/rhacs-operator.rhacs-operator: ""
  name: rhacs-operator
  namespace: rhacs-operator
spec:
  channel: stable
  config:
    nodeSelector:
      node-role.kubernetes.io/infra: "" #
    tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra #
        operator: Exists
  installPlanApproval: Automatic
  name: rhacs-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace

    where:

    spec.config.nodeSelector.node-role.kubernetes.io/infra
    Specifies the nodeSelector key and value to instruct the Kubernetes scheduler to place the Operator pods on nodes that have the label node-role.kubernetes.io/infra: "".
    spec.config.tolerations.key
    Specifies the tolerations entry, which allows the Operator pods to be scheduled on nodes that have a taint with the node-role.kubernetes.io/infra key. This is necessary as infrastructure nodes are usually provided with a taint to prevent non-infrastructure workloads from being scheduled on them.
  2. Save the YAML file and apply it by using the OpenShift CLI (oc).

When you apply the YAML file, you update the subscription for the RHACS Operator. This in turn configures where the RHACS Operator pods can be scheduled. The rhacs-operator namespace is the designated location for the RHACS Operator.

7.5.2. Next steps
Copy link

You can install RHACS Cloud Service on your secured clusters by using the Operator or Helm charts. You can also use the roxctl CLI to install it, but do not use this method unless you have a specific installation need that requires using it.

Prerequisites

  • During RHACS installation, you noted the Central instance address. You can view this information by choosing Advanced Cluster Security ACS Instances from the cloud console navigation menu, and then clicking the ACS instance you created.
  • If you are installing by using the Operator, you created your Red Hat OpenShift cluster that you want to secure and installed the Operator on it.
  • You generated and downloaded the cluster registration secret (CRS) or the init bundle by using the ACS Console or by using the roxctl CLI.
  • You applied the CRS or the init bundle on the cluster that you want to secure, unless you are installing by using a Helm chart.

To install RHACS by using the Operator, you first install the Operator and then use it to install RHACS on the secured cluster.

RHACS uses annotations attached to the custom resource (CR) so that for installations performed by using the Operator, the default values for certain configuration items are decided at runtime by the Operator based on the current environment, allowing the previously configured value of an item to persist.

For some configuration items, using a static default value for the installation is not ideal. Beginning with RHACS version 4.8, the Operator can add annotations that are attached to the CR that you apply to clusters. These annotations allow a default decision that the Operator previously made to persist and be reapplied in the future, even if the default behavior for a fresh installation has changed. In summary, RHACS uses annotations to persist runtime defaults. This means that the default value for a certain configuration setting is decided by the Operator at runtime.

For example, in release 4.8 and later, if a value is not specified for enabling Scanner V4, the default behavior is to enable Scanner V4. However, if a value is configured in the CR, such as disable, then RHACS uses that value. In the Scanner V4 example, Scanner V4 was disabled by default in version 4.7; when updating to version 4.8 by using the Operator, that disabled setting persists and Scanner V4 is disabled.

Annotations are in the form feature-defaults.platform.stackrox.io/<identifier>. For example, feature-defaults.platform.stackrox.io/scannerV4 is the annotation that allows the Operator to keep the default Scanner V4 enablement toggle stable during updating to RHACS version 4.8.

Important

Do not change or delete these annotations.

7.6.1.2. Installing secured cluster services
Copy link

You can install Secured Cluster services on your clusters by using the Operator, which creates the SecuredCluster custom resource. You must install the Secured Cluster services on every cluster in your environment that you want to monitor.

Important

When you install Red Hat Advanced Cluster Security for Kubernetes:

  • If you are installing RHACS for the first time, you must first install the Central custom resource because the SecuredCluster custom resource installation is dependent on certificates that Central generates.
  • Do not install SecuredCluster in projects whose names start with kube, openshift, or redhat, or in the istio-system project.
  • If you are installing RHACS SecuredCluster custom resource on a cluster that also hosts Central, ensure that you install it in the same namespace as Central.
  • If you are installing Red Hat Advanced Cluster Security for Kubernetes SecuredCluster custom resource on a cluster that does not host Central, Red Hat recommends that you install the Red Hat Advanced Cluster Security for Kubernetes SecuredCluster custom resource in its own project and not in the project in which you have installed the Red Hat Advanced Cluster Security for Kubernetes Operator.

Prerequisites

  • If you are using OpenShift Container Platform, you must install version 4.12 or later.
  • You have installed the RHACS Operator on the cluster that you want to secure, called the secured cluster.
  • You have generated a cluster registration secret (CRS) or an init bundle and applied it to the cluster in the recommended stackrox namespace.

Procedure

  1. On the OpenShift Container Platform web console for the secured cluster, go to the Ecosystem Installed Operators page.
  2. Click the RHACS Operator.

  3. If you have installed the Operator in the recommended namespace, OpenShift Container Platform lists the project as rhacs-operator.

    Note
    • If you installed the Operator in a different namespace, OpenShift Container Platform lists the name of that namespace instead of rhacs-operator.
  4. Click Installed Operators.
  5. You should have created the stackrox namespace when you applied the CRS or the init bundle. Make sure that you are in this namespace by verifying that Project:stackrox is selected in the menu.
  6. In Provided APIs, click Secured Cluster.
  7. Click Create SecuredCluster.

  8. Select one of the following options in the Configure via field:

    • Form view: Use this option if you want to use the on-screen fields to configure the secured cluster and do not need to change any other fields.
    • YAML view: Use this view to set up the secured cluster by using the YAML file. The YAML file is displayed in the window and you can edit fields in it. If you select this option, when you are finished editing the file, click Create.
  9. If you are using Form view, enter the new project name by accepting or editing the default name. The default value is stackrox-secured-cluster-services.
  10. Optional: Add any labels for the cluster.
  11. Enter a unique name for your SecuredCluster custom resource.

  12. For Central Endpoint, enter the address of your Central instance. For example, if Central is available at https://central.example.com, then specify the central endpoint as central.example.com.

    • For RHACS Cloud Service use the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the RHACS instance you created.
    • Use the default value of central.stackrox.svc:443 only if you are installing secured cluster services in the same cluster where Central is installed.
    • Do not use the default value when you are configuring multiple clusters. Instead, use the hostname when configuring the Central Endpoint value for each cluster.
  13. For the remaining fields, accept the default values or configure custom values if needed. For example, you might need to configure TLS if you are using custom certificates or untrusted CAs. See "Configuring Secured Cluster services options for RHACS using the Operator" for more information.

  14. To use file active monitoring, you must enable the SFA agent:

    1. Expand SFA.
    2. From the SFA Agent list, select Enabled.
  15. Click Create.

  16. After a brief pause, the SecuredClusters page displays the status of stackrox-secured-cluster-services. You might see the following conditions:

    • Conditions: Deployed, Initialized: The secured cluster services have been installed and the secured cluster is communicating with Central.
    • Conditions: Initialized, Irreconcilable: The secured cluster is not communicating with Central. Make sure that you applied the CRS or the init bundle you created in the RHACS web portal to the secured cluster.

Next steps

  1. Configure additional secured cluster settings (optional).
  2. Verify installation.

You can install RHACS on secured clusters by using Helm charts with no customization, using the default values, or with customizations of configuration parameters.

First, ensure that you add the Helm chart repository.

7.6.2.1. Adding the Helm chart repository
Copy link

Procedure

  • Add the RHACS charts repository. 

    $ helm repo add rhacs https://mirror.openshift.com/pub/rhacs/charts/

    The Helm repository for Red Hat Advanced Cluster Security for Kubernetes includes Helm charts for installing different components, including:

  • Central services Helm chart (central-services) for installing the centralized components (Central and Scanner).

    Note

    You deploy centralized components only once and you can monitor multiple separate clusters by using the same installation.

  • Secured Cluster Services Helm chart (secured-cluster-services) for installing the per-cluster and per-node components (Sensor, Admission Controller, Collector, and Scanner-slim).

    Note

    Deploy the per-cluster components into each cluster that you want to monitor and deploy the per-node components in all nodes that you want to monitor.

Verification

  • Run the following command to verify the added chart repository: 

    $ helm search repo -l rhacs/

Use the following instructions to install the secured-cluster-services Helm chart to deploy the per-cluster and per-node components (Sensor, Admission controller, Collector, and Scanner-slim).

Prerequisites

  • You must have generated a RHACS cluster registration secret (CRS) or an init bundle for your cluster.
  • You must have access to the Red Hat Container Registry and a pull secret for authentication. For information about downloading images from registry.redhat.io, see Red Hat Container Registry Authentication.
  • You must have the Central API Endpoint address. You can view this information by selecting Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the ACS instance you created.

Procedure

  • Run the following command on your Kubernetes-based clusters:

    • If you are using a CRS, run the following command: 

      $ helm install -n stackrox --create-namespace \
    stackrox-secured-cluster-services rhacs/secured-cluster-services \
    --set-file crs.file=<crs_file_name.yaml> \
    -f <path_to_pull_secret.yaml> \
    --set clusterName=<name_of_the_secured_cluster> \
    --set centralEndpoint=<endpoint_of_central_service>

      where:

      <crs_file_name.yaml>
      Specifies the name of the file in which the generated CRS has been stored.
      <path_to_pull_secret.yaml>
      Specifies the path for the pull secret for Red Hat Container Registry authentication. Or, you can specify --set imagePullSecrets.username=<your redhat.com username> and --set imagePullSecrets.password=<your redhat.com password> in the command.
      <endpoint_of_central_service>
      Specifies the address and port number for Central. For example, acs.domain.com:443.
      <your redhat.com username>
      Specifies the user name for your pull secret for Red Hat Container Registry authentication.
      <your redhat.com password>
      Specifies the password for your pull secret for Red Hat Container Registry authentication.

    • If you are using an init bundle, run the following command: 

      $ helm install -n stackrox --create-namespace \
    stackrox-secured-cluster-services rhacs/secured-cluster-services \
    -f <path_to_cluster_init_bundle.yaml> \
    -f <path_to_pull_secret.yaml> \
    --set clusterName=<name_of_the_secured_cluster> \
    --set centralEndpoint=<endpoint_of_central_service>

      where:

      <path_to_cluster_init_bundle.yaml>
      Specifies the path for the init bundle.
      <path_to_pull_secret.yaml>
      Specifies the path for the pull secret for Red Hat Container Registry authentication. Or, you can specify --set imagePullSecrets.username=<your redhat.com username> and --set imagePullSecrets.password=<your redhat.com password> in the command.
      <endpoint_of_central_service>
      Specifies the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, and then clicking the RHACS instance you created.
      <your redhat.com username>
      Specifies the user name for your pull secret for Red Hat Container Registry authentication.
      <your redhat.com password>
      Specifies the password for your pull secret for Red Hat Container Registry authentication.

  • Run one of the following commands on an OpenShift Container Platform cluster:

    • If you are using a CRS, run the following command: 

      $ helm install -n stackrox --create-namespace \
    stackrox-secured-cluster-services rhacs/secured-cluster-services \
    --set-file crs.file=<crs_file_name.yaml> \
    -f <path_to_pull_secret.yaml> \
    --set clusterName=<name_of_the_secured_cluster> \
    --set centralEndpoint=<endpoint_of_central_service> \
    --set scanner.disable=false

      where:

      <crs_file_name.yaml>
      Specifies the name of the file in which the generated CRS has been stored.
      <path_to_pull_secret.yaml>
      Specifies the path for the pull secret for Red Hat Container Registry authentication.
      <endpoint_of_central_service>
      Specifies the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the RHACS instance you created.
      --set scanner.disable=false
      Sets the value of the scanner.disable parameter to false, which means that Scanner-slim will be enabled during the installation. In Kubernetes, the secured cluster services now include Scanner-slim.

    • If you are using an init bundle, run the following command: 

      $ helm install -n stackrox --create-namespace \
    stackrox-secured-cluster-services rhacs/secured-cluster-services \
    -f <path_to_cluster_init_bundle.yaml> \
    -f <path_to_pull_secret.yaml> \
    --set clusterName=<name_of_the_secured_cluster> \
    --set centralEndpoint=<endpoint_of_central_service> \
    --set scanner.disable=false

      where:

      <path_to_cluster_init_bundle.yaml>
      Specifies the path for the init bundle.
      <path_to_pull_secret.yaml>
      Specifies the path for the pull secret for Red Hat Container Registry authentication.
      <endpoint_of_central_service>
      Specifies the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the RHACS instance you created.
      --set scanner.disable=false
      Sets the value of the scanner.disable parameter to false, which means that Scanner-slim will be enabled during the installation. In Kubernetes, the secured cluster services now include Scanner-slim.

You can use Helm chart configuration parameters with the helm install and helm upgrade commands. Specify these parameters by using the --set option or by creating YAML configuration files.

Create the following files for configuring the Helm chart for installing Red Hat Advanced Cluster Security for Kubernetes:

  • Public configuration file values-public.yaml: Use this file to save all non-sensitive configuration options.
  • Private configuration file values-private.yaml: Use this file to save all sensitive configuration options. Ensure that you store this file securely.
Important

When using the secured-cluster-services Helm chart, do not change the values.yaml file that is part of the chart.

7.6.2.3.1. Configuration parameters
Copy link
Expand
ParameterDescription

clusterName

Name of your cluster.

centralEndpoint

Address of the Central endpoint. If you are using a non-gRPC capable load balancer, use the WebSocket protocol by prefixing the endpoint address with wss://. When configuring multiple clusters, use the hostname for the address. For example, central.example.com.

env.grpcEnforceALPN

Use true to force application-level protocol negotiation (ALPN) during the TLS handshake.

sensor.endpoint

Address of the Sensor endpoint including port number.

sensor.imagePullPolicy

Image pull policy for the Sensor container.

sensor.serviceTLS.cert

The internal service-to-service TLS certificate that Sensor uses.

sensor.serviceTLS.key

The internal service-to-service TLS certificate key that Sensor uses.

sensor.resources.requests.memory

The memory request for the Sensor container. Use this parameter to override the default value.

sensor.resources.requests.cpu

The CPU request for the Sensor container. Use this parameter to override the default value.

sensor.resources.limits.memory

The memory limit for the Sensor container. Use this parameter to override the default value.

sensor.resources.limits.cpu

The CPU limit for the Sensor container. Use this parameter to override the default value.

sensor.nodeSelector

Specify a node selector label as label-key: label-value to force Sensor to only schedule on nodes with the specified label.

sensor.tolerations

If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Sensor. This parameter is mainly used for infrastructure nodes.

image.main.name

The name of the main image.

image.collector.name

The name of the Collector image.

image.main.registry

The address of the registry you are using for the main image.

image.collector.registry

The address of the registry you are using for the Collector image.

image.scanner.registry

The address of the registry you are using for the Scanner image.

image.scannerDb.registry

The address of the registry you are using for the Scanner DB image.

image.scannerV4.registry

The address of the registry you are using for the Scanner V4 image.

image.scannerV4DB.registry

The address of the registry you are using for the Scanner V4 DB image.

image.main.pullPolicy

Image pull policy for main images.

image.collector.pullPolicy

Image pull policy for the Collector images.

image.main.tag

Tag of main image to use.

image.collector.tag

Tag of collector image to use.

collector.collectionMethod

Either CORE_BPF or NO_COLLECTION.

collector.imagePullPolicy

Image pull policy for the Collector container.

collector.complianceImagePullPolicy

Image pull policy for the Compliance container.

collector.disableTaintTolerations

If you specify false, tolerations are applied to Collector, and the collector pods can schedule onto all nodes with taints. If you specify it as true, no tolerations are applied, and the collector pods are not scheduled onto nodes with taints.

collector.resources.requests.memory

The memory request for the Collector container. Use this parameter to override the default value.

collector.resources.requests.cpu

The CPU request for the Collector container. Use this parameter to override the default value.

collector.resources.limits.memory

The memory limit for the Collector container. Use this parameter to override the default value.

collector.resources.limits.cpu

The CPU limit for the Collector container. Use this parameter to override the default value.

collector.complianceResources.requests.memory

The memory request for the Compliance container. Use this parameter to override the default value.

collector.complianceResources.requests.cpu

The CPU request for the Compliance container. Use this parameter to override the default value.

collector.complianceResources.limits.memory

The memory limit for the Compliance container. Use this parameter to override the default value.

collector.complianceResources.limits.cpu

The CPU limit for the Compliance container. Use this parameter to override the default value.

collector.serviceTLS.cert

The internal service-to-service TLS certificate that Collector uses.

collector.serviceTLS.key

The internal service-to-service TLS certificate key that Collector uses.

admissionControl.enforce

This parameter determines if the admission controller has been configured to enforce policies that have enforcement enabled. For a new secured cluster deployed with RHACS 4.9, the default value is true. For secured clusters updating from RHACS versions before 4.9, previous values for the admission controller configuration parameters determine the value of this parameter. Before the update, if either of the admissionControl.enforceOnCreates or admissionControl.enforceOnUpdates parameters was set to true, the value of this parameter defaults to true after upgrade. If both of these parameters were set to false, the default value becomes false on update.

admissionControl.failurePolicy

Determines whether API server request is allowed (fail open) or blocked (fail closed) if an error or timeout happens in the RHACS validating webhook’s evaluation. Valid values are Ignore and Fail. The default value is Ignore to fail open.

admissionControl.listenOnCreates

This parameter is deprecated and RHACS ignores its value.

admissionControl.listenOnUpdates

This parameter is deprecated and RHACS ignores its value.

admissionControl.listenOnEvents

This parameter is deprecated and RHACS ignores its value.

admissionControl.dynamic.enforceOnCreates

This parameter is deprecated. RHACS checks its value during updates to version 4.9 and uses it to set a default value for the new admissionControl.enforce parameter. On new installations, changing this parameter has no effect.

admissionControl.dynamic.enforceOnUpdates

This parameter is deprecated. RHACS checks its value during updates to version 4.9 and uses it to set a default value for the new admissionControl.enforce parameter. On new installations, changing this parameter has no effect.

admissionControl.dynamic.scanInline

This parameter is deprecated and RHACS ignores its value.

admissionControl.dynamic.disableBypass

Set this parameter to true to disable bypassing the admission controller. The default value is false.

admissionControl.dynamic.timeout

The ability to configure this parameter is deprecated. RHACS uses a preset value for the timeout period and you cannot change it. This parameter is ignored.

admissionControl.resources.requests.memory

The memory request for the Admission Control container. Use this parameter to override the default value.

admissionControl.resources.requests.cpu

The CPU request for the Admission Control container. Use this parameter to override the default value.

admissionControl.resources.limits.memory

The memory limit for the Admission Control container. Use this parameter to override the default value.

admissionControl.resources.limits.cpu

The CPU limit for the Admission Control container. Use this parameter to override the default value.

admissionControl.nodeSelector

Specify a node selector label as label-key: label-value to force Admission Control to only schedule on nodes with the specified label.

admissionControl.tolerations

If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Admission Control. This parameter is mainly used for infrastructure nodes.

admissionControl.namespaceSelector

If the admission controller webhook needs a specific namespaceSelector, you can specify the corresponding selector here. Use this parameter to override the default, which avoids a few system namespaces.

admissionControl.serviceTLS.cert

The internal service-to-service TLS certificate that Admission Control uses.

admissionControl.serviceTLS.key

The internal service-to-service TLS certificate key that Admission Control uses.

registryOverride

Use this parameter to override the default docker.io registry. Specify the name of your registry if you are using some other registry.

collector.disableTaintTolerations

If you specify false, tolerations are applied to Collector, and the Collector pods can schedule onto all nodes with taints. If you specify it as true, no tolerations are applied, and the Collector pods are not scheduled onto nodes with taints.

createUpgraderServiceAccount

Specify true to create the sensor-upgrader account. By default, Red Hat Advanced Cluster Security for Kubernetes creates a service account called sensor-upgrader in each secured cluster. This account is highly privileged but is only used during upgrades. If you do not create this account, you must complete future upgrades manually if the Sensor does not have enough permissions.

createSecrets

Specify false to skip the orchestrator secret creation for the Sensor, Collector, and Admission controller.

collector.slimMode

Deprecated. Specify true if you want to use a slim Collector image for deploying Collector.

sensor.resources

Resource specification for Sensor.

admissionControl.resources

Resource specification for Admission controller.

collector.resources

Resource specification for Collector.

collector.complianceResources

Resource specification for Collector’s Compliance container.

perNode.sfa.agent

If you set this option to Enabled, you can enable file activity monitoring in your secured cluster.

exposeMonitoring

If you set this option to true, Red Hat Advanced Cluster Security for Kubernetes exposes Prometheus metrics endpoints on port number 9090 for the Sensor, Collector, and the Admission controller.

auditLogs.disableCollection

If you set this option to true, Red Hat Advanced Cluster Security for Kubernetes disables the audit log detection features used to detect access and modifications to configuration maps and secrets.

autoLockProcessBaselines.enabled

If you set this option to true, Red Hat Advanced Cluster Security for Kubernetes enables automatically locking process baselines. The default is false.

scanner.disable

If you set this option to false, Red Hat Advanced Cluster Security for Kubernetes deploys a Scanner-slim and Scanner DB in the secured cluster to allow scanning images on the integrated OpenShift image registry. Enabling Scanner-slim is supported on OpenShift Container Platform and Kubernetes secured clusters. Defaults to true.

scanner.dbTolerations

If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB.

scanner.replicas

Resource specification for Collector’s Compliance container.

scanner.logLevel

Setting this parameter allows you to modify the scanner log level. Use this option only for troubleshooting purposes.

scanner.autoscaling.disable

If you set this option to true, Red Hat Advanced Cluster Security for Kubernetes disables autoscaling on the Scanner deployment.

scanner.autoscaling.minReplicas

The minimum number of replicas for autoscaling. Defaults to 2.

scanner.autoscaling.maxReplicas

The maximum number of replicas for autoscaling. Defaults to 5.

scanner.nodeSelector

Specify a node selector label as label-key: label-value to force Scanner to only schedule on nodes with the specified label.

scanner.tolerations

If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner.

scanner.dbNodeSelector

Specify a node selector label as label-key: label-value to force Scanner DB to only schedule on nodes with the specified label.

scanner.dbTolerations

If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB.

scanner.resources.requests.memory

The memory request for the Scanner container. Use this parameter to override the default value.

scanner.resources.requests.cpu

The CPU request for the Scanner container. Use this parameter to override the default value.

scanner.resources.limits.memory

The memory limit for the Scanner container. Use this parameter to override the default value.

scanner.resources.limits.cpu

The CPU limit for the Scanner container. Use this parameter to override the default value.

scanner.dbResources.requests.memory

The memory request for the Scanner DB container. Use this parameter to override the default value.

scanner.dbResources.requests.cpu

The CPU request for the Scanner DB container. Use this parameter to override the default value.

scanner.dbResources.limits.memory

The memory limit for the Scanner DB container. Use this parameter to override the default value.

scanner.dbResources.limits.cpu

The CPU limit for the Scanner DB container. Use this parameter to override the default value.

monitoring.openshift.enabled

If you set this option to false, Red Hat Advanced Cluster Security for Kubernetes will not set up Red Hat OpenShift monitoring. Defaults to true on Red Hat OpenShift 4.

network.enableNetworkPolicies

To provide security at the network level, RHACS creates default NetworkPolicy resources in the namespace where secured cluster resources are installed. These network policies allow ingress to specific components on specific ports. If you do not want RHACS to create these policies, set this parameter to False. This is a Boolean value. The default value is True, which means the default policies are automatically created.

Warning

Disabling creation of default network policies can break communication between RHACS components. If you disable creation of default policies, you must create your own network policies to allow this communication.

7.6.2.3.1.1. Environment variables
Copy link

You can specify environment variables for Sensor and Admission controller in the following format: 

customize:
  envVars:
    ENV_VAR1: "value1"
    ENV_VAR2: "value2"

The customize setting allows you to specify custom Kubernetes metadata (labels and annotations) for all objects created by this Helm chart and additional pod labels, pod annotations, and container environment variables for workloads.

The configuration is hierarchical, in the sense that metadata defined at a more generic scope (for example, for all objects) can be overridden by metadata defined at a narrower scope (for example, only for the Sensor deployment).

After you configure the values-public.yaml and values-private.yaml files, install the secured-cluster-services Helm chart to deploy the following per-cluster and per-node components:

  • Sensor
  • Admission controller
  • Collector
  • Scanner: optional for secured clusters when the StackRox Scanner is installed
  • Scanner DB: optional for secured clusters when the StackRox Scanner is installed
  • Scanner V4 Indexer and Scanner V4 DB: optional for secured clusters when Scanner V4 is installed

Prerequisites

  • You must have generated a cluster registration secret (CRS) or an init bundle for your cluster.
  • You must have access to the Red Hat Container Registry and a pull secret for authentication. For information about downloading images from registry.redhat.io, see Red Hat Container Registry Authentication.
  • You must have the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the RHACS instance you created.

Procedure

  • Run the following command: 

    $ helm install -n stackrox \
  --create-namespace stackrox-secured-cluster-services rhacs/secured-cluster-services \
  -f <name_of_cluster_init_bundle.yaml> \
  -f <path_to_values_public.yaml> \
  -f <path_to_values_private.yaml> \
  --set imagePullSecrets.username=<username> \
  --set imagePullSecrets.password=<password>

    where:

    <path_to_values_public.yaml>
    Specifies the path to your public YAML configuration file.
    <path_to_values_private.yaml>
    Specifies the path to your private YAML configuration file.
    <username>
    Specifies the user name for your pull secret for Red Hat Container Registry authentication.
    <password>
    Specifies the password for your pull secret for Red Hat Container Registry authentication.
    Note

    To deploy secured-cluster-services Helm chart by using a continuous integration (CI) system, pass the CRS or the init bundle YAML file as an environment variable to the helm install command: 

    $ helm install ... -f <(echo "$INIT_BUNDLE_YAML_SECRET")

    If you are using base64 encoded variables, use the helm install …​ -f <(echo "$INIT_BUNDLE_YAML_SECRET" | base64 --decode) command instead.

You can make changes to any configuration options after you have deployed the secured-cluster-services Helm chart.

When using the helm upgrade command to make changes, the following guidelines and requirements apply:

  • You can also specify configuration values using the --set or --set-file parameters. However, these options are not saved, and you must manually specify all the options again whenever you make changes.

  • Some changes, such as enabling a new component, require new certificates to be issued for the component. Therefore, you must provide a CA when making these changes.

    • If the CA was generated by the Helm chart during the initial installation, you must retrieve these automatically generated values from the cluster and provide them to the helm upgrade command. The post-installation notes of the central-services Helm chart include a command for retrieving the automatically generated values.
    • If the CA was generated outside of the Helm chart and provided during the installation of the central-services chart, then you must perform that action again when using the helm upgrade command, for example, by using the --reuse-values flag with the helm upgrade command.

Procedure

  1. Update the values-public.yaml and values-private.yaml configuration files with new values.

  2. Run the helm upgrade command and specify the configuration files using the -f option: 

    $ helm upgrade -n stackrox \
  stackrox-secured-cluster-services rhacs/secured-cluster-services \
  --reuse-values \
  -f <path_to_values_public.yaml> \
  -f <path_to_values_private.yaml>

    where:

    --reuse-values
    Specifies that the modified values are not included in the values_public.yaml and values_private.yaml files.

To install RHACS on secured clusters by using the CLI, perform the following steps:

  1. Install the roxctl CLI.
  2. Install Sensor.

7.6.3.1. Installing the roxctl CLI
Copy link

You must first download the binary. You can install roxctl on Linux, Windows, or macOS.

7.6.3.1.1. Installing the roxctl CLI on Linux
Copy link

You can install the roxctl CLI binary on Linux by using the following procedure.

Note

roxctl CLI for Linux is available for amd64, arm64, ppc64le, and s390x architectures.

Procedure

  1. Determine the roxctl architecture for the target operating system: 

    $ arch="$(uname -m | sed "s/x86_64//")"; arch="${arch:+-$arch}"

  2. Download the roxctl CLI: 

    $ curl -L -f -o roxctl "https://mirror.openshift.com/pub/rhacs/assets/4.10.1/bin/Linux/roxctl${arch}"

  3. Make the roxctl binary executable: 

    $ chmod +x roxctl

  4. Place the roxctl binary in a directory that is on your PATH:

    To check your PATH, execute the following command: 

    $ echo $PATH

Verification

  • Verify the roxctl version you have installed: 

    $ roxctl version
7.6.3.1.2. Installing the roxctl CLI on macOS
Copy link

You can install the roxctl CLI binary on macOS by using the following procedure.

Note

roxctl CLI for macOS is available for amd64 and arm64 architectures.

Procedure

  1. Determine the roxctl architecture for the target operating system: 

    $ arch="$(uname -m | sed "s/x86_64//")"; arch="${arch:+-$arch}"

  2. Download the roxctl CLI: 

    $ curl -L -f -o roxctl "https://mirror.openshift.com/pub/rhacs/assets/4.10.1/bin/Darwin/roxctl${arch}"

  3. Remove all extended attributes from the binary: 

    $ xattr -c roxctl

  4. Make the roxctl binary executable: 

    $ chmod +x roxctl

  5. Place the roxctl binary in a directory that is on your PATH:

    To check your PATH, execute the following command: 

    $ echo $PATH

Verification

  • Verify the roxctl version you have installed: 

    $ roxctl version
7.6.3.1.3. Installing the roxctl CLI on Windows
Copy link

You can install the roxctl CLI binary on Windows by using the following procedure.

Note

roxctl CLI for Windows is available for the amd64 architecture.

Procedure

  • Download the roxctl CLI: 

    $ curl -f -O https://mirror.openshift.com/pub/rhacs/assets/4.10.1/bin/Windows/roxctl.exe

Verification

  • Verify the roxctl version you have installed: 

    $ roxctl version

7.6.3.2. Installing Sensor
Copy link

To monitor a cluster, you must deploy Sensor. You must deploy Sensor into each cluster that you want to monitor. This installation method is also called the manifest installation method.

To perform an installation by using the manifest installation method, follow only one of the following procedures:

  • Use the RHACS web portal to download the cluster bundle, and then extract and run the sensor script.
  • Use the roxctl CLI to generate the required sensor configuration for your OpenShift Container Platform cluster and associate it with your Central instance.

Prerequisites

  • You must have already installed Central services, or you can access Central services by selecting your ACS instance on Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service).

Procedure

  1. On your secured cluster, in the RHACS portal, go to Platform Configuration Clusters.
  2. Select Secure a cluster Legacy installation method.
  3. Specify a name for the cluster.

  4. Provide appropriate values for the fields based on where you are deploying the Sensor.

    • Enter the Central API Endpoint address. You can view this information by choosing Advanced Cluster Security ACS Instances from the Red Hat Hybrid Cloud Console navigation menu, then clicking the RHACS instance you created.
  5. Click Next to continue with the Sensor setup.

  6. Click Download YAML File and Keys to download the cluster bundle (zip archive).

    Important

    The cluster bundle zip archive includes unique configurations and keys for each cluster. Do not reuse the same files in another cluster.

  7. From a system that has access to the monitored cluster, extract and run the sensor script from the cluster bundle: 

    $ unzip -d sensor sensor-<cluster_name>.zip
     
$ ./sensor/sensor.sh

If you get a warning that you do not have the required permissions to deploy Sensor, follow the on-screen instructions, or contact your cluster administrator for help.

After Sensor is deployed, it contacts Central and provides cluster information.

Procedure

  1. Generate the required sensor configuration for your OpenShift Container Platform cluster and associate it with your Central instance by running the following command: 

    $ roxctl sensor generate openshift --openshift-version <ocp_version> --name <cluster_name> --central "$ROX_ENDPOINT"

    where:

    <ocp_version>
    Specifies the major OpenShift Container Platform version number for your cluster. For example, specify 3 for OpenShift Container Platform version 3.x and specify 4 for OpenShift Container Platform version 4.x.

  2. From a system that has access to the monitored cluster, extract and run the sensor script from the cluster bundle: 

    $ unzip -d sensor sensor-<cluster_name>.zip
     
$ ./sensor/sensor.sh

If you get a warning that you do not have the required permissions to deploy Sensor, follow the on-screen instructions, or contact your cluster administrator for help.

After Sensor is deployed, it contacts Central and provides cluster information.

Verification

  1. Return to the RHACS portal and check if the deployment is successful. If successful, when viewing your list of clusters in Platform Configuration Clusters, the cluster status displays a green checkmark and a Healthy status. If you do not see a green checkmark, use the following command to check for problems:

    • On OpenShift Container Platform, enter the following command: 

      $ oc get pod -n stackrox -w

    • On Kubernetes, enter the following command: 

      $ kubectl get pod -n stackrox -w
  2. Click Finish to close the window.

After installation, Sensor starts reporting security information to RHACS and the RHACS portal dashboard begins showing deployments, images, and policy violations from the cluster on which you have installed the Sensor.

7.6.4. Next steps
Copy link

  • Verify installation by ensuring that your secured clusters can communicate with the ACS instance.

You must configure the proxy settings for secured cluster services within the Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) environment to establish a connection between the Secured Cluster and the specified proxy server. This ensures reliable data collection and transmission.

To configure an egress proxy, you can either use the cluster-wide Red Hat OpenShift proxy or specify the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables within the SecuredCluster Custom Resource (CR) configuration file to ensure proper use of the proxy and bypass for internal requests within the specified domain.

The proxy configuration applies to all running services: Sensor, Collector, Admission Controller and Scanner.

Procedure

  • Specify the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables under the customize specification in the SecuredCluster CR configuration file:

    For example: 

    # proxy collector
customize:
  envVars:
    - name: HTTP_PROXY
      value: http://egress-proxy.stackrox.svc:xxxx
    - name: HTTPS_PROXY
      value: http://egress-proxy.stackrox.svc:xxxx
    - name: NO_PROXY
      value: .stackrox.svc

    where:

    customize.envVars.value.name:<HTTP_PROXY>
    Specifies the value of the HTTP_PROXY variable. This is the proxy server used for HTTP connections.
    customize.envVars.value.name:<HTTPS_PROXY>
    Specifies the value of the HTTPS_PROXY variable. This is the proxy server used for HTTPS connections.
    customize.envVars.value.name:<NO_PROXY>
    Specifies the value of the NO _PROXY variable. This variable is used to define the hostname or IP address that should not be accessed through the proxy server.

7.8. Verifying installation of secured clusters
Copy link

After installing RHACS Cloud Service, you can perform some steps to verify that the installation was successful.

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 Installing secured cluster resources from RHACS Cloud Service.
  • Examine your Sensor pod logs to ensure that the connection to your RHACS Cloud Service instance is successful.
  • In the Red Hat OpenShift cluster, go 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.
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top