Installing
Installing Red Hat Advanced Cluster Security for Kubernetes
Abstract
Chapter 1. Supported platforms and installation methods
Red Hat Advanced Cluster Security for Kubernetes (RHACS) and Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) are supported on OpenShift Container Platform and Kubernetes platforms.
1.1. Installation methods for different platforms
You can perform different types of installations on different platforms.
Not all installation methods are supported for all platforms.
Platform type [1] | Platform | Supported for Central | Supported for Secured Clusters | Supported installation methods | Installation steps |
---|---|---|---|---|---|
Managed service platform | Red Hat OpenShift Dedicated (OSD) | Yes [2] | Yes [2] | Operator (recommended), Helm charts, or roxctl CLI [3] | |
Azure Red Hat OpenShift (ARO) | Yes [2] | Yes [2] | |||
Red Hat OpenShift Service on AWS (ROSA) | Yes [2] | Yes [2] | |||
Amazon Elastic Kubernetes Service (Amazon EKS) | Limited [4] | Yes | Helm charts (recommended), or roxctl CLI [3] | ||
Google Kubernetes Engine (Google GKE) | Limited [4] | Yes | |||
Microsoft Azure Kubernetes Service (Microsoft AKS) | Limited [4] | Yes | |||
Self-managed platform | Red Hat OpenShift Container Platform (OCP) 4.x | Yes | Yes | Operator (recommended), Helm charts, or roxctl CLI [3] | |
Red Hat OpenShift Kubernetes Engine (OKE) 4.x | No | Yes |
- The availability of support for each platform depends on the overarching lifecycle of the platform and the end-of-life date.
- Red Hat Advanced Cluster Security for Kubernetes (RHACS) is supported as a self-managed add-on for managed OpenShift services that meet the installation and sizing requirements for RHACS. Deploying and managing RHACS components does not fall under the service description for the managed service, and therefore RHACS is not included in the SRE service.
-
Do not use the
roxctl
installation method unless you have a specific installation that requires this method. - RHACS Central is tested, qualified, and is fully supported exclusively on OpenShift Container Platform 4. Deployment and use of Central in environments that are not OpenShift Container Platform 4 is possible, but support is limited to the RHACS product software only and not to the underlying infrastructure provider. As part of problem diagnosis and isolation, it is necessary to reproduce problems in an OpenShift Container Platform 4 environment. If an issue is specific to a provider and cluster that is not OpenShift Container Platform 4, Red Hat provides commercially reasonable support to isolate issues. You are expected to open a case with your respective provider. For instructions, see the Red Hat 3rd Party Support Policy.
1.2. Installation methods for different architectures
Red Hat Advanced Cluster Security for Kubernetes (RHACS) and Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) supports the following architectures.
Supported architectures | Supported for Central | Supported for Secured Clusters | Supported installation methods |
---|---|---|---|
AMD64 | Yes | Yes | Operator (preferred), Helm charts, or roxctl CLI (not recommended) |
ppc64le (IBM Power) | No | Yes (OpenShift Container Platform version 4.12 only) | Operator is the only supported install method. |
s390x (IBM zSystems and IBM® LinuxONE) | No | Yes (OpenShift Container Platform versions 4.10 and 4.12 only) |
1.3. Supported Browsers for RHACS
Red Hat Advanced Cluster Security for Kubernetes (RHACS) browser support complies with Red Hat policy and includes the following browsers:
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
Chapter 2. Getting started with RHACS Cloud Service
Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) provides security services for your Kubernetes clusters on different platforms.
This topic provides instructions to get started using RHACS Cloud Service on Red Hat OpenShift, including OpenShift Container Platform, OpenShift Kubernetes Engine (OKE), Red Hat OpenShift Dedicated (OSD), Azure Red Hat OpenShift (ARO), and Red Hat OpenShift Service on Amazon Web Services (ROSA). See the inline notes for information that differs for RHACS Cloud Service on other Kubernetes platforms.
This installation example shows you how to set up RHACS Cloud Service on OpenShift Container Platform using the Operator. It does not cover installations using Helm charts or the roxctl
CLI.
Prerequisites
- Ensure that you can access the Advanced Cluster Security menu option from the Red Hat Hybrid Cloud Console.
2.1. Accessing the ACS Console
In the Red Hat Hybrid Cloud Console, from the navigation menu, select Advanced Cluster Security → ACS Instances, and then select the instance that you want connected to your secured clusters.
- In the Instance Details section, note the Central API Endpoint. You use this address when creating secured clusters.
- Click Open ACS Console. You need your Red Hat Single Sign-On (RH-SSO) credentials, or credentials for another identity provider if that has been configured.
2.2. Creating an RHACS Cloud Service project
-
In your OpenShift Container Platform cluster, navigate to Home → Projects and create a project for RHACS Cloud Service. Red Hat suggests using
stackrox
as the project Name.
2.3. Generating an init bundle
- In the ACS console, navigate to Platform Configuration → Integrations.
- Navigate to the Authentication Tokens section and click on Cluster Init Bundle.
- Click Generate bundle.
- Enter a name for the cluster init bundle and click Generate.
Click Download Kubernetes Secret File to download the generated bundle.
ImportantStore this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.
2.4. Applying an init bundle by creating resources
Using a terminal window, log in to your OpenShift Container Platform cluster, and using the Red Hat OpenShift CLI, run the following command to create the resources:
$ oc create -f <init_bundle>.yaml \ 1 -n <stackrox> 2
For non-OpenShift Kubernetes clusters, enter the comparable kubectl
commands to create the resources.
2.5. Installing secured cluster resources on each cluster
These steps assume that you are installing resources by using the Operator.
For installation on non-OpenShift Kubernetes clusters, you must use Helm charts or the roxctl
CLI to install secured cluster resources.
2.5.1. Installing the Operator on the cluster
- On your cluster, in the web console, go to the Operators → OperatorHub page.
- 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.
- Select the Red Hat Advanced Cluster Security for Kubernetes Operator to view the details page.
- Read the information about the Operator and click Install.
On the Install Operator page:
- Keep the default value for Installation mode as All namespaces on the cluster.
- Choose a specific namespace for the Installed namespace field. Red Hat recommends installing the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operator namespace.
- Select automatic or manual updates for Update approval. Red Hat recommends that you select automatic updates and choose the latest option for the Operator channel.
- Click Install.
Verification
- After the installation completes, navigate to Operators → Installed Operators to verify that the Red Hat Advanced Cluster Security for Kubernetes Operator is listed with the status of Succeeded.
2.5.2. Creating Secured Cluster resources
- On your cluster, navigate to Operators → Installed Operators.
-
Click the Project menu and select the
stackrox
namespace. - Under Provided APIs, select Secured Cluster.
- In the SecuredClusters page, click Create SecuredCluster.
- Select Form view.
- Enter the new project name by accepting or editing the default name. The default value is stackrox-secured-cluster-services.
- Optional: Add any labels for the cluster.
-
Enter a unique name for your
SecuredCluster
custom resource. - 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.
- Click Create.
2.5.3. Verifying RHACS Cloud Service installation
To verify installation, access your ACS Console from the Red Hat Hybrid Cloud Console. The Dashboard displays the number of clusters that RHACS Cloud Service is monitoring, along with information about nodes, deployments, images, and violations.
If no data appears in the ACS Console:
- Ensure that at least one secured cluster is connected to your RHACS Cloud Service instance. For more information, see the "Installing secured cluster resources on each cluster" section.
- Examine your Sensor pod logs to ensure that the connection to your RHACS Cloud Service instance is successful.
- In the OCP cluster, navigate to Platform Configuration → Clusters to verify that the components are healthy and view additional operational information.
-
Examine the values in the
SecuredCluster
API in the Operator on your local cluster to ensure that the Central API Endpoint has been entered correctly. This value should be the same value as shown in the ACS instance details in the Red Hat Hybrid Cloud Console.
2.6. Default access to ACS Console
By default, the authentication mechanism available to users is authentication by using Red Hat Single Sign-On (SSO). You cannot delete or change the Red Hat SSO authentication provider. However, you can change the minimum access role and add additional rules, or add another identity provider.
To learn how authentication providers work in ACS, visit Understanding authentication providers.
A dedicated OIDC client of sso.redhat.com
is created for each ACS Console. All OIDC clients share the same sso.redhat.com
realm. Claims from the token issued by sso.redhat.com
are mapped to an ACS-issued token as follows:
-
realm_access.roles
togroups
-
org_id
torh_org_id
-
is_org_admin
torh_is_org_admin
-
sub
touserid
The built-in Red Hat SSO authentication provider has the required attribute rh_org_id
set to the organization ID assigned to account of the user who created the ACSCS instance. This is the ID of the organizational account the user is a part of. This can be thought of as the "tenant" the user is under and owned by. Only users with the same organizational account can access the ACS console by using the Red Hat SSO authentication provider.
To gain more control over access to your ACS Console, configure another identity provider instead of relying on the Red Hat SSO authentication provider. You can set up your own identity provider after provisioning by using one of the guides under Operating → Managing user access.
To configure this authentication provider to be the first authentication option on the login page, its name should be lexicographically smaller than Red Hat SSO
.
The minimum access role is set to None
. Assigning a different value to this field gives access to the ACSCS instance to all users with the same organizational account.
Other rules that are set up in the built-in Red Hat SSO authentication provider include the following:
-
Rule mapping your
userid
toAdmin
-
Rules mapping administrators of the organization to
Admin
You can add more rules to grant access to the ACS Console to someone else with the same organizational account; for example, by using email
as a key.
Chapter 3. Installing RHACS on Red Hat OpenShift
3.1. High-level overview of installing RHACS on Red Hat OpenShift
Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides security services for your self-managed Red Hat OpenShift Kubernetes systems.
Before you install:
- Understand the installation platforms and methods.
- Understand Red Hat Advanced Cluster Security for Kubernetes architecture.
- Review the prerequisites.
The following list provides a high-level overview of installation steps:
-
Install Central services on a cluster using the Operator, Helm charts, or the
roxctl
CLI. - Generate and apply an init bundle.
- Install secured cluster resources on each of your secured clusters.
3.2. Prerequisites for RHACS on Red Hat OpenShift
Before you install RHACS for OpenShift Container Platform or another OCP-compatible supported Kubernetes platform, ensure you have met the prerequisites.
3.2.1. General requirements
RHACS has some system requirements that must be met before installing.
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:
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.
NoteFor 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.
NoteYou 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).
ImportantYou 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. -
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.
3.2.2. Prerequisites for installing Central
A single containerized service called Central handles data persistence, API interactions, and user interface (Portal) access.
Central requires persistent storage:
You can provide storage with a persistent volume claim (PVC).
NoteYou can use a hostPath volume for storage only if all your hosts (or a group of hosts) mount a shared file system, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node. Red Hat does not recommend using a hostPath volume.
- Use Solid-State Drives (SSD) for best performance. However, you can use another storage type if you do not have SSDs available.
If you use a web proxy or firewall, you must configure bypass rules to allow traffic for the
definitions.stackrox.io
andcollector-modules.stackrox.io
domains and enable Red Hat Advanced Cluster Security for Kubernetes to trust your web proxy or firewall. Otherwise, updates for vulnerability definitions and kernel support packages will fail.Red Hat Advanced Cluster Security for Kubernetes requires access to:
-
definitions.stackrox.io
for downloading updated vulnerability definitions. Vulnerability definition updates allow Red Hat Advanced Cluster Security for Kubernetes to maintain up-to-date vulnerability data when new vulnerabilities are discovered or additional data sources are added. -
collector-modules.stackrox.io
to download updated kernel support packages. Updated Kernel support packages ensure that Red Hat Advanced Cluster Security for Kubernetes can monitor the latest operating systems and collect data about the network traffic and processes running inside the containers. Without these updates, Red Hat Advanced Cluster Security for Kubernetes might fail to monitor containers if you add new nodes in your cluster or if you update your nodes' operating system.
-
For security reasons, you should deploy Central in a cluster with limited administrative access.
Memory and storage requirements
The following table lists the minimum memory and storage values required to install and run Central.
Central | CPU | Memory | Storage |
---|---|---|---|
Request | 1.5 cores | 4 GiB | 100 GiB |
Limit | 4 cores | 8 GiB | 100 GiB |
Sizing guidelines
Use the following compute resources and storage values depending upon the number of nodes in your cluster.
Nodes | Deployments | CPU | Memory | Storage |
---|---|---|---|---|
Up to 100 | Up to 1000 | 2 cores | 4 GiB | 100 GiB |
Up to 500 | Up to 2000 | 4 cores | 8 GiB | 100 GiB |
More than 500 | More than 2000 | 8 cores | 12 - 16 GiB | 100 - 200 GiB |
3.2.3. 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
Scanner | CPU | Memory |
---|---|---|
Request | 1.2 cores | 2700 MiB |
Limit | 5 cores | 8000 MiB |
3.2.4. 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
Sensor | CPU | Memory |
---|---|---|
Request | 1 core | 1 GiB |
Limit | 2 cores | 4 GiB |
3.2.5. 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 controller | CPU | Memory |
---|---|---|
Request | .05 cores | 100 MiB |
Limit | .5 cores | 500 MiB |
3.2.6. Prerequisites for installing Collector
Collector monitors runtime activity on each node in your secured clusters. It connects to Sensor to report this information.
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
Collector | CPU | Memory |
---|---|---|
Request | .05 cores | 320 MiB |
Limit | .75 cores | 1 GiB |
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.
3.3. Installing Central services for RHACS on Red Hat OpenShift
Central is the resource that contains the RHACS application management interface and services. It handles data persistence, API interactions, and RHACS portal access. You can use the same Central instance to secure multiple OpenShift Container Platform or Kubernetes clusters.
You can install Central on your OpenShift Container Platform or Kubernetes cluster by using one of the following methods:
- Install using the Operator
- Install using Helm charts
-
Install using the
roxctl
CLI (do not use this method unless you have a specific installation need that requires using it)
3.3.1. Install Central using the Operator
3.3.1.1. Installing the Red Hat Advanced Cluster Security for Kubernetes Operator
Using the OperatorHub provided with OpenShift Container Platform is the easiest way to install Red Hat Advanced Cluster Security for Kubernetes.
Prerequisites
- You have access to an OpenShift Container Platform cluster using an account with Operator installation permissions.
- You must be using OpenShift Container Platform 4.6 or later.
Procedure
- Navigate in the web console to the Operators → OperatorHub page.
- 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.
- Select the Red Hat Advanced Cluster Security for Kubernetes Operator to view the details page.
- Read the information about the Operator and click Install.
On the Install Operator page:
- Keep the default value for Installation mode as All namespaces on the cluster.
- Choose a specific namespace in which to install the Operator for the Installed namespace field. Red Hat recommends installing the Red Hat Advanced Cluster Security for Kubernetes Operator in the rhacs-operator namespace.
Select automatic or manual updates for Update approval.
If you choose 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 choose 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.
ImportantIf you choose manual updates, you must update the RHACS Operator in all secured clusters when you update the RHACS Operator in the cluster where Central is installed. The secured clusters and the cluster where Central is installed must have the same version to ensure optimal functionality.
- Click Install.
Verification
- After the installation completes, navigate to Operators → Installed Operators to verify that the Red Hat Advanced Cluster Security for Kubernetes Operator is listed with the status of Succeeded.
Next Step
-
Install, configure, and deploy the
Central
custom resource.
3.3.1.2. Installing Central using the Operator method
The main component of Red Hat Advanced Cluster Security for Kubernetes is called Central. You can install Central on OpenShift Container Platform by using the Central
custom resource. You deploy Central only once, and you can monitor multiple separate clusters by using the same Central installation.
When you install Red Hat Advanced Cluster Security for Kubernetes 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.
Prerequisites
- You must be using OpenShift Container Platform 4.6 or later.
Procedure
- On the OpenShift Container Platform web console, navigate to the Operators → Installed Operators page.
- Select the Red Hat Advanced Cluster Security for Kubernetes Operator from the list of installed Operators.
If you have installed the Operator in the recommended namespace, OpenShift Container Platform lists the project as
rhacs-operator
. Select Project: rhacs-operator → Create project.Warning-
If you have installed the Operator in a different namespace, OpenShift Container Platform shows the name of that namespace rather than
rhacs-operator
. -
You must install the Red Hat Advanced Cluster Security for Kubernetes
Central
custom resource in its own project and not in therhacs-operator
andopenshift-operator
projects, or in the project in which you have installed the Red Hat Advanced Cluster Security for Kubernetes Operator.
-
If you have installed the Operator in a different namespace, OpenShift Container Platform shows the name of that namespace rather than
-
Enter the new project name (for example,
stackrox
), and click Create. Red Hat recommends that you usestackrox
as the project name. - Under the Provided APIs section, select Central. Click Create Central.
-
Enter a name for your
Central
custom resource and add any labels you want to apply. Otherwise, accept the default values for the available options. - Click Create.
If you are using the cluster-wide proxy, Red Hat Advanced Cluster Security for Kubernetes uses that proxy configuration to connect to the external services.
Next Steps
- Verify Central installation.
- Optional: Configure Central options.
-
Generate an init bundle containing the cluster secrets that allows communication between the
Central
andSecuredCluster
resources. You need to download this bundle, use it to generate resources on the clusters you want to secure, and securely store it. - Install secured cluster services on each cluster you want to monitor.
Additional resources
3.3.1.3. Verifying Central installation using the Operator method
After Central finishes installing, log in to the RHACS portal to verify the successful installation of Central.
Procedure
- On the OpenShift Container Platform web console, navigate to the Operators → Installed Operators page.
- Select the Red Hat Advanced Cluster Security for Kubernetes Operator from the list of installed Operators.
- Select the Central tab.
-
From the Centrals list, select
stackrox-central-services
to view its details. To get the password for the
admin
user, you can either:- Click the link under Admin Password Secret Reference.
Use the Red Hat OpenShift CLI to enter the command listed under Admin Credentials Info:
$ oc -n stackrox get secret central-htpasswd -o go-template='{{index .data "password" | base64decode}}'
Find the link to the RHACS portal by using the Red Hat OpenShift CLI command:
$ oc -n stackrox get route central -o jsonpath="{.status.ingress[0].host}"
Alternatively, you can use the Red Hat Advanced Cluster Security for Kubernetes web console to find the link to the RHACS portal by performing the following commands:
- Navigate to Networking → Routes.
- Find the central Route and click on the RHACS portal link under the Location column.
-
Log in to the RHACS portal using the username admin and the password that you retrieved in a previous step. Until RHACS is completely configured (for example, you have the
Central
resource and at least oneSecuredCluster
resource installed and configured), no data is available in the dashboard. TheSecuredCluster
resource can be installed and configured on the same cluster as theCentral
resource. Clusters with theSecuredCluster
resource are similar to managed clusters in Red Hat Advanced Cluster Management (RHACM).
Next Steps
- Optional: Configure central settings.
-
Generate an init bundle containing the cluster secrets that allows communication between the
Central
andSecuredCluster
resources. You need to download this bundle, use it to generate resources on the clusters you want to secure, and securely store it. - Install secured cluster services on each cluster you want to monitor.
3.3.2. Install Central using Helm charts
You can install Central using Helm charts without any customization, using the default values, or by using Helm charts with additional customizations of configuration parameters.
3.3.2.1. Install Central using Helm charts without customization
You can install RHACS on your cluster without any customizations. You must add the Helm chart repository and install the central-services
Helm chart to install the centralized components of Central and Scanner.
3.3.2.1.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:
Central services Helm chart (
central-services
) for installing the centralized components (Central and Scanner).NoteYou 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 (Sensor and Admission controller) and per-node (Collector) components.NoteDeploy 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/
3.3.2.1.2. Installing the central-services Helm chart without customizations
Use the following instructions to install the central-services
Helm chart to deploy the centralized components (Central and Scanner).
Prerequisites
-
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.
Procedure
Run the following command to install Central services and expose Central using a route:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password> \ --set central.exposure.route.enabled=true
Or, run the following command to install Central services and expose Central using a load balancer:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password> \ --set central.exposure.loadBalancer.enabled=true
Or, run the following command to install Central services and expose Central using port forward:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password>
If you are installing Red Hat Advanced Cluster Security for Kubernetes in a cluster that requires a proxy to connect to external services, you must specify your proxy configuration by using the
proxyConfig
parameter. For example:env: proxyConfig: | url: http://proxy.name:port username: username password: password excludes: - some.domain
-
If you already created one or more image pull secrets in the namespace in which you are installing, instead of using a username and password, you can use
--set imagePullSecrets.useExisting="<pull-secret-1;pull-secret-2>"
. Do not use image pull secrets:
-
If you are pulling your images from
quay.io/stackrox-io
or a registry in a private network that does not require authentication. Use use--set imagePullSecrets.allowNone=true
instead of specifying a username and password. -
If you already configured image pull secrets in the default service account in the namespace you are installing. Use
--set imagePullSecrets.useFromDefaultServiceAccount=true
instead of specifying a username and password.
-
If you are pulling your images from
The output of the installation command includes:
- An automatically generated administrator password.
- Instructions on storing all the configuration values.
- Any warnings that Helm generates.
3.3.2.2. Install Central using Helm charts with customizations
You can install RHACS on your Red Hat OpenShift cluster with customizations by using Helm chart configuration parameters with the helm install
and helm upgrade
commands. You can 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.
3.3.2.2.1. Private configuration file
This section lists the configurable parameters of the values-private.yaml
file. There are no default values for these parameters.
3.3.2.2.1.1. Image pull secrets
The credentials that are required for pulling images from the registry depend on the following factors:
If you are using a custom registry, you must specify these parameters:
-
imagePullSecrets.username
-
imagePullSecrets.password
-
image.registry
-
If you do not use a username and password to log in to the custom registry, you must specify one of the following parameters:
-
imagePullSecrets.allowNone
-
imagePullSecrets.useExisting
-
imagePullSecrets.useFromDefaultServiceAccount
-
Parameter | Description |
---|---|
| The username of the account that is used to log in to the registry. |
| The password of the account that is used to log in to the registry. |
|
Use |
|
A comma-separated list of secrets as values. For example, |
|
Use |
3.3.2.2.1.2. Proxy configuration
If you are installing Red Hat Advanced Cluster Security for Kubernetes in a cluster that requires a proxy to connect to external services, you must specify your proxy configuration by using the proxyConfig
parameter. For example:
env: proxyConfig: | url: http://proxy.name:port username: username password: password excludes: - some.domain
Parameter | Description |
---|---|
| Your proxy configuration. |
3.3.2.2.1.3. Central
Configurable parameters for Central.
For a new installation, you can skip the following parameters:
-
central.jwtSigner.key
-
central.serviceTLS.cert
-
central.serviceTLS.key
-
central.adminPassword.value
-
central.adminPassword.htpasswd
- When you do not specify values for these parameters the Helm chart autogenerates values for them.
-
If you want to modify these values you can use the
helm upgrade
command and specify the values using the--set
option.
For setting the administrator password, you can only use either central.adminPassword.value
or central.adminPassword.htpasswd
, but not both.
Parameter | Description |
---|---|
| A private key which Red Hat Advanced Cluster Security for Kubernetes should use for signing JSON web tokens (JWTs) for authentication. |
| An internal certificate that the Central service should use for deploying Central. |
| The private key of the internal certificate that the Central service should use. |
| The user-facing certificate that Central should use. Red Hat Advanced Cluster Security for Kubernetes uses this certificate for RHACS portal.
|
| The private key of the user-facing certificate that Central should use.
|
| Administrator password for logging into Red Hat Advanced Cluster Security for Kubernetes. |
| Administrator password for logging into Red Hat Advanced Cluster Security for Kubernetes. This password is stored in hashed format using bcrypt. |
If you are using central.adminPassword.htpasswd
parameter, you must use a bcrypt encoded password hash. You can run the command htpasswd -nB admin
to generate a password hash. For example,
htpasswd: | admin:<bcrypt-hash>
3.3.2.2.1.4. Scanner
Configurable parameters for Scanner.
For a new installation, you can skip the following parameters and the Helm chart autogenerates values for them. Otherwise, if you are upgrading to a new version, specify the values for the following parameters:
-
scanner.dbPassword.value
-
scanner.serviceTLS.cert
-
scanner.serviceTLS.key
-
scanner.dbServiceTLS.cert
-
scanner.dbServiceTLS.key
Parameter | Description |
---|---|
| The password to use for authentication with Scanner database. Do not modify this parameter because Red Hat Advanced Cluster Security for Kubernetes automatically creates and uses its value internally. |
| An internal certificate that the Scanner service should use for deploying Scanner. |
| The private key of the internal certificate that the Scanner service should use. |
| An internal certificate that the Scanner-db service should use for deploying Scanner database. |
| The private key of the internal certificate that the Scanner-db service should use. |
3.3.2.2.2. Public configuration file
This section lists the configurable parameters of the values-public.yaml
file.
3.3.2.2.2.1. Image pull secrets
Image pull secrets are the credentials required for pulling images from your registry.
Parameter | Description |
---|---|
|
Use |
|
A comma-seprated list of secrets as values. For example, |
|
Use |
3.3.2.2.2.2. Image
Image declares the configuration to set up the main registry, which the Helm chart uses to resolve images for the central.image
, scanner.image
, and scanner.dbImage
parameters.
Parameter | Description |
---|---|
|
Address of your image registry. Either use a hostname, such as |
3.3.2.2.2.3. Environment variables
Red Hat Advanced Cluster Security for Kubernetes automatically detects your cluster environment and sets values for env.openshift
, env.istio
, and env.platform
. Only set these values to override the automatic cluster environment detection.
Parameter | Description |
---|---|
|
Use |
|
Use |
|
The platform on which you are installing Red Hat Advanced Cluster Security for Kubernetes. Set its value to |
|
Use |
3.3.2.2.2.4. Additional trusted certificate authorities
The Red Hat Advanced Cluster Security for Kubernetes automatically references the system root certificates to trust. When Central or Scanner must reach out to services that use certificates issued by an authority in your organization or a globally trusted partner organization, you can add trust for these services by specifying the root certificate authority to trust by using the following parameter:
Parameter | Description |
---|---|
| Specify the PEM encoded certificate of the root certificate authority to trust. |
3.3.2.2.2.5. Central
Configurable parameters for Central.
-
You must specify a persistent storage option as either
hostPath
orpersistentVolumeClaim
. -
For exposing Central deployment for external access. You must specify one parameter, either
central.exposure.loadBalancer
,central.exposure.nodePort
, orcentral.exposure.route
. When you do not specify any value for these parameters, you must manually expose Central or access it by using port-forwarding.
Parameter | Description |
---|---|
| The endpoint configuration options for Central. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Central. This parameter is mainly used for infrastructure nodes. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Central. This parameter is mainly used for infrastructure nodes. |
|
Specify |
|
A custom registry that overrides the global |
|
The custom image name that overrides the default Central image name ( |
|
The custom image tag that overrides the default tag for Central image. If you specify you own image tag during a new installation, you must manually increment this tag when you to upgrade to a new version by running the |
|
Full reference including registry address, image name, and image tag for the Central image. Setting a value for this parameter overrides the |
| The memory request for Central to override the default value. |
| The CPU request for Central to override the default value. |
| The memory limit for Central to override the default value. |
| The CPU limit for Central to override the default value. |
| The path on the node where Red Hat Advanced Cluster Security for Kubernetes should create a database volume. Red Hat does not recommend using this option. |
| The name of the persistent volume claim (PVC) you are using. |
|
Use |
| The size (in GiB) of the persistent volume managed by the specified claim. |
|
Use |
| The port number on which to expose Central. The default port number is 443. |
|
Use |
| The port number on which to expose Central. When you skip this parameter, OpenShift Container Platform automatically assigns a port number. Red Hat recommends that you do not specify a port number if you are exposing Red Hat Advanced Cluster Security for Kubernetes by using a node port. |
|
Use |
3.3.2.2.2.6. Scanner
Configurable parameters for Scanner.
Parameter | Description |
---|---|
|
Use |
|
Specify |
|
The number of replicas to create for the Scanner deployment. When you use it with the |
|
Configure the log level for Scanner. Red Hat recommends that you not change the log level’s default value ( |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. This parameter is mainly used for infrastructure nodes. |
|
Use |
| The minimum number of replicas for autoscaling. |
| The maximum number of replicas for autoscaling. |
| The memory request for Scanner to override the default value. |
| The CPU request for Scanner to override the default value. |
| The memory limit for Scanner to override the default value. |
| The CPU limit for Scanner to override the default value. |
| The memory request for Scanner database deployment to override the default values. |
| The CPU request for Scanner database deployment to override the default values. |
| The memory limit for Scanner database deployment to override the default values. |
| The CPU limit for Scanner database deployment to override the default values. |
| A custom registry for the Scanner image. |
|
The custom image name that overrides the default Scanner image name ( |
| A custom registry for the Scanner DB image. |
|
The custom image name that overrides the default Scanner DB image name ( |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. This parameter is mainly used for infrastructure nodes. |
3.3.2.2.2.7. Customization
Use these parameters to specify additional attributes for all objects that Red Hat Advanced Cluster Security for Kubernetes creates.
Parameter | Description |
---|---|
| A custom label to attach to all objects. |
| A custom annotation to attach to all objects. |
| A custom label to attach to all deployments. |
| A custom annotation to attach to all deployments. |
| A custom environment variable for all containers in all objects. |
| A custom label to attach to all objects that Central creates. |
| A custom annotation to attach to all objects that Central creates. |
| A custom label to attach to all Central deployments. |
| A custom annotation to attach to all Central deployments. |
| A custom environment variable for all Central containers. |
| A custom label to attach to all objects that Scanner creates. |
| A custom annotation to attach to all objects that Scanner creates. |
| A custom label to attach to all Scanner deployments. |
| A custom annotation to attach to all Scanner deployments. |
| A custom environment variable for all Scanner containers. |
| A custom label to attach to all objects that Scanner DB creates. |
| A custom annotation to attach to all objects that Scanner DB creates. |
| A custom label to attach to all Scanner DB deployments. |
| A custom annotation to attach to all Scanner DB deployments. |
| A custom environment variable for all Scanner DB containers. |
You can also use:
-
the
customize.other.service/*.labels
and thecustomize.other.service/*.annotations
parameters, to specify labels and annotations for all objects. -
or, provide a specific service name, for example,
customize.other.service/central-loadbalancer.labels
andcustomize.other.service/central-loadbalancer.annotations
as parameters and set their value.
3.3.2.2.2.8. Advanced customization
The parameters specified in this section are for information only. Red Hat does not support Red Hat Advanced Cluster Security for Kubernetes instances with modified namespace and release names.
Parameter | Description |
---|---|
|
Use |
|
Use |
3.3.2.2.3. Installing the central-services Helm chart
After you configure the values-public.yaml
and values-private.yaml
files, install the central-services
Helm chart to deploy the centralized components (Central and Scanner).
Procedure
Run the following command:
$ helm install -n stackrox --create-namespace \ stackrox-central-services rhacs/central-services \ -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.
3.3.2.3. Changing configuration options after deploying the central-services Helm chart
You can make changes to any configuration options after you have deployed the central-services
Helm chart.
Procedure
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. Run the
helm upgrade
command and specify the configuration files using the-f
option:$ helm upgrade -n stackrox \ stackrox-central-services rhacs/central-services \ -f <path_to_values_public.yaml> \ -f <path_to_values_private.yaml>
NoteYou 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.
3.3.3. Install Central using the roxctl CLI
For production environments, Red Hat recommends using the Operator or Helm charts to install RHACS. Do not use the roxctl
install method unless you have a specific installation need that requires using this method.
3.3.3.1. Installing the roxctl CLI
To install Red Hat Advanced Cluster Security for Kubernetes you must install the roxctl
CLI by downloading the binary. You can install roxctl
on Linux, Windows, or macOS.
3.3.3.1.1. Installing the roxctl CLI on Linux
You can install the roxctl
CLI binary on Linux 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/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
3.3.3.1.2. Installing the roxctl CLI on macOS
You can install the roxctl
CLI binary on macOS 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/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
3.3.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
3.3.3.1.4. Using the interactive installer
Use the interactive installer to generate the required secrets, deployment configurations, and deployment scripts for your environment.
Procedure
Run the interactive install command:
$ roxctl central generate interactive
ImportantInstalling Red Hat Advanced Cluster Security for Kubernetes using
roxctl
CLI creates PodSecurityPolicy (PSP) objects by default for backward compatibility. If you install RHACS on Kubernetes versions 1.25 and newer or OpenShift Container Platform version 4.12 and newer, you must disable the PSP object creation. To do this, specify--enable-pod-security-policies
option asfalse
for theroxctl central generate
androxctl sensor generate
commands.Press Enter to accept the default value for a prompt or enter custom values as required.
Enter path to the backup bundle from which to restore keys and certificates (optional): Enter PEM cert bundle file (optional): 1 Enter administrator password (default: autogenerated): Enter orchestrator (k8s, openshift): openshift Enter the directory to output the deployment bundle to (default: "central-bundle"): Enter the OpenShift major version (3 or 4) to deploy on (default: "0"): 4 Enter Istio version when deploying into an Istio-enabled cluster (leave empty when not running Istio) (optional): Enter the method of exposing Central (route, lb, np, none) (default: "none"): route 2 Enter main image to use (default: "stackrox.io/main:3.0.61.1"): Enter whether to run StackRox in offline mode, which avoids reaching out to the Internet (default: "false"): Enter whether to enable telemetry (default: "true"): Enter the deployment tool to use (kubectl, helm, helm-values) (default: "kubectl"): Enter Scanner DB image to use (default: "stackrox.io/scanner-db:2.15.2"): Enter Scanner image to use (default: "stackrox.io/scanner:2.15.2"): Enter Central volume type (hostpath, pvc): pvc 3 Enter external volume name (default: "stackrox-db"): Enter external volume size in Gi (default: "100"): Enter storage class name (optional if you have a default StorageClass configured):
- 1
- If you want to add a custom TLS certificate, provide the file path for the PEM-encoded certificate. When you specify a custom certificate the interactive installer also prompts you to provide a PEM private key for the custom certificate you are using.
- 2
- To use the RHACS portal, you must expose Central by using a route, a load balancer or a node port.
- 3
- If you plan to install Red Hat Advanced Cluster Security for Kubernetes on OpenShift Container Platform with a hostPath volume, you must modify the SELinux policy.
WarningOn OpenShift Container Platform, for using a hostPath volume, you must modify the SELinux policy to allow access to the directory, which the host and the container share. It is because SELinux blocks directory sharing by default. To modify the SELinux policy, run the following command:
$ sudo chcon -Rt svirt_sandbox_file_t <full_volume_path>
However, Red Hat does not recommend modifying the SELinux policy, instead use PVC when installing on OpenShift Container Platform.
On completion, the installer creates a folder named central-bundle, which contains the necessary YAML manifests and scripts to deploy Central. In addition, it shows on-screen instructions for the scripts you need to run to deploy additional trusted certificate authorities, Central and Scanner, and the authentication instructions for logging into the RHACS portal along with the autogenerated password if you did not provide one when answering the prompts.
3.3.3.2. Running the Central installation scripts
After you run the interactive installer, you can run the setup.sh
script to install Central.
Procedure
Run the
setup.sh
script to configure image registry access:$ ./central-bundle/central/scripts/setup.sh
Create the necessary resources:
$ oc create -R -f central-bundle/central
Check the deployment progress:
$ oc get pod -n stackrox -w
After Central is running, find the RHACS portal IP address and open it in your browser. Depending on the exposure method you selected when answering the prompts, use one of the following methods to get the IP address.
Exposure method Command Address Example Route
oc -n stackrox get route central
The address under the
HOST/PORT
column in the outputhttps://central-stackrox.example.route
Node Port
oc get node -owide && oc -n stackrox get svc central-loadbalancer
IP or hostname of any node, on the port shown for the service
https://198.51.100.0:31489
Load Balancer
oc -n stackrox get svc central-loadbalancer
EXTERNAL-IP or hostname shown for the service, on port 443
https://192.0.2.0
None
central-bundle/central/scripts/port-forward.sh 8443
https://localhost:8443
https://localhost:8443
If you have selected autogenerated password during the interactive install, you can run the following command to see it for logging into Central:
$ cat central-bundle/password
3.4. Optional - Configuring Central configuration options for RHACS using the Operator
This topic provides information about optional configuration options that you can configure using the Operator.
3.4.1. Central configuration options using the Operator
When you create a Central instance, the Operator lists the following configuration options for the Central
custom resource.
3.4.1.1. Central settings
Parameter | Description |
---|---|
|
Specify a secret that contains the administrator password in the |
| By default, Central only serves an internal TLS certificate, which means that you need to handle TLS termination at the ingress or load balancer level. If you want to terminate TLS in Central and serve a custom server certificate, you can specify a secret containing the certificate and private key. |
|
Set this parameter to |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Central. This parameter is mainly used for infrastructure nodes. |
|
Set this to |
| Use this parameter to specify a custom port for your load balancer. |
| Use this parameter to specify a static IP address reserved for your load balancer. |
|
Set this to |
| Specify a custom hostname to use for Central’s route. Leave this unset to accept the default value that OpenShift Container Platform provides. |
|
Set this to |
| Use this to specify an explicit node port. |
|
Use |
| If you want this component to only run on specific nodes, you can configure a node selector by using this parameter. |
| Specify a host path to store persistent data in a directory on the host. Red Hat does not recommend using this. If you need to use host path, you must use it with a node selector. |
|
The name of the PVC to manage persistent data. If no PVC with the given name exists, it will be created. The default value is |
| The size of the persistent volume when created through the claim. This is automatically generated by default. |
| The name of the storage class to use for the PVC. If your cluster is not configured with a default storage class, you must provide a value for this parameter. |
| Use this parameter to override the default resource limits for the Central. |
| Use this parameter to override the default resource requests for the Central. |
| Use this parameter to specify the image pull secrets for the Central image. |
3.4.1.2. Scanner settings
Parameter | Description |
---|---|
| If you want this scanner to only run on specific nodes, you can configure a node selector by using this parameter. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. This parameter is mainly used for infrastructure nodes. |
| Use this parameter to override the default resource limits for the scanner. |
| Use this parameter to override the default resource requests for the scanner. |
| When enabled, the number of analyzer replicas is managed dynamically based on the load, within the limits specified. |
| Specifies the maximum replicas to be used the analyzer autoscaling configuration |
| Specifies the minimum replicas to be used the analyzer autoscaling configuration |
| When autoscaling is disabled, the number of replicas will always be configured to match this value. |
| If you want this component to only run on specific nodes, you can configure a node selector by using this parameter. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. This parameter is mainly used for infrastructure nodes. |
| Use this parameter to override the default resource limits for the scanner. |
| Use this parameter to override the default resource requests for the scanner. |
|
Use |
| If you do not want to deploy Scanner, you can disable it by using this parameter. If you disable Scanner, all other settings in this section have no effect. Red Hat does not recommend disabling Red Hat Advanced Cluster Security for Kubernetes Scanner. |
3.4.1.3. General and miscellaneous settings
Parameter | Description |
---|---|
| Additional Trusted CA certificates for the secured cluster to trust. These certificates are typically used when integrating with services using a private certificate authority. |
|
Specify |
| Allows specifying custom annotations for the Central deployment. |
| Advanced settings to configure environment variables. |
| Configures whether RHACS should run in online or offline mode. In offline mode, automatic updates of vulnerability definitions and kernel modules are disabled. |
3.5. Generating and applying an init bundle for RHACS 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.
To configure an init bundle for RHACS Cloud Service, see the following resources:
You must have the Admin user role to create an init bundle.
3.5.1. Generating an init bundle
3.5.1.1. Generating an init bundle by using the RHACS portal
You can create an init bundle containing secrets by using the RHACS portal.
You must have the Admin user role to create an init bundle.
Procedure
Find the address of the RHACS portal based on your exposure method:
For a route:
$ oc get route central -n stackrox
For a load balancer:
$ oc get service central-loadbalancer -n stackrox
For port forward:
Run the following command:
$ oc port-forward svc/central 18443:443 -n stackrox
-
Navigate to
https://localhost:18443/
.
- On the RHACS portal, navigate to Platform Configuration → Integrations.
- Navigate to the Authentication Tokens section and click on Cluster Init Bundle.
- Click Generate bundle.
Enter a name for the cluster init bundle and click Generate.
- If you are installing using Helm charts, click Download Helm Values File to download the generated bundle.
- If you are installing using the Operator, click Download Kubernetes Secret File to download the generated bundle.
Store this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.
Next steps
- Apply the init bundle by creating a resource on the secured cluster.
- Install secured cluster services on each cluster.
3.5.1.2. Generating an init bundle by using the roxctl CLI
You can create an init bundle with secrets by using the roxctl
CLI.
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 theROX_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
ImportantEnsure 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.
3.5.2. 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.
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
Next Step
- Install RHACS secured cluster services in all clusters that you want to monitor.
3.6. Installing secured cluster services for RHACS on Red Hat OpenShift
This section describes the installation procedure for installing Red Hat Advanced Cluster Security for Kubernetes on your secured clusters.
You can install RHACS on your secured clusters by using one of the following methods:
- Install using the Operator
- Install using Helm charts
-
Install using the
roxctl
CLI (do not use this method unless you have a specific installation need that requires using it)
3.6.1. Installing RHACS on secured clusters by using the Operator
3.6.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.
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
- On the OpenShift Container Platform web console, navigate to the Operators → Installed Operators page.
- Click the RHACS Operator.
- Click Secured Cluster from the central navigation menu in the Operator details page.
- Click Create SecuredCluster.
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.
- 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.
- Optional: Add any labels for the cluster.
-
Enter a unique name for your
SecuredCluster
custom resource. 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 ascentral.example.com:443
. The default value ofcentral.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.-
Only if you are installing secured cluster services and Central in the same cluster, use
central.stackrox.svc:443
.
-
Only if you are installing secured cluster services and Central in the same cluster, use
- 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.
- Click Create.
Next step
- Optional: Configure additional secured cluster settings.
- Verify installation.
3.6.2. Installing RHACS 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.
3.6.2.1. Installing RHACS on secured clusters by using Helm charts without customizations
3.6.2.1.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:
Central services Helm chart (
central-services
) for installing the centralized components (Central and Scanner).NoteYou 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 (Sensor and Admission controller) and per-node (Collector) components.NoteDeploy 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/
3.6.2.1.2. 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).
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 address and the port number that you are exposing the Central service on.
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
Run the following command on OpenShift Container Platform 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 scanner.disable=false
Additional resources
3.6.2.2. Configuring the secured-cluster-services Helm chart with customizations
This section describes Helm chart configuration parameters that you can use with the helm install
and helm upgrade
commands. You can 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.
While using the secured-cluster-services
Helm chart, do not modify the values.yaml
file that is part of the chart.
3.6.2.2.1. Configuration parameters
Parameter | Description |
---|---|
| Name of your cluster. |
|
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 |
| Address of the Sensor endpoint including port number. |
| Image pull policy for the Sensor container. |
| The internal service-to-service TLS certificate that Sensor uses. |
| The internal service-to-service TLS certificate key that Sensor uses. |
| The memory request for the Sensor container. Use this parameter to override the default value. |
| The CPU request for the Sensor container. Use this parameter to override the default value. |
| The memory limit for the Sensor container. Use this parameter to override the default value. |
| The CPU limit for the Sensor container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
|
The name of the |
| The name of the Collector image. |
| Address of the registry you are using for the main image. |
| Address of the registry you are using for the Collector image. |
|
Image pull policy for |
| Image pull policy for the Collector images. |
|
Tag of |
|
Tag of |
|
Either |
| Image pull policy for the Collector container. |
| Image pull policy for the Compliance container. |
|
If you specify |
| The memory request for the Collector container. Use this parameter to override the default value. |
| The CPU request for the Collector container. Use this parameter to override the default value. |
| The memory limit for the Collector container. Use this parameter to override the default value. |
| The CPU limit for the Collector container. Use this parameter to override the default value. |
| The memory request for the Compliance container. Use this parameter to override the default value. |
| The CPU request for the Compliance container. Use this parameter to override the default value. |
| The memory limit for the Compliance container. Use this parameter to override the default value. |
| The CPU limit for the Compliance container. Use this parameter to override the default value. |
| The internal service-to-service TLS certificate that Collector uses. |
| The internal service-to-service TLS certificate key that Collector uses. |
|
This setting controls whether Kubernetes is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
|
When you set this parameter as |
|
This setting controls whether the cluster is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
| This setting controls whether Red Hat Advanced Cluster Security for Kubernetes evaluates policies; if it is disabled, all AdmissionReview requests are automatically accepted. |
|
This setting controls the behavior of the admission control service. You must specify |
|
If you set this option to |
|
Set it to |
| 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. |
| The memory request for the Admission Control container. Use this parameter to override the default value. |
| The CPU request for the Admission Control container. Use this parameter to override the default value. |
| The memory limit for the Admission Control container. Use this parameter to override the default value. |
| The CPU limit for the Admission Control container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
| The internal service-to-service TLS certificate that Admission Control uses. |
| The internal service-to-service TLS certificate key that Admission Control uses. |
|
Use this parameter to override the default |
|
If you specify |
|
Specify |
|
Specify |
|
Specify |
| Resource specification for Sensor. |
| Resource specification for Admission controller. |
| Resource specification for Collector. |
| Resource specification for Collector’s Compliance container. |
|
If you set this option to |
|
If you set this option to |
|
If you set this option to |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| Resource specification for Collector’s Compliance container. |
| Setting this parameter allows you to modify the scanner log level. Use this option only for troubleshooting purposes. |
|
If you set this option to |
| The minimum number of replicas for autoscaling. Defaults to 2. |
| The maximum number of replicas for autoscaling. Defaults to 5. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| The memory request for the Scanner container. Use this parameter to override the default value. |
| The CPU request for the Scanner container. Use this parameter to override the default value. |
| The memory limit for the Scanner container. Use this parameter to override the default value. |
| The CPU limit for the Scanner container. Use this parameter to override the default value. |
| The memory request for the Scanner DB container. Use this parameter to override the default value. |
| The CPU request for the Scanner DB container. Use this parameter to override the default value. |
| The memory limit for the Scanner DB container. Use this parameter to override the default value. |
| The CPU limit for the Scanner DB container. Use this parameter to override the default value. |
3.6.2.2.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).
3.6.2.2.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).
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 address and the port number that you are exposing the Central service on.
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.
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
3.6.2.3. 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
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. 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.
NoteYou 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.
3.6.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:
-
Install the
roxctl
CLI - Install Sensor.
3.6.3.1. Installing the roxctl CLI
You must first download the binary. You can install roxctl
on Linux, Windows, or macOS.
3.6.3.1.1. Installing the roxctl CLI on Linux
You can install the roxctl
CLI binary on Linux 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/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
3.6.3.1.2. Installing the roxctl CLI on macOS
You can install the roxctl
CLI binary on macOS 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/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
3.6.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
3.6.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
- On the RHACS portal, navigate to Platform Configuration → Clusters.
- Select + New Cluster.
- Specify a name for the cluster.
Provide appropriate values for the fields based on where you are deploying the Sensor.
- If you are deploying Sensor in the same cluster, accept the default values for all the fields.
-
If you are deploying into a different cluster, replace
central.stackrox.svc:443
with a load balancer, node port, or other address, including the port number, that is accessible from the other cluster. If you are using a non-gRPC capable load balancer, such as HAProxy, AWS Application Load Balancer (ALB), or AWS Elastic Load Balancing (ELB), use the WebSocket Secure (
wss
) protocol. To usewss
:-
Prefix the address with
wss://
. -
Add the port number after the address, for example,
wss://stackrox-central.example.com:443
.
-
Prefix the address with
- Click Next to continue with the Sensor setup.
Click Download YAML File and Keys to download the cluster bundle (zip archive).
ImportantThe cluster bundle zip archive includes unique configurations and keys for each cluster. Do not reuse the same files in another cluster.
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
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:
$ oc get pod -n stackrox -w
On Kubernetes:
$ kubectl get pod -n stackrox -w
- 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.
3.7. Verifying installation of RHACS on Red Hat OpenShift
Provides steps to verify that RHACS is properly installed.
3.7.1. Verifying installation
After you complete the installation, run a few vulnerable applications and navigate to the RHACS portal to evaluate the results of security assessments and policy violations.
The sample applications listed in the following section contain critical vulnerabilities and they are specifically designed to verify the build and deploy-time assessment features of Red Hat Advanced Cluster Security for Kubernetes.
To verify installation:
Find the address of the RHACS portal based on your exposure method:
For a route:
$ oc get route central -n stackrox
For a load balancer:
$ oc get service central-loadbalancer -n stackrox
For port forward:
Run the following command:
$ oc port-forward svc/central 18443:443 -n stackrox
-
Navigate to
https://localhost:18443/
.
Using the Red Hat OpenShift CLI, create a new project:
$ oc new-project test
Start some applications with critical vulnerabilities:
$ oc run shell --labels=app=shellshock,team=test-team \ --image=vulnerables/cve-2014-6271 -n test $ oc run samba --labels=app=rce \ --image=vulnerables/cve-2017-7494 -n test
Red Hat Advanced Cluster Security for Kubernetes automatically scans these deployments for security risk and policy violations as soon as they are submitted to the cluster. Navigate to the RHACS portal to view the violations. You can log in to the RHACS portal by using the default username admin and the generated password.
Chapter 4. Installing RHACS on other platforms
4.1. High-level overview of installing RHACS on other platforms
Red Hat Advanced Cluster Security for Kubernetes (RHACS) provides security services for self-managed RHACS on platforms such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (Google GKE), and Microsoft Azure Kubernetes Service (Microsoft AKS).
Before you install:
- Understand the installation platforms and methods.
- Understand Red Hat Advanced Cluster Security for Kubernetes architecture.
- Review the prerequisites.
The following list provides a high-level overview of installation steps:
-
Install Central services on a cluster using Helm charts or the
roxctl
CLI. - Generate and apply an init bundle.
- Install secured cluster resources on each of your secured clusters.
4.2. Prerequisites for RHACS on other platforms
Before installing RHACS on other platforms such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (Google GKE), and Microsoft Azure Kubernetes Service (Microsoft AKS), ensure that you have met the prerequisites.
4.2.1. General requirements
RHACS has some system requirements that must be met before installing.
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.
NoteFor 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.
NoteYou 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).
ImportantYou 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.
4.2.2. Prerequisites for installing Central
A single containerized service called Central handles data persistence, API interactions, and user interface (Portal) access.
Central requires persistent storage:
You can provide storage with a persistent volume claim (PVC).
NoteYou can use a hostPath volume for storage only if all your hosts (or a group of hosts) mount a shared file system, such as an NFS share or a storage appliance. Otherwise, your data is only saved on a single node. Red Hat does not recommend using a hostPath volume.
- Use Solid-State Drives (SSD) for best performance. However, you can use another storage type if you do not have SSDs available.
If you use a web proxy or firewall, you must configure bypass rules to allow traffic for the
definitions.stackrox.io
andcollector-modules.stackrox.io
domains and enable Red Hat Advanced Cluster Security for Kubernetes to trust your web proxy or firewall. Otherwise, updates for vulnerability definitions and kernel support packages will fail.Red Hat Advanced Cluster Security for Kubernetes requires access to:
-
definitions.stackrox.io
for downloading updated vulnerability definitions. Vulnerability definition updates allow Red Hat Advanced Cluster Security for Kubernetes to maintain up-to-date vulnerability data when new vulnerabilities are discovered or additional data sources are added. -
collector-modules.stackrox.io
to download updated kernel support packages. Updated Kernel support packages ensure that Red Hat Advanced Cluster Security for Kubernetes can monitor the latest operating systems and collect data about the network traffic and processes running inside the containers. Without these updates, Red Hat Advanced Cluster Security for Kubernetes might fail to monitor containers if you add new nodes in your cluster or if you update your nodes' operating system.
-
For security reasons, you should deploy Central in a cluster with limited administrative access.
Memory and storage requirements
The following table lists the minimum memory and storage values required to install and run Central.
Central | CPU | Memory | Storage |
---|---|---|---|
Request | 1.5 cores | 4 GiB | 100 GiB |
Limit | 4 cores | 8 GiB | 100 GiB |
Sizing guidelines
Use the following compute resources and storage values depending upon the number of nodes in your cluster.
Nodes | Deployments | CPU | Memory | Storage |
---|---|---|---|---|
Up to 100 | Up to 1000 | 2 cores | 4 GiB | 100 GiB |
Up to 500 | Up to 2000 | 4 cores | 8 GiB | 100 GiB |
More than 500 | More than 2000 | 8 cores | 12 - 16 GiB | 100 - 200 GiB |
4.2.3. 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
Scanner | CPU | Memory |
---|---|---|
Request | 1.2 cores | 2700 MiB |
Limit | 5 cores | 8000 MiB |
4.2.4. 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
Sensor | CPU | Memory |
---|---|---|
Request | 1 core | 1 GiB |
Limit | 2 cores | 4 GiB |
4.2.5. 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 controller | CPU | Memory |
---|---|---|
Request | .05 cores | 100 MiB |
Limit | .5 cores | 500 MiB |
4.2.6. Prerequisites for installing Collector
Collector monitors runtime activity on each node in your secured clusters. It connects to Sensor to report this information.
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
Collector | CPU | Memory |
---|---|---|
Request | .05 cores | 320 MiB |
Limit | .75 cores | 1 GiB |
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.
4.3. Installing Central services for RHACS on other platforms
Central is the resource that contains the RHACS application management interface and services. It handles data persistence, API interactions, and RHACS portal access. You can use the same Central instance to secure multiple OpenShift Container Platform or Kubernetes clusters.
You can install Central by using one of the following methods:
- Install using Helm charts
-
Install using the
roxctl
CLI (do not use this method unless you have a specific installation need that requires using it)
4.3.1. Install Central using Helm charts
You can install Central using Helm charts without any customization, using the default values, or by using Helm charts with additional customizations of configuration parameters.
4.3.1.1. Install Central using Helm charts without customization
You can install RHACS on your Red Hat OpenShift cluster without any customizations. You must add the Helm chart repository and install the central-services
Helm chart to install the centralized components of Central and Scanner.
4.3.1.1.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:
Central services Helm chart (
central-services
) for installing the centralized components (Central and Scanner).NoteYou 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 (Sensor and Admission controller) and per-node (Collector) components.NoteDeploy 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/
4.3.1.1.2. Installing the central-services Helm chart without customizations
Use the following instructions to install the central-services
Helm chart to deploy the centralized components (Central and Scanner).
Prerequisites
-
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.
Procedure
Run the following command to install Central services and expose Central using a route:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password> \ --set central.exposure.route.enabled=true
Or, run the following command to install Central services and expose Central using a load balancer:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password> \ --set central.exposure.loadBalancer.enabled=true
Or, run the following command to install Central services and expose Central using port forward:
$ helm install -n stackrox \ --create-namespace stackrox-central-services rhacs/central-services \ --set imagePullSecrets.username=<username> \ --set imagePullSecrets.password=<password>
If you are installing Red Hat Advanced Cluster Security for Kubernetes in a cluster that requires a proxy to connect to external services, you must specify your proxy configuration by using the
proxyConfig
parameter. For example:env: proxyConfig: | url: http://proxy.name:port username: username password: password excludes: - some.domain
-
If you already created one or more image pull secrets in the namespace in which you are installing, instead of using a username and password, you can use
--set imagePullSecrets.useExisting="<pull-secret-1;pull-secret-2>"
. Do not use image pull secrets:
-
If you are pulling your images from
quay.io/stackrox-io
or a registry in a private network that does not require authentication. Use use--set imagePullSecrets.allowNone=true
instead of specifying a username and password. -
If you already configured image pull secrets in the default service account in the namespace you are installing. Use
--set imagePullSecrets.useFromDefaultServiceAccount=true
instead of specifying a username and password.
-
If you are pulling your images from
The output of the installation command includes:
- An automatically generated administrator password.
- Instructions on storing all the configuration values.
- Any warnings that Helm generates.
4.3.1.2. Install Central using Helm charts with customizations
You can install RHACS on your Red Hat OpenShift cluster with customizations by using Helm chart configuration parameters with the helm install
and helm upgrade
commands. You can 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.
4.3.1.2.1. Private configuration file
This section lists the configurable parameters of the values-private.yaml
file. There are no default values for these parameters.
4.3.1.2.1.1. Image pull secrets
The credentials that are required for pulling images from the registry depend on the following factors:
If you are using a custom registry, you must specify these parameters:
-
imagePullSecrets.username
-
imagePullSecrets.password
-
image.registry
-
If you do not use a username and password to log in to the custom registry, you must specify one of the following parameters:
-
imagePullSecrets.allowNone
-
imagePullSecrets.useExisting
-
imagePullSecrets.useFromDefaultServiceAccount
-
Parameter | Description |
---|---|
| The username of the account that is used to log in to the registry. |
| The password of the account that is used to log in to the registry. |
|
Use |
|
A comma-separated list of secrets as values. For example, |
|
Use |
4.3.1.2.1.2. Proxy configuration
If you are installing Red Hat Advanced Cluster Security for Kubernetes in a cluster that requires a proxy to connect to external services, you must specify your proxy configuration by using the proxyConfig
parameter. For example:
env: proxyConfig: | url: http://proxy.name:port username: username password: password excludes: - some.domain
Parameter | Description |
---|---|
| Your proxy configuration. |
4.3.1.2.1.3. Central
Configurable parameters for Central.
For a new installation, you can skip the following parameters:
-
central.jwtSigner.key
-
central.serviceTLS.cert
-
central.serviceTLS.key
-
central.adminPassword.value
-
central.adminPassword.htpasswd
- When you do not specify values for these parameters the Helm chart autogenerates values for them.
-
If you want to modify these values you can use the
helm upgrade
command and specify the values using the--set
option.
For setting the administrator password, you can only use either central.adminPassword.value
or central.adminPassword.htpasswd
, but not both.
Parameter | Description |
---|---|
| A private key which Red Hat Advanced Cluster Security for Kubernetes should use for signing JSON web tokens (JWTs) for authentication. |
| An internal certificate that the Central service should use for deploying Central. |
| The private key of the internal certificate that the Central service should use. |
| The user-facing certificate that Central should use. Red Hat Advanced Cluster Security for Kubernetes uses this certificate for RHACS portal.
|
| The private key of the user-facing certificate that Central should use.
|
| Administrator password for logging into Red Hat Advanced Cluster Security for Kubernetes. |
| Administrator password for logging into Red Hat Advanced Cluster Security for Kubernetes. This password is stored in hashed format using bcrypt. |
If you are using central.adminPassword.htpasswd
parameter, you must use a bcrypt encoded password hash. You can run the command htpasswd -nB admin
to generate a password hash. For example,
htpasswd: | admin:<bcrypt-hash>
4.3.1.2.1.4. Scanner
Configurable parameters for Scanner.
For a new installation, you can skip the following parameters and the Helm chart autogenerates values for them. Otherwise, if you are upgrading to a new version, specify the values for the following parameters:
-
scanner.dbPassword.value
-
scanner.serviceTLS.cert
-
scanner.serviceTLS.key
-
scanner.dbServiceTLS.cert
-
scanner.dbServiceTLS.key
Parameter | Description |
---|---|
| The password to use for authentication with Scanner database. Do not modify this parameter because Red Hat Advanced Cluster Security for Kubernetes automatically creates and uses its value internally. |
| An internal certificate that the Scanner service should use for deploying Scanner. |
| The private key of the internal certificate that the Scanner service should use. |
| An internal certificate that the Scanner-db service should use for deploying Scanner database. |
| The private key of the internal certificate that the Scanner-db service should use. |
4.3.1.2.2. Public configuration file
This section lists the configurable parameters of the values-public.yaml
file.
4.3.1.2.2.1. Image pull secrets
Image pull secrets are the credentials required for pulling images from your registry.
Parameter | Description |
---|---|
|
Use |
|
A comma-seprated list of secrets as values. For example, |
|
Use |
4.3.1.2.2.2. Image
Image declares the configuration to set up the main registry, which the Helm chart uses to resolve images for the central.image
, scanner.image
, and scanner.dbImage
parameters.
Parameter | Description |
---|---|
|
Address of your image registry. Either use a hostname, such as |
4.3.1.2.2.3. Environment variables
Red Hat Advanced Cluster Security for Kubernetes automatically detects your cluster environment and sets values for env.openshift
, env.istio
, and env.platform
. Only set these values to override the automatic cluster environment detection.
Parameter | Description |
---|---|
|
Use |
|
Use |
|
The platform on which you are installing Red Hat Advanced Cluster Security for Kubernetes. Set its value to |
|
Use |
4.3.1.2.2.4. Additional trusted certificate authorities
The Red Hat Advanced Cluster Security for Kubernetes automatically references the system root certificates to trust. When Central or Scanner must reach out to services that use certificates issued by an authority in your organization or a globally trusted partner organization, you can add trust for these services by specifying the root certificate authority to trust by using the following parameter:
Parameter | Description |
---|---|
| Specify the PEM encoded certificate of the root certificate authority to trust. |
4.3.1.2.2.5. Central
Configurable parameters for Central.
-
You must specify a persistent storage option as either
hostPath
orpersistentVolumeClaim
. -
For exposing Central deployment for external access. You must specify one parameter, either
central.exposure.loadBalancer
,central.exposure.nodePort
, orcentral.exposure.route
. When you do not specify any value for these parameters, you must manually expose Central or access it by using port-forwarding.
Parameter | Description |
---|---|
| The endpoint configuration options for Central. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Central. This parameter is mainly used for infrastructure nodes. |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Central. This parameter is mainly used for infrastructure nodes. |
|
Specify |
|
A custom registry that overrides the global |
|
The custom image name that overrides the default Central image name ( |
|
The custom image tag that overrides the default tag for Central image. If you specify you own image tag during a new installation, you must manually increment this tag when you to upgrade to a new version by running the |
|
Full reference including registry address, image name, and image tag for the Central image. Setting a value for this parameter overrides the |
| The memory request for Central to override the default value. |
| The CPU request for Central to override the default value. |
| The memory limit for Central to override the default value. |
| The CPU limit for Central to override the default value. |
| The path on the node where Red Hat Advanced Cluster Security for Kubernetes should create a database volume. Red Hat does not recommend using this option. |
| The name of the persistent volume claim (PVC) you are using. |
|
Use |
| The size (in GiB) of the persistent volume managed by the specified claim. |
|
Use |
| The port number on which to expose Central. The default port number is 443. |
|
Use |
| The port number on which to expose Central. When you skip this parameter, OpenShift Container Platform automatically assigns a port number. Red Hat recommends that you do not specify a port number if you are exposing Red Hat Advanced Cluster Security for Kubernetes by using a node port. |
|
Use |
4.3.1.2.2.6. Scanner
Configurable parameters for Scanner.
Parameter | Description |
---|---|
|
Use |
|
Specify |
|
The number of replicas to create for the Scanner deployment. When you use it with the |
|
Configure the log level for Scanner. Red Hat recommends that you not change the log level’s default value ( |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. This parameter is mainly used for infrastructure nodes. |
|
Use |
| The minimum number of replicas for autoscaling. |
| The maximum number of replicas for autoscaling. |
| The memory request for Scanner to override the default value. |
| The CPU request for Scanner to override the default value. |
| The memory limit for Scanner to override the default value. |
| The CPU limit for Scanner to override the default value. |
| The memory request for Scanner database deployment to override the default values. |
| The CPU request for Scanner database deployment to override the default values. |
| The memory limit for Scanner database deployment to override the default values. |
| The CPU limit for Scanner database deployment to override the default values. |
| A custom registry for the Scanner image. |
|
The custom image name that overrides the default Scanner image name ( |
| A custom registry for the Scanner DB image. |
|
The custom image name that overrides the default Scanner DB image name ( |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. This parameter is mainly used for infrastructure nodes. |
4.3.1.2.2.7. Customization
Use these parameters to specify additional attributes for all objects that Red Hat Advanced Cluster Security for Kubernetes creates.
Parameter | Description |
---|---|
| A custom label to attach to all objects. |
| A custom annotation to attach to all objects. |
| A custom label to attach to all deployments. |
| A custom annotation to attach to all deployments. |
| A custom environment variable for all containers in all objects. |
| A custom label to attach to all objects that Central creates. |
| A custom annotation to attach to all objects that Central creates. |
| A custom label to attach to all Central deployments. |
| A custom annotation to attach to all Central deployments. |
| A custom environment variable for all Central containers. |
| A custom label to attach to all objects that Scanner creates. |
| A custom annotation to attach to all objects that Scanner creates. |
| A custom label to attach to all Scanner deployments. |
| A custom annotation to attach to all Scanner deployments. |
| A custom environment variable for all Scanner containers. |
| A custom label to attach to all objects that Scanner DB creates. |
| A custom annotation to attach to all objects that Scanner DB creates. |
| A custom label to attach to all Scanner DB deployments. |
| A custom annotation to attach to all Scanner DB deployments. |
| A custom environment variable for all Scanner DB containers. |
You can also use:
-
the
customize.other.service/*.labels
and thecustomize.other.service/*.annotations
parameters, to specify labels and annotations for all objects. -
or, provide a specific service name, for example,
customize.other.service/central-loadbalancer.labels
andcustomize.other.service/central-loadbalancer.annotations
as parameters and set their value.
4.3.1.2.2.8. Advanced customization
The parameters specified in this section are for information only. Red Hat does not support Red Hat Advanced Cluster Security for Kubernetes instances with modified namespace and release names.
Parameter | Description |
---|---|
|
Use |
|
Use |
4.3.1.2.3. Installing the central-services Helm chart
After you configure the values-public.yaml
and values-private.yaml
files, install the central-services
Helm chart to deploy the centralized components (Central and Scanner).
Procedure
Run the following command:
$ helm install -n stackrox --create-namespace \ stackrox-central-services rhacs/central-services \ -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.
4.3.1.3. Changing configuration options after deploying the central-services Helm chart
You can make changes to any configuration options after you have deployed the central-services
Helm chart.
Procedure
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. Run the
helm upgrade
command and specify the configuration files using the-f
option:$ helm upgrade -n stackrox \ stackrox-central-services rhacs/central-services \ -f <path_to_values_public.yaml> \ -f <path_to_values_private.yaml>
NoteYou 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.
4.3.2. Install Central using the roxctl CLI
For production environments, Red Hat recommends using the Operator or Helm charts to install RHACS. Do not use the roxctl
install method unless you have a specific installation need that requires using this method.
4.3.2.1. Installing the roxctl CLI
To install Red Hat Advanced Cluster Security for Kubernetes you must install the roxctl
CLI by downloading the binary. You can install roxctl
on Linux, Windows, or macOS.
4.3.2.1.1. Installing the roxctl CLI on Linux
You can install the roxctl
CLI binary on Linux 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/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
4.3.2.1.2. Installing the roxctl CLI on macOS
You can install the roxctl
CLI binary on macOS 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/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
4.3.2.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
4.3.2.1.4. Using the interactive installer
Use the interactive installer to generate the required secrets, deployment configurations, and deployment scripts for your environment.
Procedure
Run the interactive install command:
$ roxctl central generate interactive
ImportantInstalling Red Hat Advanced Cluster Security for Kubernetes using
roxctl
CLI creates PodSecurityPolicy (PSP) objects by default for backward compatibility. If you install RHACS on Kubernetes versions 1.25 and newer or OpenShift Container Platform version 4.12 and newer, you must disable the PSP object creation. To do this, specify--enable-pod-security-policies
option asfalse
for theroxctl central generate
androxctl sensor generate
commands.Press Enter to accept the default value for a prompt or enter custom values as required.
Enter path to the backup bundle from which to restore keys and certificates (optional): Enter PEM cert bundle file (optional): 1 Enter administrator password (default: autogenerated): Enter orchestrator (k8s, openshift): openshift Enter the directory to output the deployment bundle to (default: "central-bundle"): Enter the OpenShift major version (3 or 4) to deploy on (default: "0"): 4 Enter Istio version when deploying into an Istio-enabled cluster (leave empty when not running Istio) (optional): Enter the method of exposing Central (route, lb, np, none) (default: "none"): route 2 Enter main image to use (default: "stackrox.io/main:3.0.61.1"): Enter whether to run StackRox in offline mode, which avoids reaching out to the Internet (default: "false"): Enter whether to enable telemetry (default: "true"): Enter the deployment tool to use (kubectl, helm, helm-values) (default: "kubectl"): Enter Scanner DB image to use (default: "stackrox.io/scanner-db:2.15.2"): Enter Scanner image to use (default: "stackrox.io/scanner:2.15.2"): Enter Central volume type (hostpath, pvc): pvc 3 Enter external volume name (default: "stackrox-db"): Enter external volume size in Gi (default: "100"): Enter storage class name (optional if you have a default StorageClass configured):
- 1
- If you want to add a custom TLS certificate, provide the file path for the PEM-encoded certificate. When you specify a custom certificate the interactive installer also prompts you to provide a PEM private key for the custom certificate you are using.
- 2
- To use the RHACS portal, you must expose Central by using a route, a load balancer or a node port.
- 3
- If you plan to install Red Hat Advanced Cluster Security for Kubernetes on OpenShift Container Platform with a hostPath volume, you must modify the SELinux policy.
WarningOn OpenShift Container Platform, for using a hostPath volume, you must modify the SELinux policy to allow access to the directory, which the host and the container share. It is because SELinux blocks directory sharing by default. To modify the SELinux policy, run the following command:
$ sudo chcon -Rt svirt_sandbox_file_t <full_volume_path>
However, Red Hat does not recommend modifying the SELinux policy, instead use PVC when installing on OpenShift Container Platform.
On completion, the installer creates a folder named central-bundle, which contains the necessary YAML manifests and scripts to deploy Central. In addition, it shows on-screen instructions for the scripts you need to run to deploy additional trusted certificate authorities, Central and Scanner, and the authentication instructions for logging into the RHACS portal along with the autogenerated password if you did not provide one when answering the prompts.
4.3.2.2. Running the Central installation scripts
After you run the interactive installer, you can run the setup.sh
script to install Central.
Procedure
Run the
setup.sh
script to configure image registry access:$ ./central-bundle/central/scripts/setup.sh
Create the necessary resources:
$ oc create -R -f central-bundle/central
Check the deployment progress:
$ oc get pod -n stackrox -w
After Central is running, find the RHACS portal IP address and open it in your browser. Depending on the exposure method you selected when answering the prompts, use one of the following methods to get the IP address.
Exposure method Command Address Example Route
oc -n stackrox get route central
The address under the
HOST/PORT
column in the outputhttps://central-stackrox.example.route
Node Port
oc get node -owide && oc -n stackrox get svc central-loadbalancer
IP or hostname of any node, on the port shown for the service
https://198.51.100.0:31489
Load Balancer
oc -n stackrox get svc central-loadbalancer
EXTERNAL-IP or hostname shown for the service, on port 443
https://192.0.2.0
None
central-bundle/central/scripts/port-forward.sh 8443
https://localhost:8443
https://localhost:8443
If you have selected autogenerated password during the interactive install, you can run the following command to see it for logging into Central:
$ cat central-bundle/password
4.4. Generating and applying an init bundle for RHACS on other platforms
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.
You must have the Admin user role to create an init bundle.
4.4.1. Generating an init bundle
4.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.
You must have the Admin user role to create an init bundle.
Procedure
Find the address of the RHACS portal based on your exposure method:
For a route:
$ oc get route central -n stackrox
For a load balancer:
$ oc get service central-loadbalancer -n stackrox
For port forward:
Run the following command:
$ oc port-forward svc/central 18443:443 -n stackrox
-
Navigate to
https://localhost:18443/
.
- On the RHACS portal, navigate to Platform Configuration → Integrations.
- Navigate to the Authentication Tokens section and click on Cluster Init Bundle.
- Click Generate bundle.
Enter a name for the cluster init bundle and click Generate.
- If you are installing using Helm charts, click Download Helm Values File to download the generated bundle.
- If you are installing using the Operator, click Download Kubernetes Secret File to download the generated bundle.
Store this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.
Next steps
- Apply the init bundle by creating a resource on the secured cluster.
- Install secured cluster services on each cluster.
4.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.
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 theROX_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
ImportantEnsure 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.
4.4.2. 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.
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
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
Next Step
- Install RHACS secured cluster services in all clusters that you want to monitor.
4.5. Installing secured cluster services for RHACS on other platforms
You can install Red Hat Advanced Cluster Security Cloud Service on your secured clusters for platforms such as Amazon Elastic Kubernetes Service (Amazon EKS), Google Kubernetes Engine (Google GKE), and Microsoft Azure Kubernetes Service (Microsoft AKS).
4.5.1. Installing RHACS 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.
4.5.1.1. Installing RHACS on secured clusters by using Helm charts without customizations
4.5.1.1.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:
Central services Helm chart (
central-services
) for installing the centralized components (Central and Scanner).NoteYou 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 (Sensor and Admission controller) and per-node (Collector) components.NoteDeploy 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/
4.5.1.1.2. 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).
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 address and the port number that you are exposing the Central service on.
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
Run the following command on OpenShift Container Platform 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 scanner.disable=false
Additional resources
4.5.1.2. Configuring the secured-cluster-services Helm chart with customizations
This section describes Helm chart configuration parameters that you can use with the helm install
and helm upgrade
commands. You can 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.
While using the secured-cluster-services
Helm chart, do not modify the values.yaml
file that is part of the chart.
4.5.1.2.1. Configuration parameters
Parameter | Description |
---|---|
| Name of your cluster. |
|
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 |
| Address of the Sensor endpoint including port number. |
| Image pull policy for the Sensor container. |
| The internal service-to-service TLS certificate that Sensor uses. |
| The internal service-to-service TLS certificate key that Sensor uses. |
| The memory request for the Sensor container. Use this parameter to override the default value. |
| The CPU request for the Sensor container. Use this parameter to override the default value. |
| The memory limit for the Sensor container. Use this parameter to override the default value. |
| The CPU limit for the Sensor container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
|
The name of the |
| The name of the Collector image. |
| Address of the registry you are using for the main image. |
| Address of the registry you are using for the Collector image. |
|
Image pull policy for |
| Image pull policy for the Collector images. |
|
Tag of |
|
Tag of |
|
Either |
| Image pull policy for the Collector container. |
| Image pull policy for the Compliance container. |
|
If you specify |
| The memory request for the Collector container. Use this parameter to override the default value. |
| The CPU request for the Collector container. Use this parameter to override the default value. |
| The memory limit for the Collector container. Use this parameter to override the default value. |
| The CPU limit for the Collector container. Use this parameter to override the default value. |
| The memory request for the Compliance container. Use this parameter to override the default value. |
| The CPU request for the Compliance container. Use this parameter to override the default value. |
| The memory limit for the Compliance container. Use this parameter to override the default value. |
| The CPU limit for the Compliance container. Use this parameter to override the default value. |
| The internal service-to-service TLS certificate that Collector uses. |
| The internal service-to-service TLS certificate key that Collector uses. |
|
This setting controls whether Kubernetes is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
|
When you set this parameter as |
|
This setting controls whether the cluster is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
| This setting controls whether Red Hat Advanced Cluster Security for Kubernetes evaluates policies; if it is disabled, all AdmissionReview requests are automatically accepted. |
|
This setting controls the behavior of the admission control service. You must specify |
|
If you set this option to |
|
Set it to |
| 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. |
| The memory request for the Admission Control container. Use this parameter to override the default value. |
| The CPU request for the Admission Control container. Use this parameter to override the default value. |
| The memory limit for the Admission Control container. Use this parameter to override the default value. |
| The CPU limit for the Admission Control container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
| The internal service-to-service TLS certificate that Admission Control uses. |
| The internal service-to-service TLS certificate key that Admission Control uses. |
|
Use this parameter to override the default |
|
If you specify |
|
Specify |
|
Specify |
|
Specify |
| Resource specification for Sensor. |
| Resource specification for Admission controller. |
| Resource specification for Collector. |
| Resource specification for Collector’s Compliance container. |
|
If you set this option to |
|
If you set this option to |
|
If you set this option to |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| Resource specification for Collector’s Compliance container. |
| Setting this parameter allows you to modify the scanner log level. Use this option only for troubleshooting purposes. |
|
If you set this option to |
| The minimum number of replicas for autoscaling. Defaults to 2. |
| The maximum number of replicas for autoscaling. Defaults to 5. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| The memory request for the Scanner container. Use this parameter to override the default value. |
| The CPU request for the Scanner container. Use this parameter to override the default value. |
| The memory limit for the Scanner container. Use this parameter to override the default value. |
| The CPU limit for the Scanner container. Use this parameter to override the default value. |
| The memory request for the Scanner DB container. Use this parameter to override the default value. |
| The CPU request for the Scanner DB container. Use this parameter to override the default value. |
| The memory limit for the Scanner DB container. Use this parameter to override the default value. |
| The CPU limit for the Scanner DB container. Use this parameter to override the default value. |
4.5.1.2.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).
4.5.1.2.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).
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 address and the port number that you are exposing the Central service on.
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.
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
4.5.1.3. 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
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. 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.
NoteYou 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.
4.5.2. Installing RHACS on secured clusters by using the roxctl CLI
To install RHACS on secured clusters by using the CLI, perform the following steps:
-
Install the
roxctl
CLI - Install Sensor.
4.5.2.1. Installing the roxctl CLI
You must first download the binary. You can install roxctl
on Linux, Windows, or macOS.
4.5.2.1.1. Installing the roxctl CLI on Linux
You can install the roxctl
CLI binary on Linux 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/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
4.5.2.1.2. Installing the roxctl CLI on macOS
You can install the roxctl
CLI binary on macOS 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/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
4.5.2.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
4.5.2.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
- On the RHACS portal, navigate to Platform Configuration → Clusters.
- Select + New Cluster.
- Specify a name for the cluster.
Provide appropriate values for the fields based on where you are deploying the Sensor.
- If you are deploying Sensor in the same cluster, accept the default values for all the fields.
-
If you are deploying into a different cluster, replace
central.stackrox.svc:443
with a load balancer, node port, or other address, including the port number, that is accessible from the other cluster. If you are using a non-gRPC capable load balancer, such as HAProxy, AWS Application Load Balancer (ALB), or AWS Elastic Load Balancing (ELB), use the WebSocket Secure (
wss
) protocol. To usewss
:-
Prefix the address with
wss://
. -
Add the port number after the address, for example,
wss://stackrox-central.example.com:443
.
-
Prefix the address with
- Click Next to continue with the Sensor setup.
Click Download YAML File and Keys to download the cluster bundle (zip archive).
ImportantThe cluster bundle zip archive includes unique configurations and keys for each cluster. Do not reuse the same files in another cluster.
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
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
- 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.
4.6. Verifying installation of RHACS on other platforms
After installing RHACS Cloud Service, you can perform some steps to verify that the installation was successful.
RHACS Cloud Service is available as a Field Trial release. A Field Trial provides approved customers access to Red Hat Advanced Cluster Security Cloud Service for trial purposes. For more information, contact Red Hat Sales.
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 there is no data 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.
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
- Understand the installation platforms and methods.
- Understand Red Hat Advanced Cluster Security for Kubernetes architecture.
- Review the prerequisites.
To set up RHACS Cloud Service:
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.
- 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.
- In the ACS console, generate an init bundle.
- Using a terminal window, log in to your OpenShift Container Platform cluster and apply the init bundle.
- 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.
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.
NoteFor 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.
NoteYou 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).
ImportantYou 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
Scanner | CPU | Memory |
---|---|---|
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
Sensor | CPU | Memory |
---|---|---|
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 controller | CPU | Memory |
---|---|---|
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.
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
Collector | CPU | Memory |
---|---|---|
Request | .05 cores | 320 MiB |
Limit | .75 cores | 1 GiB |
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:
- Log in to the Red Hat Hybrid Cloud Console.
- From the navigation menu, select Advanced Cluster Security → ACS Instances.
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.
- 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.
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.
You must have the Admin user role to create an init bundle.
Procedure
- On the RHACS portal, navigate to Platform Configuration → Integrations.
- Navigate to the Authentication Tokens section and click on Cluster Init Bundle.
- Click Generate bundle.
Enter a name for the cluster init bundle and click Generate.
- If you are installing using Helm charts, click Download Helm Values File to download the generated bundle.
- If you are installing using the Operator, click Download Kubernetes Secret File to download the generated bundle.
Store this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.
Next steps
- Apply the init bundle by creating a resource on the secured cluster.
- 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.
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 theROX_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
ImportantEnsure 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.
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
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
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.
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
- On the OpenShift Container Platform web console, navigate to the Operators → Installed Operators page.
- Click the RHACS Operator.
- Click Secured Cluster from the central navigation menu in the Operator details page.
- Click Create SecuredCluster.
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.
- 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.
- Optional: Add any labels for the cluster.
-
Enter a unique name for your
SecuredCluster
custom resource. 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 ascentral.example.com:443
. The default value ofcentral.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
.
- 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.
- Click Create.
Next step
- Optional: Configure additional secured cluster settings.
- 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.NoteDeploy 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).
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.
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
Parameter | Description |
---|---|
| Name of your cluster. |
|
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 |
| Address of the Sensor endpoint including port number. |
| Image pull policy for the Sensor container. |
| The internal service-to-service TLS certificate that Sensor uses. |
| The internal service-to-service TLS certificate key that Sensor uses. |
| The memory request for the Sensor container. Use this parameter to override the default value. |
| The CPU request for the Sensor container. Use this parameter to override the default value. |
| The memory limit for the Sensor container. Use this parameter to override the default value. |
| The CPU limit for the Sensor container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
|
The name of the |
| The name of the Collector image. |
| Address of the registry you are using for the main image. |
| Address of the registry you are using for the Collector image. |
|
Image pull policy for |
| Image pull policy for the Collector images. |
|
Tag of |
|
Tag of |
|
Either |
| Image pull policy for the Collector container. |
| Image pull policy for the Compliance container. |
|
If you specify |
| The memory request for the Collector container. Use this parameter to override the default value. |
| The CPU request for the Collector container. Use this parameter to override the default value. |
| The memory limit for the Collector container. Use this parameter to override the default value. |
| The CPU limit for the Collector container. Use this parameter to override the default value. |
| The memory request for the Compliance container. Use this parameter to override the default value. |
| The CPU request for the Compliance container. Use this parameter to override the default value. |
| The memory limit for the Compliance container. Use this parameter to override the default value. |
| The CPU limit for the Compliance container. Use this parameter to override the default value. |
| The internal service-to-service TLS certificate that Collector uses. |
| The internal service-to-service TLS certificate key that Collector uses. |
|
This setting controls whether Kubernetes is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
|
When you set this parameter as |
|
This setting controls whether the cluster is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
| This setting controls whether Red Hat Advanced Cluster Security for Kubernetes evaluates policies; if it is disabled, all AdmissionReview requests are automatically accepted. |
|
This setting controls the behavior of the admission control service. You must specify |
|
If you set this option to |
|
Set it to |
| 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. |
| The memory request for the Admission Control container. Use this parameter to override the default value. |
| The CPU request for the Admission Control container. Use this parameter to override the default value. |
| The memory limit for the Admission Control container. Use this parameter to override the default value. |
| The CPU limit for the Admission Control container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
| The internal service-to-service TLS certificate that Admission Control uses. |
| The internal service-to-service TLS certificate key that Admission Control uses. |
|
Use this parameter to override the default |
|
If you specify |
|
Specify |
|
Specify |
|
Specify |
| Resource specification for Sensor. |
| Resource specification for Admission controller. |
| Resource specification for Collector. |
| Resource specification for Collector’s Compliance container. |
|
If you set this option to |
|
If you set this option to |
|
If you set this option to |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| Resource specification for Collector’s Compliance container. |
| Setting this parameter allows you to modify the scanner log level. Use this option only for troubleshooting purposes. |
|
If you set this option to |
| The minimum number of replicas for autoscaling. Defaults to 2. |
| The maximum number of replicas for autoscaling. Defaults to 5. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| The memory request for the Scanner container. Use this parameter to override the default value. |
| The CPU request for the Scanner container. Use this parameter to override the default value. |
| The memory limit for the Scanner container. Use this parameter to override the default value. |
| The CPU limit for the Scanner container. Use this parameter to override the default value. |
| The memory request for the Scanner DB container. Use this parameter to override the default value. |
| The CPU request for the Scanner DB container. Use this parameter to override the default value. |
| The memory limit for the Scanner DB container. Use this parameter to override the default value. |
| 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).
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.
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
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. 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.
NoteYou 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:
-
Install the
roxctl
CLI. - 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
Download the latest version of the
roxctl
CLI:$ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.74.9/bin/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
: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
Download the latest version of the
roxctl
CLI:$ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.74.9/bin/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
: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
- On the RHACS portal, navigate to Platform Configuration → Clusters.
- Select + New Cluster.
- Specify a name for the cluster.
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.
- Click Next to continue with the Sensor setup.
Click Download YAML File and Keys to download the cluster bundle (zip archive).
ImportantThe cluster bundle zip archive includes unique configurations and keys for each cluster. Do not reuse the same files in another cluster.
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
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
- 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.
Chapter 6. Setting up RHACS Cloud Service on other platforms
6.1. Setting up RHACS Cloud Service on other platforms
Red Hat Advanced Cluster Security Cloud Service (RHACS Cloud Service) provides security services for your Kubernetes clusters. You can install RHACS Cloud Service on Kubernetes systems with secured clusters on managed platforms such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Microsoft Azure Kubernetes Service (AKS).
Prerequisites
- Understand the installation platforms and methods.
- Understand Red Hat Advanced Cluster Security for Kubernetes architecture.
- Review the prerequisites.
To set up RHACS Cloud Service on other platforms:
In the Red Hat Hybrid Cloud Console, from the navigation menu, select Advanced Cluster Security → ACS Instances and 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.
- Click Open ACS Console. You need your Red Hat Single Sign-On (RH-SSO) credentials, or credentials for another identity provider if that has been configured.
- In the ACS console, generate an init bundle.
- Using a terminal window, log in to your cluster and apply the init bundle.
- Install secured cluster resources on each of your secured clusters.
6.2. Prerequisites for RHACS Cloud Service on other platforms
You must complete prerequisites before installing Red Hat Advanced Cluster Security Cloud Service for supported Kubernetes platforms.
6.2.1. General requirements
RHACS has some system requirements that must be met before installing.
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.
NoteFor 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.
NoteYou 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).
ImportantYou 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.
6.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
Scanner | CPU | Memory |
---|---|---|
Request | 1.2 cores | 2700 MiB |
Limit | 5 cores | 8000 MiB |
6.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
Sensor | CPU | Memory |
---|---|---|
Request | 1 core | 1 GiB |
Limit | 2 cores | 4 GiB |
6.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 controller | CPU | Memory |
---|---|---|
Request | .05 cores | 100 MiB |
Limit | .5 cores | 500 MiB |
6.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.
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
Collector | CPU | Memory |
---|---|---|
Request | .05 cores | 320 MiB |
Limit | .75 cores | 1 GiB |
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.
6.3. Creating an RHACS Cloud instance on other platforms
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.
6.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:
- Log in to the Red Hat Hybrid Cloud Console.
- From the navigation menu, select Advanced Cluster Security → ACS Instances.
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.
- Click Create instance.
Next step
- Generate an init bundle by using the ACS Console.
6.4. Generating and applying an init bundle for RHACS Cloud Service on other platforms
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.
You must have the Admin user role to create an init bundle.
6.4.1. Generating an init bundle
6.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.
You must have the Admin user role to create an init bundle.
Procedure
- On the RHACS portal, navigate to Platform Configuration → Integrations.
- Navigate to the Authentication Tokens section and click on Cluster Init Bundle.
- Click Generate bundle.
Enter a name for the cluster init bundle and click Generate.
- If you are installing using Helm charts, click Download Helm Values File to download the generated bundle.
- If you are installing using the Operator, click Download Kubernetes Secret File to download the generated bundle.
Store this bundle securely because it contains secrets. You can use the same bundle to create multiple secured clusters.
Next steps
- Apply the init bundle by creating a resource on the secured cluster.
- Install secured cluster services on each cluster.
6.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.
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 theROX_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
ImportantEnsure 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.
-
Use the
kubectl
CLI to create resources using the init bundle.
6.4.2. Applying an init bundle by creating a resource
6.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.
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
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
Next Step
- Install RHACS secured cluster services in all clusters that you want to monitor.
6.5. Installing secured cluster services for RHACS Cloud Service on other platforms
You can install RHACS Cloud Service on your secured clusters by using one of the following methods:
- 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)
6.5.1. 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, by using Helm charts with the default values, or by using Helm charts with customizations of configuration parameters.
First, ensure that you add the Helm chart repository.
6.5.1.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.NoteDeploy 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/
6.5.1.2. Installing RHACS Cloud Service on secured clusters by using Helm charts without customizations
6.5.1.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).
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
6.5.1.3. Configuring the secured-cluster-services Helm chart with customizations
This section describes Helm chart configuration parameters that you can use with the helm install
and helm upgrade
commands. You can 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.
While using the secured-cluster-services
Helm chart, do not modify the values.yaml
file that is part of the chart.
6.5.1.3.1. Configuration parameters
Parameter | Description |
---|---|
| Name of your cluster. |
|
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 |
| Address of the Sensor endpoint including port number. |
| Image pull policy for the Sensor container. |
| The internal service-to-service TLS certificate that Sensor uses. |
| The internal service-to-service TLS certificate key that Sensor uses. |
| The memory request for the Sensor container. Use this parameter to override the default value. |
| The CPU request for the Sensor container. Use this parameter to override the default value. |
| The memory limit for the Sensor container. Use this parameter to override the default value. |
| The CPU limit for the Sensor container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
|
The name of the |
| The name of the Collector image. |
| Address of the registry you are using for the main image. |
| Address of the registry you are using for the Collector image. |
|
Image pull policy for |
| Image pull policy for the Collector images. |
|
Tag of |
|
Tag of |
|
Either |
| Image pull policy for the Collector container. |
| Image pull policy for the Compliance container. |
|
If you specify |
| The memory request for the Collector container. Use this parameter to override the default value. |
| The CPU request for the Collector container. Use this parameter to override the default value. |
| The memory limit for the Collector container. Use this parameter to override the default value. |
| The CPU limit for the Collector container. Use this parameter to override the default value. |
| The memory request for the Compliance container. Use this parameter to override the default value. |
| The CPU request for the Compliance container. Use this parameter to override the default value. |
| The memory limit for the Compliance container. Use this parameter to override the default value. |
| The CPU limit for the Compliance container. Use this parameter to override the default value. |
| The internal service-to-service TLS certificate that Collector uses. |
| The internal service-to-service TLS certificate key that Collector uses. |
|
This setting controls whether Kubernetes is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
|
When you set this parameter as |
|
This setting controls whether the cluster is configured to contact Red Hat Advanced Cluster Security for Kubernetes with |
| This setting controls whether Red Hat Advanced Cluster Security for Kubernetes evaluates policies; if it is disabled, all AdmissionReview requests are automatically accepted. |
|
This setting controls the behavior of the admission control service. You must specify |
|
If you set this option to |
|
Set it to |
| 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. |
| The memory request for the Admission Control container. Use this parameter to override the default value. |
| The CPU request for the Admission Control container. Use this parameter to override the default value. |
| The memory limit for the Admission Control container. Use this parameter to override the default value. |
| The CPU limit for the Admission Control container. Use this parameter to override the default value. |
|
Specify a node selector label as |
| 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. |
| The internal service-to-service TLS certificate that Admission Control uses. |
| The internal service-to-service TLS certificate key that Admission Control uses. |
|
Use this parameter to override the default |
|
If you specify |
|
Specify |
|
Specify |
|
Specify |
| Resource specification for Sensor. |
| Resource specification for Admission controller. |
| Resource specification for Collector. |
| Resource specification for Collector’s Compliance container. |
|
If you set this option to |
|
If you set this option to |
|
If you set this option to |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| Resource specification for Collector’s Compliance container. |
| Setting this parameter allows you to modify the scanner log level. Use this option only for troubleshooting purposes. |
|
If you set this option to |
| The minimum number of replicas for autoscaling. Defaults to 2. |
| The maximum number of replicas for autoscaling. Defaults to 5. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner. |
|
Specify a node selector label as |
| If the node selector selects tainted nodes, use this parameter to specify a taint toleration key, value, and effect for Scanner DB. |
| The memory request for the Scanner container. Use this parameter to override the default value. |
| The CPU request for the Scanner container. Use this parameter to override the default value. |
| The memory limit for the Scanner container. Use this parameter to override the default value. |
| The CPU limit for the Scanner container. Use this parameter to override the default value. |
| The memory request for the Scanner DB container. Use this parameter to override the default value. |
| The CPU request for the Scanner DB container. Use this parameter to override the default value. |
| The memory limit for the Scanner DB container. Use this parameter to override the default value. |
| The CPU limit for the Scanner DB container. Use this parameter to override the default value. |
6.5.1.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).
6.5.1.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).
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.
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
6.5.1.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
-
Update the
values-public.yaml
andvalues-private.yaml
configuration files with new values. 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.
NoteYou 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.
6.5.2. Installing RHACS on secured clusters by using the roxctl CLI
To install RHACS on secured clusters by using the CLI, perform the following steps:
-
Install the
roxctl
CLI. - Install Sensor.
6.5.2.1. Installing the roxctl CLI
You must first download the binary. You can install roxctl
on Linux, Windows, or macOS.
6.5.2.1.1. Installing the roxctl CLI on Linux
You can install the roxctl
CLI binary on Linux 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/Linux/roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
6.5.2.1.2. Installing the roxctl CLI on macOS
You can install the roxctl
CLI binary on macOS 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/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctl
binary executable:$ chmod +x roxctl
Place the
roxctl
binary in a directory that is on yourPATH
:To check your
PATH
, execute the following command:$ echo $PATH
Verification
Verify the
roxctl
version you have installed:$ roxctl version
6.5.2.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
6.5.2.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
- On the RHACS portal, navigate to Platform Configuration → Clusters.
- Select + New Cluster.
- Specify a name for the cluster.
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.
- Click Next to continue with the Sensor setup.
Click Download YAML File and Keys to download the cluster bundle (zip archive).
ImportantThe cluster bundle zip archive includes unique configurations and keys for each cluster. Do not reuse the same files in another cluster.
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
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
- 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.
6.6. Verifying installation of RHACS Cloud Service on other platforms
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.
Chapter 7. Uninstalling Red Hat Advanced Cluster Security for Kubernetes
When you install Red Hat Advanced Cluster Security for Kubernetes, it creates:
-
A namespace called
rhacs-operator
where the Operator is installed, if you chose the Operator method of installation -
A namespace called
stackrox
, or another namespace where you created the Central and SecuredCluster custom resources -
PodSecurityPolicy
and Kubernetes role-based access control (RBAC) objects for all components - Additional labels on namespaces, for use in generated network policies
- An application custom resource definition (CRD), if it does not exist
Uninstalling Red Hat Advanced Cluster Security for Kubernetes involves deleting all of these items.
7.1. Deleting namespace
You can delete the namespace that Red Hat Advanced Cluster Security for Kubernetes creates by using the OpenShift Container Platform or Kubernetes command-line interface.
Procedure
Delete the
stackrox
namespace:On OpenShift Container Platform:
$ oc delete namespace stackrox
On Kubernetes:
$ kubectl delete namespace stackrox
If you installed RHACS in a different namespace, use the name of that namespace in the delete
command.
7.2. Deleting global resources
You can delete the global resources that Red Hat Advanced Cluster Security for Kubernetes creates, by using the OpenShift Container Platform or Kubernetes command-line interface.
Procedure
Delete global resources:
On OpenShift Container Platform:
$ oc get clusterrole,clusterrolebinding,role,rolebinding,psp -o name | grep stackrox | xargs oc delete --wait
$ oc delete scc -l "app.kubernetes.io/name=stackrox"
$ oc delete ValidatingWebhookConfiguration stackrox
On Kubernetes:
$ kubectl get clusterrole,clusterrolebinding,role,rolebinding,psp -o name | grep stackrox | xargs kubectl delete --wait
$ kubectl delete ValidatingWebhookConfiguration stackrox
7.3. Deleting labels and annotations
You can delete the labels and annotations that Red Hat Advanced Cluster Security for Kubernetes creates, by using the OpenShift Container Platform or Kubernetes command-line interface.
Procedure
Delete labels and annotations:
On OpenShift Container Platform:
$ for namespace in $(oc get ns | tail -n +2 | awk '{print $1}'); do oc label namespace $namespace namespace.metadata.stackrox.io/id-; oc label namespace $namespace namespace.metadata.stackrox.io/name-; oc annotate namespace $namespace modified-by.stackrox.io/namespace-label-patcher-; done
On Kubernetes:
$ for namespace in $(kubectl get ns | tail -n +2 | awk '{print $1}'); do kubectl label namespace $namespace namespace.metadata.stackrox.io/id-; kubectl label namespace $namespace namespace.metadata.stackrox.io/name-; kubectl annotate namespace $namespace modified-by.stackrox.io/namespace-label-patcher-; done