Configuring

Procedure

1. Download the ca-setup.sh script.

   Note
   • If you are doing a new installation, you can find the ca-setup.sh script in the scripts directory at central-bundle/central/scripts/ca-setup.sh.
   • You must run the ca-setup.sh script in the same terminal from which you logged into your OpenShift Container Platform cluster.

2. Make the ca-setup.sh script executable:

   $ chmod +x ca-setup.sh

3. To add:

   1. A single certificate, use the -f (file) option:

      $ ./ca-setup.sh -f <certificate>

      Note
      • You must use a PEM-encoded certificate file (with any extension).
      • You can also use the -u (update) option along with the -f option to update any previously added certificate.

   2. Multiple certificates at once, move all certificates in a directory, and then use the -d (directory) option:

      $ ./ca-setup.sh -d <directory_name>

      Note
      • You must use PEM-encoded certificate files with a .crt or .pem extension.
      • Each file must only contain a single certificate.
      • You can also use the -u (update) option along with the -d option to update any previously added certificates.

Procedure

1. In the RHACS portal, click on the link in the banner that announces the certificate expiration to download a YAML configuration file, which contains a new secret. The secret includes the certificate and key values.

2. Apply the new YAML configuration file to the cluster where you have installed Central by running the following command:

   $ oc apply -f <secret_file.yaml>

3. Restart Central to apply the changes.

Procedure

1. Click on the link in the banner to download a YAML configuration file, which contains a new OpenShift Container Platform secret, including the certificate and key values.

2. Apply the new YAML configuration file to the cluster where you installed Scanner.

   $ oc apply -f <secret_file.yaml>

3. Restart Scanner to apply the changes.

Procedure

1. In the RHACS portal, go to Platform Configuration → System Configuration.
2. On the System Configuration view header, click Edit.
3. Enter your login message in the Login Configuration section.
4. To enable the login message, turn on the toggle in the Login Configuration section.
5. Click Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → System Configuration.
2. On the System Configuration view header, click Edit.
3. Under the Header Configuration and Footer Configuration sections, enter the header and footer text.
4. Customize the header and footer Text Color, Size, and Background Color.
5. To enable the header, turn on the toggle in the Header Configuration section.
6. To enable the footer, turn on the toggle in the Footer Configuration section.
7. Click Save.

1. Download the definitions.
2. Upload the definitions to Central.

1. The existing Collector image.
2. The kernel support package (if you have uploaded one to Central).
3. A Red Hat-operated server available on the internet. Collector uses Central’s network connection to check and download the probes.

Procedure

1. In the RHACS portal, go to Platform Configuration → System Configuration.
2. On the System Configuration view header, click Edit.

3. Under the Data Retention Configuration section, update the number of days for each type of data:

   • All Runtime Violations
   • Resolved Deploy-Phase Violations
   • Runtime Violations For Deleted Deployments

   • Images No Longer Deployed

     Note

     To save a type of data forever, set the retention period to 0 days.

4. Click Save.

Procedure

1. Create a patch and define a ROX_PLAINTEXT_ENDPOINTS environment variable:

   $ CENTRAL_PLAINTEXT_PATCH='
   spec:
     template:
       spec:
         containers:
         - name: central
           env:
           - name: ROX_PLAINTEXT_ENDPOINTS
             value: <endpoints_spec> 1
   '

   1

   Endpoint specifications in the form of <type>@<addr>:<port>. See the Prerequisites section for details.

2. Add the ROX_PLAINTEXT_ENDPOINTS environment variable to the Central deployment:

   $ oc -n stackrox patch deploy/central -p "$CENTRAL_PLAINTEXT_PATCH"

Procedure

1. In the RHACS portal, go to Platform Configuration → Clusters.

2. Turn on the Automatically upgrade secured clusters toggle.

   Note

   For new installations, the Automatically upgrade secured clusters toggle is enabled by default.

Procedure

1. In the RHACS portal, go to Platform Configuration → Clusters.

