SupportConsoleDevelopersStart a trialContact

Chapter 5. Setting up RHACS Cloud Service on Red Hat OpenShift

5.1. Setting up RHACS Cloud Service on Red Hat OpenShift

Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) provides security services for your Kubernetes clusters, such as OpenShift Kubernetes Engine (OKE), Red Hat OpenShift Dedicated (OSD), Azure Red Hat OpenShift (ARO), and Red Hat OpenShift Service on Amazon Web Services (ROSA).

For information about configuring RHACS Cloud Service for other platforms, such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Microsoft Azure Kubernetes Service (AKS), see Overview of installing RHACS Cloud Service on other platforms.

Prerequisites

To set up RHACS Cloud Service:

  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 to connect 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 will need your Red Hat Single Sign-On (RH-SSO) credentials, or credentials for another identity provider if that has been configured.
  3. In the ACS console, generate an init bundle.
  4. Using a terminal window, log in to your OpenShift Container Platform cluster and apply the init bundle.
  5. Using OpenShift Container Platform, install secured cluster resources on each of your secured clusters.

5.2. Prerequisites for RHACS Cloud Service on Red Hat OpenShift

You must complete prerequisites before installing Red Hat Advanced Cluster Security Cloud Service for Red Hat OpenShift on secured clusters.

5.2.1. General requirements

RHACS has some system requirements that must be met before installing.

Warning

You must not install Red Hat Advanced Cluster Security for Kubernetes on:

  • Amazon Elastic File System (Amazon EFS). Use the Amazon Elastic Block Store (Amazon EBS) with the default gp2 volume type instead.
  • Older CPUs that do not have the Streaming SIMD Extensions (SSE) 4.2 instruction set. For example, Intel processors older than Sandy Bridge and AMD processors older than Bulldozer. (These processors were released in 2011.)

To install Red Hat Advanced Cluster Security for Kubernetes, you must have:

  • OpenShift Container Platform version 4.5 or later

  • Cluster nodes with a supported operating system. For more information, see the Red Hat Advanced Cluster Security for Kubernetes Support Policy.

    • Operating system: Amazon Linux, CentOS, Container-Optimized OS from Google, Red Hat Enterprise Linux CoreOS (RHCOS), Debian, Red Hat Enterprise Linux (RHEL), or Ubuntu.

    • Processor and memory: 2 CPU cores and at least 3GiB of RAM.

      Note

      For deploying Central, use a machine type with four or more cores and apply scheduling policies to launch Central on such nodes.

    • Architectures: AMD64, ppc64le, or s390x.

      Note

      You can only install RHACS Secured cluster services on IBM Power, IBM zSystems, and IBM® LinuxONE clusters. Central is not supported at this time.

  • Persistent storage by using persistent volume claim (PVC).

    Important

    You must not use Ceph FS storage with Red Hat Advanced Cluster Security for Kubernetes. Red Hat recommends using RBD block mode PVCs for Red Hat Advanced Cluster Security for Kubernetes.

    • Use Solid-State Drives (SSDs) for best performance. However, you can use another storage type if you do not have SSDs available.

To install using Helm charts:

  • You must have Helm command-line interface (CLI) v3.2 or newer, if you are installing or configuring Red Hat Advanced Cluster Security for Kubernetes using Helm charts. Use the helm version command to verify the version of Helm you have installed.
  • The Red Hat OpenShift CLI (oc).
  • You must have access to the Red Hat Container Registry. For information about downloading images from registry.redhat.io, see Red Hat Container Registry Authentication.

5.2.2. Prerequisites for installing Scanner

Red Hat Advanced Cluster Security for Kubernetes includes an image vulnerability scanner called Scanner. This service scans images that are not already scanned by scanners integrated into image registries.

Memory and storage requirements
ScannerCPUMemory

Request

1.2 cores

2700 MiB

Limit

5 cores

8000 MiB

5.2.3. Prerequisites for installing Sensor

Sensor monitors your Kubernetes and OpenShift Container Platform clusters. These services currently deploy in a single deployment, which handles interactions with the Kubernetes API and coordinates with Collector.

Memory and storage requirements
SensorCPUMemory

Request

1 core

1 GiB

Limit

2 cores

4 GiB

5.2.4. Prerequisites for installing Admission controller

The Admission controller prevents users from creating workloads that violate policies you configure.

Memory and storage requirements

By default, the admission control service runs 3 replicas. The following table lists the request and limits for each replica.

Admission controllerCPUMemory

Request

.05 cores

100 MiB

Limit

.5 cores

500 MiB

5.2.5. Prerequisites for installing Collector

