Release of Guardium Data Protection 12.2.1

Backup and archive operations fail on MiniIO or ECS when a custom bucket is configured. 

Workaround: For miniIO, create a new bucket name by updating the user policy to include the s3:CreateBucket permission. For ECS, if the backup/archive fails on the initial attempt, retry the action immediately.

After you backup and restore to a 12.2.1 environment, opening a custom dashboard can trigger an error that prevents the dashboard from loading. 

Workaround: Open the affected dashboard in Edit mode and then save the dashboard. If it's still unsuccessful, go to Query-Report builder and fix the query definition.

After switching to the backup central manager (CM) in version 12.2.1, the Kafka Cluster status turns red, indicating connection failures to Kafka brokers. 

Workaround: After switching to the backup CM, manually restart the Kafka Cluster and Kafka Cruise Control using the Kafka Cluster Management UI to restore the Kafka Cluster to a healthy state.

If the central manager is running version 12.2.1, all managed units must be patched to the same version. V6 datamarts cannot extract data from managed units that are not on the same patch level, and Guardium Data Security Center (GDSC) may not receive data from these datamarts. 

Workaround: Upgrade all managed units to match the central manager’s patch level to ensure v6 datamarts are supported.

Enabling DHCP does not automatically set the hostname and domain as expected.  

Workaround: Manually set host and domain names by using the following commands: store system hostname <host_name> and store system domain <domain_name>

Edge Gateway

(New feature in 12.2.1)

When custom certificates are generated without a Subject Alternative Name (SAN), Edge cannot transmit health metrics to the central manager and its status is displayed as RED. Starting with Go 1.15, certificates require at least one SAN entry. 

Workaround:  Regenerate TLS certificates used by Edge Gateway to include a SAN that matches the Edge hostname(s).

Edge Gateway

(New feature in 12.2.1)

When you register an Edge Gateway, you might encounter issues with configuring ports if you select HAProxy options when you have Traefik with K3s installed. Configure Traefik manually after Edge installation is complete. 

Workaround: Traefik could be disabled during K3s setup by using this option: INSTALL_K3S_EXEC="--disable=traefik"

If you want to use Traefik and Gateway API for TCPROUTE, you must enable experimentalChannel support.

When K3s multi nodes cluster is used to deploy edge, the control-plane/master nodes need to be configured NoSchedule using command: 

kubectl taint nodes ${node-name} key=value:NoSchedule

To use control-plane/master node as worker node, the control-plane/master node must match the minimum resource requirements.

Edge Gateway 

(New feature in 12.2.1)

The grdapi registerEdge command does not validate cpuLimits, memoryLimits, and storageRequests inputs, allowing invalid values to register an edge without error. This results in UI issues when attempting to update the Edge Gateway due to incorrect or negative resource specifications. 

Workaround: Manually validate values in 00-edge-namespace-resourcequota-optional.yaml  in the edge bundle. A fix is available in an upcoming release.

Edge Gateway 

(New feature in 12.2.1)

When multiple aggregators are selected for data export, the system processes them based on selection priority. However, the user interface does not indicate the order in which aggregators are processed. 

A fix is available in an upcoming release.

Gen AI app nodes 

(New feature in 12.2.1)

The UUID to register or unregister an app is not available from the Guardium UI or through an Guardium API.

Workaround: UUIDs are available in the following folder: /var/IBM/Guardium/applications/

You can use the API list_applications to list all installed applications on a specific app-node. A fix to enhance the API to display app names is available in an upcoming release.

GenAI app nodes 

(New feature in 12.2.1)

Long-term retention 

(New feature in 12.2.1)

LTR configuration fails if certificate distribution was not successful. 

Workaround: Before configuring LTR, check that the datalake-gui certificate was distributed successfully on the application node where LTR is being configured.

Long-term retention 

(New feature in 12.2.1)

If the bucket used to house LTR data is not empty, or is reused, on startup, errors can occur due to a duplicate database, table, or view name. 

Workaround: After clearing the bucket, rerun the cold storage configuration command. If you want to attempt to use an un-empty bucket, try using a unique resultSchema and coldCatalogSchema.

Long-term retention 

(New feature in 12.2.1)

Long-term retention 

(New feature in 12.2.1)

When configuring long-term retention, you may receive the following message after installing the unit type application on the AIO node: "The new configuration will be effective once you execute the "restart inspection-core" command." 

This message can safely be ignored.

Long-term retention 

(New feature in 12.2.1)