2. Turn off the Automatically upgrade secured clusters toggle.

   Note

   For new installations, the Automatically upgrade secured clusters toggle is enabled by default.

Procedure

1. In the RHACS portal, go to Platform Configuration → Clusters.
2. Select the Upgrade available option under the Upgrade status column for the cluster you want to upgrade.
3. To upgrade multiple clusters at once, select the checkboxes in the Cluster column for the clusters you want to update.
4. Click Upgrade.

Procedure

1. In the RHACS portal, go to Platform Configuration → System Configuration.
2. In the System Configuration header, click Edit.

3. In the Cluster deletion section, you can configure the following fields:

   • Decommissioned cluster age: The number of days that a cluster is unreachable before it is considered for removal from RHACS. If Central cannot reach Sensor on the cluster for this number of days, the cluster and all of its resources are removed from RHACS. To leave this feature disabled, which is the default behavior, enter 0 in this field. To enable this feature, enter a nonzero number, such as 90, to configure the number of unreachable days.

   • Ignore clusters which have labels: To prevent a cluster from being removed, you can configure a label by entering a key and value in this section. Clusters with this label will not be removed, even if they have been unreachable for the number of days set in the Decommissioned cluster age field.

     • Key: Enter the label to use for the cluster.

     • Value: Enter the value associated with the key.

       For example, to preserve production clusters from removal, you can configure a key of cluster-type and a value of production.

       Note

       In the Cluster deletion section, click Clusters which have Sensor Status: Unhealthy to go to the Clusters list page. This page is filtered to show nonactive clusters that are subject to removal and a timeframe for the removal from RHACS.

4. Click Save.

Procedure

1. In the RHACS portal, go to Platform Configuration → System Configuration.

2. In the Cluster deletion section, click Clusters which have Sensor Status: Unhealthy to go to the Clusters list page. This page is filtered to show nonactive clusters that are subject to removal from RHACS and a timeframe for the removal.

   Note

   If this feature is enabled after a cluster is considered nonactive, the counting of days towards removal starts from the time the cluster became nonactive, not from the time that the feature was enabled. If there are any nonactive clusters that you do not want removed, you can configure a label as described in the "Configuring cluster decommissioning" section. Clusters with those labels are ignored when the system removes nonactive clusters.

Procedure

1. Save the existing secret as a YAML file:

   $ oc -n stackrox get secret proxy-config \
     -o go-template='{{index .data "config.yaml" | \
     base64decode}}{{"\n"}}' > /tmp/proxy-config.yaml

2. Edit the fields you want to modify in the YAML configuration file, as specified in the Configure proxy during installation section.

3. After you save the changes, run the following command to replace the secret:

   $ oc -n stackrox create secret generic proxy-config \
     --from-file=config.yaml=/tmp/proxy-config.yaml -o yaml --dry-run | \
     oc label -f - --local -o yaml app.kubernetes.io/name=stackrox | \
     oc apply -f -

   Important
   • You must wait for at least 1 minute, until OpenShift Container Platform propagates your changes to Central and Scanner.
   • If you see any issues with outgoing connections after changing the proxy configuration, you must restart your Central and Scanner pods.

Procedure

1. Open the configuration file central/proxy-config-secret.yaml from your deployment bundle directory.

   Note

   If you are using Helm the configuration file is at central/templates/proxy-config-secret.yaml.