Collector monitors runtime activity on each node in your secured clusters. It connects to Sensor to report this information.

Caution

To install Collector on systems that have Unified Extensible Firmware Interface (UEFI) and that have Secure Boot enabled, you must use eBPF probes because kernel modules are unsigned, and the UEFI firmware cannot load unsigned packages. Collector identifies Secure Boot status at the start and switches to eBPF probes if required.

Memory and storage requirements
CollectorCPUMemory

Request

.05 cores

320 MiB

Limit

.75 cores

1 GiB

Note

Collector uses a mutable image tag (<version>-latest), so you get support for newer Linux kernel versions more easily. There is no change in code, pre-existing kernel modules, or eBPF programs for image updates. Updates only add a single image layer with support for new kernel versions published after the initial release.

5.3. Creating a RHACS Cloud instance on Red Hat OpenShift

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 multiple clusters.

5.3.1. Creating an instance in the console

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 multiple 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 AWS.
    • Availability zones: Use the default value.
  4. Click Create instance.

Next step

  • Generate an init bundle by using the ACS Console.

5.4. Generating and applying an init bundle for RHACS Cloud Service on Red Hat OpenShift

Before you install the SecuredCluster resource on a cluster, you must create an init bundle. The cluster that has SecuredCluster installed and configured then uses this bundle to authenticate with Central. You can create an init bundle by using either the RHACS portal or the roxctl CLI. You then apply the init bundle by using it to create resources.

Note

You must have the Admin user role to create an init bundle.

5.4.1. Generating an init bundle

5.4.1.1. Generating an init bundle by using the RHACS portal

You can create an init bundle containing secrets by using the RHACS portal, also called the ACS Console.

Note

You must have the Admin user role to create an init bundle.

Procedure

  1. On the RHACS portal, 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.

    1. If you are installing using Helm charts, click Download Helm Values File to download the generated bundle.
    2. If you are installing using the Operator, click Download Kubernetes Secret File to download the generated bundle.
Important

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

Next steps

  1. Apply the init bundle by creating a resource on the secured cluster.
  2. Install secured cluster services on each cluster.

5.4.1.2. Generating an init bundle by using the roxctl CLI

You can create 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.

  • Set the ROX_API_TOKEN and the ROX_CENTRAL_ADDRESS environment variables: 

    $ export ROX_API_TOKEN=<api_token>
    $ export ROX_CENTRAL_ADDRESS=<address>:<port_number>

Procedure

  • Run the following command to generate a cluster init bundle containing secrets:

    For Helm installations: 

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

    For Operator installations: 

    $ 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 multiple secured clusters.

Next Step

  • Use the Red Hat OpenShift CLI to create resources using the init bundle.

5.4.2. Applying an init bundle by creating a resource

5.4.2.1. Creating resources by using the init bundle

Before you install secured clusters, you must use the init bundle to create the required resources on the cluster that will allow the services on the secured clusters to communicate with Central.

Note

If you are installing by using Helm charts, do not perform this step.

Prerequisites

  • You must have generated an init bundle containing secrets.

Procedure

To create resources, perform one of the following steps:

  • In the OpenShift Container Platform web console, in the top menu, click + to open the Import YAML page. You can drag the init bundle file or copy and paste its contents into the editor, and then click Create.

  • 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 where Central services are installed.

  • Using the kubectl CLI, run the following commands to create the resources: 

    $ kubectl create namespace stackrox
$ kubectl 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 where secured cluster services will be installed.

Next Step

  • Install RHACS secured cluster services in all clusters that you want to monitor.

5.5. Installing secured cluster resources for RHACS Cloud Service on Red Hat OpenShift

You can install RHACS Cloud Service on your secured clusters by using the Operator.

Ensure that you have performed the following steps:

  • Created your OpenShift Container Platform cluster and installed the Operator on it.
  • In the ACS Console in RHACS Cloud Service, you have created and downloaded the init bundle.
  • You applied the init bundle by using the oc create command.
  • During installation, you noted the Central API Endpoint, including the address and the port number. 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.

You can install RHACS on your secured clusters by using one of the following methods:

  • By using the Operator
  • By using Helm charts
  • By using the roxctl CLI (do not use this method unless you have a specific installation need that requires using it)

5.5.1. Installing RHACS on secured clusters by using the Operator

5.5.1.1. Installing secured cluster services

You can install secured cluster services on your clusters by using the SecuredCluster custom resource. You must install the secured cluster services on every cluster in your environment that you want to monitor.

Caution