The report execution status and results are not logged in ‘Report activity’ table for datalake reports on the backup central manager (CM). 

Workaround: After switching to the backup CM in version 12.2.1, you must create the datalake runtime environment and distribute certificates by using the following two CLI commands:

• store datalake runtime
• distribute application certificate datalake all_managed true

Long-term retention 

(New feature in 12.2.1)

After restoring collectors with long-term retention (LTR) datamarts from backup, you must reconfigure each datamart to reconnect to LTR by running the datamart_update_copy_file_info GrdAPI command on the central manager (CM).

Workaround: 

1. Access target CM and list cold storages to get the cold storage information with the command: grdapi list_cold_storages

2. Run the command grdapi datamart_update_copy_file_info

Update the v6 Datamart with the cold storage name, data bucket, and catalog endpoint names from the output in step 1.

Long-term retention 

(New feature in 12.2.1)

Long-term retention

(New feature in 12.2.1)

The orphan collection (data that is not ingested) runs automatically after a central manager (CM) failover, but it does not run following a CM restore from backup.

Workaround: After failover, manually run the orphan collection by using the following GuardAPI command:

grdapi ingest_orphaned_files cold_storage_id=<cold_storage_id>

After upgrading from Guardium 12.2 to 12.2.1, compliance measure or metric reports may not display the data correctly due to missing column descriptions. 

Workaround: Open the affected report in the Query Report Builder and click Save on that report to regenerate the column descriptions.

SOX ticket reconciliation

(New feature in 12.2.1)

Automatic ticket mapping via GenAI fails for custom tables created prior to GenAI configuration. Ticket mapping only works if a new custom table is created after GenAI setup. 

Workaround: Create a new custom table post-GenAI configuration.

In MarkLogic database version 11.3.2, a discrepancy has been observed where the Session Key and Session ID are generated uniquely for each query from the Query console, even when multiple queries originate from the same session. This unexpected behavior may cause confusion for users relying on consistent session identifiers. 

A fix is available in an upcoming release.

When the shared-memory segment size for the priority packets or failover information hash table is changed during an upgrade from a previous release or by modifying the tap_failover_session_size parameter, restarting Unix S-TAP will result in the loss of previously saved priority packet data. 

A fix is available in an upcoming release.

In the modernized GUI for S-TAP Control, you cannot set a new G-host as primary. This regression was functional in earlier releases. You also cannot control the sequence to configure failover order. 

Workaround:  After adding the G-host, save and reopen the edit panel to manually edit the S-TAP configuration and designate the desired primary host. For UNIX S-TAPs, you can also edit the guard_tap.ini file manually to update the failover order for each G-host.

After upgrading ATAP to version 12.2.1, failover events lose existing database‑session attributes ( db_user, client_ip, db_name, source_program ) due to a change in shared‑memory segment sizing between 12.2.0 and 12.2.1. 

A fix is available in an upcoming release.

The "Run Diagnostics" function from the STAP Control screen is not working correctly. 

Workaround: DNS resolver is required for STAP diagnostics upload to work correctly. You must also manually specify the gim_server value in the tap ini file.

Universal connector on Edge Gateway

(New feature in 12.2.1)

Universal connector on Edge Gateway

(New feature in 12.2.1)

Universal connector (UC) profile installation fails on OCP edge cluster. 

Workaround:  When deploying Edge Gateway in OpenShift or Amazon EKS clusters, an additional load balancer is required to forward traffic. Configure the ports in the load balancer to match the ports that are used by the sniffer in GDP. Then configure UC or STAP to use the load balancer's hostname/IP address and the opened ports instead of the cluster's hostname. You may need assistance from your cloud administrator to configure certain load balancer products.

After upgrading from Guardium version 12.2 to 12.2.1, universal connector (UC) Kafka plugins (OUA, EDB Postgres) stopped functioning correctly, leading to failure in capturing traffic for these plugins.

Workaround: After upgrading Guardium Data Protection from version 12.2 to 12.2.1:

• Restart Kafka Cluster and UC.
• If EDB Postgres is installed on the system, update the rsyslog.conf file on the EDB server to reference the new certificate.

After installing 12.2.1 on a central manager, the Kafka Dashboard and Kafka Alerts stop functioning correctly. The issue was traced to the Kafka Cruise Control not receiving new certificates promptly, causing authentication failures. 

Workaround: After installing 12.2.1, manually restart the Kafka cluster from the Kafka cluster management page.