2. Edit the fields you want to modify in the configuration file:

   apiVersion: v1
   kind: Secret
   metadata:
     namespace: stackrox
     name: proxy-config
   type: Opaque
   stringData:
     config.yaml: |- 1
       # # NOTE: Both central and scanner should be restarted if this secret is changed.
       # # While it is possible that some components will pick up the new proxy configuration
       # # without a restart, it cannot be guaranteed that this will apply to every possible
       # # integration etc.
       # url: http://proxy.name:port 2
       # username: username 3
       # password: password 4
       # # If the following value is set to true, the proxy wil NOT be excluded for the default hosts:
       # # - *.stackrox, *.stackrox.svc
       # # - localhost, localhost.localdomain, 127.0.0.0/8, ::1
       # # - *.local
       # omitDefaultExcludes: false
       # excludes:  # hostnames (may include * components) for which you do not 5
       # # want to use a proxy, like in-cluster repositories.
       # - some.domain
       # # The following configuration sections allow specifying a different proxy to be used for HTTP(S) connections.
       # # If they are omitted, the above configuration is used for HTTP(S) connections as well as TCP connections.
       # # If only the `http` section is given, it will be used for HTTPS connections as well.
       # # Note: in most cases, a single, global proxy configuration is sufficient.
       # http:
       #   url: http://http-proxy.name:port 6
       #   username: username 7
       #   password: password 8
       # https:
       #   url: http://https-proxy.name:port 9
       #   username: username 10
       #   password: password 11

   3 4 7 8 10 11

   Adding a username and a password is optional, both at the beginning and in the http and https sections.

   2 6 9

   The url option supports the following URL schemes:

   • http:// for an HTTP proxy.
   • https:// for a TLS-enabled HTTP proxy.
   • socks5:// for a SOCKS5 proxy.

   5

   The excludes list can contain DNS names (with or without * wildcards), IP addresses, or IP blocks in CIDR notation (for example, 10.0.0.0/8). The values in this list are applied to all outgoing connections, regardless of protocol.

   1

   The |- line in the stringData section indicates the start of the configuration data.

   Note

   • When you first open the file, all values are commented out (by using the # sign at the beginning of the line). Lines starting with double hash signs # # contain explanation of the configuration keys.
   • Make sure that when you edit the fields, you maintain an indentation level of two spaces relative to the config.yaml: |- line.

3. After editing the configuration file, you can proceed with your usual installation. The updated configuration instructs Red Hat Advanced Cluster Security for Kubernetes to use the proxy running on the provided address and the port number.

Procedure

1. In the RHACS portal, select Platform Configuration → System Health.
2. On the System Health view header, click Generate Diagnostic Bundle.
3. For the Filter by clusters drop-down menu, select the clusters for which you want to generate the diagnostic data.
4. For Filter by starting time, specify the date and time (in UTC format) from which you want to include the diagnostic data.
5. Click Download Diagnostic Bundle.

Procedure

1. After you generate the central-bundle, open the ./central-bundle/central/02-endpoints-config.yaml file.
2. In this file, add your custom YAML configuration under the data: section of the key endpoints.yaml. Make sure that you maintain a 4 space indentation for the YAML configuration.
3. Continue the installation instructions as usual. Red Hat Advanced Cluster Security for Kubernetes uses the specified configuration.

Procedure

1. Download the existing config map:

   $ oc -n stackrox get cm/central-endpoints -o go-template='{{index .data "endpoints.yaml"}}'  > <directory_path>/central_endpoints.yaml

2. In the downloaded central_endpoints.yaml file, specify your custom YAML configuration.

3. Upload and apply the modified central_endpoints.yaml configuration file:

   $ oc -n stackrox create cm central-endpoints --from-file=endpoints.yaml=<directory-path>/central-endpoints.yaml -o yaml --dry-run | \
   oc label -f - --local -o yaml app.kubernetes.io/name=stackrox | \
   oc apply -f -

4. Restart Central.

Procedure

1. Clone the allow-ext-to-central Kubernetes network policy:

   $ oc -n stackrox get networkpolicy.networking.k8s.io/allow-ext-to-central -o yaml > <directory_path>/allow-ext-to-central-custom-port.yaml

2. Use it as a reference to create your network policy, and in that policy, specify the port number you want to expose. Make sure to change the name of your network policy in the metadata section of the YAML file, so that it does not interfere with the built-in allow-ext-to-central policy.

Procedure

1. Update the values-public.yaml configuration file with the following values:

   central.exposeMonitoring: true
   scanner.exposeMonitoring: true

2. Run the helm upgrade command and specify the configuration files.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Scroll down to the Notifier Integrations section and select Generic Webhook or Splunk.
3. Fill in the required information and turn on the Enable Audit Logging toggle.

Procedure

1. In the RHACS portal, go to Platform Configuration → Integrations.
2. Scroll to the Authentication Tokens category, and then click API Token.
3. Click Generate Token.
4. Enter a name for the token and select a role that provides the required level of access (for example, Continuous Integration or Sensor Creator).

5. Click Generate.

   Important

   Copy the generated token and securely store it. You will not be able to view it again.

Procedure

1. Create the permission set by entering the following command. This example creates a permission set named "restricted" and is saved as the permission-set.yaml file. It sets read and write access for the Administration resource and read access to the Access resource.

   $ roxctl declarative-config create permission-set \
   --name="restricted" \
   --description="Restriction permission set that only allows \
   access to Administration and Access resources" \
   --resource-with-access=Administration=READ_WRITE_ACCESS \
   --resource-with-access=Access=READ_ACCESS > permission-set.yaml

2. Create the role that allows access to the Administration and Access resources by entering the following command. This example creates a role named "restricted" and is saved as the role.yaml file.

   $ roxctl declarative-config create role \
   --name="restricted" \
   --description="Restricted role that only allows access to Administration and Access" \
   --permission-set="restricted" \
   --access-scope="Unrestricted" > role.yaml

3. Create a config map from the two YAML files that were created in the earlier steps by entering the following command. This example creates the declarative-configurations config map.

   $ kubectl create configmap declarative-configurations \ 1
   --from-file permission-set.yaml --from-file role.yaml \
   -o yaml --namespace=stackrox > declarative-configs.yaml

   1

   For OpenShift Container Platform, use oc create.

4. Apply the config map by entering the following command:

   $ kubectl apply -f declarative-configs.yaml 1

   1

   For OpenShift Container Platform, use oc apply.

   After you apply the config map, configuration information extracted from Central creates the resources.

   Note

   Although the watch interval is 5 seconds, as described in the following paragraph, there can be a delay in propagating changes from the config map to the Central mount.

   You can configure the following intervals to specify how declarative configurations interact with Central:

   • Configuration watch interval: The interval for Central to check for changes is every 5 seconds. You can configure this interval by using the ROX_DECLARATIVE_CONFIG_WATCH_INTERVAL environment variable.
   • Reconciliation interval: By default, declarative configuration reconciliation with Central occurs every 20 seconds. You can configure this interval by using the ROX_DECLARATIVE_CONFIG_RECONCILE_INTERVAL environment variable.

Procedure

1. In the RHACS portal, go to the Platform Configuration → Access Control → Auth providers tab, and then click Invite users.

2. In the Invite users dialog box, provide the following information:

   • Emails to invite: Enter one or more email addresses of the users you want to invite. Ensure that they are valid email addresses associated with the intended recipients.

   • Provider: From the drop-down list, select a provider you want to use for each invited user.

     Important
     • If you have only one authentication provider available, it is selected by default.
     • If multiple authentication providers are available and at least one of them is Red Hat SSO or Default Internal SSO, that provider is selected by default.
     • If multiple authentication providers are available, but none of them is Red Hat SSO or Default Internal SSO, you are prompted to select one manually.
     • If you have not yet set up an authentication provider, a warning message appears and the form is disabled. Click the link, which takes you to the Access Control section to configure an authentication provider.
   • Role: From the drop-down list, select the role to assign to each invited user.
3. Click Invite users.
4. On the confirmation dialog box, you receive a confirmation that the users have been created with the selected role.
5. Copy the one or more email addresses and the message into an email that you create in your own email client, and send it to the users.
6. Click Done.

Verification

1. In the RHACS portal, go to the Platform Configuration → Access Control → Auth providers tab.
2. Select the authentication provider you used to invite users.
3. Scroll down to the Rules section.
4. Verify that the user emails and authentication provider roles have been added to the list.