When you install secured cluster services, Collector is also installed. To install Collector on systems that have Unified Extensible Firmware Interface (UEFI) and that have Secure Boot enabled, you must use eBPF probes because kernel modules are unsigned, and the UEFI firmware cannot load unsigned packages. Collector identifies Secure Boot status at the start and switches to eBPF probes if required.

Prerequisites

  • If you are using OpenShift Container Platform, you must install version 4.6 or later.
  • You have installed the RHACS Operator.
  • You have generated an init bundle and applied it to the cluster.

Procedure

  1. On the OpenShift Container Platform web console, navigate to the Operators Installed Operators page.
  2. Click the RHACS Operator.
  3. Click Secured Cluster from the central navigation menu in the Operator details page.
  4. Click Create SecuredCluster.

  5. 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 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.
  6. 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.
  7. Optional: Add any labels for the cluster.
  8. Enter a unique name for your SecuredCluster custom resource.

  9. For Central Endpoint, enter the address and port number of your Central instance. For example, if Central is available at https://central.example.com, then specify the central endpoint as central.example.com:443. The default value of central.stackrox.svc:443 only works when you install secured cluster services and Central in the same cluster. 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.

    • For RHACS Cloud Service use the Central API Endpoint, including the address and the port number. You can view this information by choosing Advanced Cluster Security ACS Instances from the cloud console navigation menu, then clicking the ACS instance you created.
    • Only if you are installing secured cluster services and Central in the same cluster, use central.stackrox.svc:443.
  10. Accept the default values or configure custom values if needed. For example, you may need to configure TLS if you are using custom certificates or untrusted CAs.
  11. Click Create.

Next step

  1. Optional: Configure additional secured cluster settings.
  2. Verify installation.

5.5.2. Installing RHACS Cloud Service on secured clusters by using Helm charts

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.

5.5.2.1. Adding the Helm chart repository

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:

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

    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/

5.5.2.2. Installing RHACS Cloud Service on secured clusters by using Helm charts without customizations

5.5.2.2.1. Installing the secured-cluster-services Helm chart without customization

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

Caution

To install Collector on systems that have Unified Extensible Firmware Interface (UEFI) and that have Secure Boot enabled, you must use eBPF probes because kernel modules are unsigned, and the UEFI firmware cannot load unsigned packages. Collector identifies Secure Boot status at the start and switches to eBPF probes if required.

Prerequisites

  • You must have generated RHACS init bundle for your cluster.
  • You must have the Central API Endpoint, including the address and the port number. You can view this information by choosing Advanced Cluster Security ACS Instances from the cloud console navigation menu, then clicking the ACS instance you created.

Procedure

  • Run the following command on your Kubernetes based clusters: 

    $ helm install -n stackrox --create-namespace \
    stackrox-secured-cluster-services rhacs/secured-cluster-services \
    -f <path_to_cluster_init_bundle.yaml> \ 1
    --set clusterName=<name_of_the_secured_cluster> \
    --set centralEndpoint=<endpoint_of_central_service> 2
--set imagePullSecrets.username=<your redhat.com username> \
--set imagePullSecrets.password=<your redhat.com password>
    1
    Use the -f option to specify the path for the init bundle.
    2
    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.

Additional resources

5.5.2.3. Configuring the secured-cluster-services Helm chart with customizations

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.

5.5.2.3.1. Configuration parameters
ParameterDescription

clusterName

Name of your cluster.

centralEndpoint

Address, including port number, 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:443).

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

Address of the registry you are using for the main image.

image.collector.registry

Address of the registry you are using for the Collector 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 EBPF, KERNEL_MODULE, 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.listenOnCreates

This setting controls whether Kubernetes is configured to contact Red Hat Advanced Cluster Security for Kubernetes with AdmissionReview requests for workload creation events.

admissionControl.listenOnUpdates

When you set this parameter as false, Red Hat Advanced Cluster Security for Kubernetes creates the ValidatingWebhookConfiguration in a way that causes the Kubernetes API server not to send object update events. Since the volume of object updates is usually higher than the object creates, leaving this as false limits the load on the admission control service and decreases the chances of a malfunctioning admission control service.

admissionControl.listenOnEvents

This setting controls whether the cluster is configured to contact Red Hat Advanced Cluster Security for Kubernetes with AdmissionReview requests for Kubernetes exec and portforward events. Red Hat Advanced Cluster Security for Kubernetes does not support this feature on OpenShift Container Platform 3.11.

admissionControl.dynamic.enforceOnCreates

This setting controls whether Red Hat Advanced Cluster Security for Kubernetes evaluates policies; if it is disabled, all AdmissionReview requests are automatically accepted.

admissionControl.dynamic.enforceOnUpdates

This setting controls the behavior of the admission control service. You must specify listenOnUpdates as true for this to work.

admissionControl.dynamic.scanInline

If you set this option to true, the admission control service requests an image scan before making an admission decision. Since image scans take several seconds, enable this option only if you can ensure that all images used in your cluster are scanned before deployment (for example, by a CI integration during image build). This option corresponds to the Contact image scanners option in the RHACS Portal.

admissionControl.dynamic.disableBypass

Set it to true to disable bypassing the Admission controller.

admissionControl.dynamic.timeout

The maximum time, in seconds, Red Hat Advanced Cluster Security for Kubernetes should wait while evaluating admission review requests. Use this to set request timeouts when you enable image scanning. If the image scan runs longer than the specified time, Red Hat Advanced Cluster Security for Kubernetes accepts the request.

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

Specify true if you want to use a slim Collector image for deploying Collector. Using slim Collector images requires Central to provide the matching eBPF probe or kernel module. If you are running Red Hat Advanced Cluster Security for Kubernetes in offline mode, you must download a kernel support package from stackrox.io and upload it to Central for slim Collectors to function. Otherwise, you must ensure that Central can access the online probe repository hosted at https://collector-modules.stackrox.io/.

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.

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.

scanner.disable

If you set this option to false, Red Hat Advanced Cluster Security for Kubernetes deploys a lightweight scanner and Scanner DB in the secured cluster to allow scanning images on OpenShift Container Registry. Enabling Scanner is only supported on OpenShift. 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.

5.5.2.3.1.1. Environment variables

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

5.5.2.3.2. Installing the secured-cluster-services Helm chart

After you configure the values-public.yaml and values-private.yaml files, install the secured-cluster-services Helm chart to deploy the per-cluster and per-node components (Sensor, Admission controller, and Collector).

Caution

To install Collector on systems that have Unified Extensible Firmware Interface (UEFI) and that have Secure Boot enabled, you must use eBPF probes because kernel modules are unsigned, and the UEFI firmware cannot load unsigned packages. Collector identifies Secure Boot status at the start and switches to eBPF probes if required.

Prerequisites

  • You must have generated RHACS init bundle for your cluster.
  • You must have the Central API Endpoint, including the address and the port number. You can view this information by choosing Advanced Cluster Security ACS Instances from the cloud console navigation menu, then clicking the ACS 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> 1
    1
    Use the -f option to specify the paths for your YAML configuration files.
Note

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

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

Additional resources

5.5.2.4. Changing configuration options after deploying the secured-cluster-services Helm chart

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

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 \ 1
  -f <path_to_values_public.yaml> \
  -f <path_to_values_private.yaml>
    1
    You must specify the --reuse-values parameter, otherwise the Helm upgrade command resets all previously configured settings.
    Note

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

5.5.3. Installing RHACS on secured clusters by using the roxctl CLI

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

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

5.5.3.1. Installing the roxctl CLI

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

5.5.3.1.1. Installing the roxctl CLI on Linux

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

Procedure

  1. Download the latest version of the roxctl CLI: 

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.74.9/bin/Linux/roxctl

  2. Make the roxctl binary executable: 

    $ chmod +x roxctl

  3. 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
5.5.3.1.2. Installing the roxctl CLI on macOS

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

Procedure

  1. Download the latest version of the roxctl CLI: 

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.74.9/bin/Darwin/roxctl

  2. Remove all extended attributes from the binary: 

    $ xattr -c roxctl

  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
5.5.3.1.3. Installing the roxctl CLI on Windows

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

Procedure

  • Download the latest version of the roxctl CLI: 

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

Verification

  • Verify the roxctl version you have installed: 

    $ roxctl version

5.5.3.2. Installing Sensor

To monitor a cluster, you must deploy Sensor. You must deploy Sensor into each cluster that you want to monitor. The following steps describe adding Sensor by using the RHACS portal.

Prerequisites

  • You must have already installed Central services, or you can access Central services on Red Hat Advanced Cluster Security Cloud Service (ACSCS).

Procedure

  1. On the RHACS portal, navigate to Platform Configuration Clusters.
  2. Select + New Cluster.
  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, including the address and the port number. You can view this information again in the Red Hat Hybrid Cloud Console by choosing Advanced Cluster Security ACS Instances, and then clicking the ACS 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, unzip 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 assistance.

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 Kubernetes: 

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

5.6. Verifying installation of RHACS Cloud Service on Red Hat OpenShift

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 will display 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.
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.

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.

© 2024 Red Hat, Inc.