Skip to main content
Version: v4.17

Known issues

Issue with Offline Token Validation in Cyral v4.13 Upgrade Scenarios​

During certain upgrade scenarios, Offline Token Validation may not function properly in Cyral v4.13. The Offline Token Validation feature was introduced in Cyral v4.12. However, if your Cyral Control Plane is upgraded to v4.13 and a new repository is added with Cyral token authentication configuration while your Cyral sidecars are still running v4.12, the Offline Token Validation feature will not work as expected.

Workaround: To address this issue, upgrade your sidecars to v4.13 or later. Alternatively, you can disable the Offline Token Validation setting from your Control Plane. Simply navigate to the Settings menu on the left panel to make the necessary adjustments.

Tableau and Looker can't connect to MySQL Smart Port​

Tableau and Looker clients cannot connect through a Cyral Smart Port to a MySQL database. (A Smart Port is a multiplexed port that allows you to expose multiple databases of the same type through a single Cyral sidecar port.)

Workaround: To connect a BI tool like Tableau or Looker to a Cyral-protected MySQL database, use a Cyral sidecar port assignment that is exclusive to the database, rather than a Smart Port that covers multiple databases.

Snowflake Classic Console Worksheets for Snowflake running on the Azure cloud are not supported​

Cyral currently does not support Snowflake Classic Console Worksheets for Snowflake deployments that run on the Azure cloud. Likewise, for Azure cloud-based deployments, Worksheets built in the Classic Console are not supported when querying from a JDBC or ODBC client.

Workaround: Worksheets are supported in the following configurations:

  • Cyral supports Snowflake Worksheets in the Snowsight UI for sites running on Azure cloud.
  • Cyral supports Snowflake Worksheets in both Snowsight and Classic Console for sites running on AWS.

Editing sidecar certificate ARN results in disabled sidecar ports​

When an administrator changes the sidecar certificate ARN for a sidecar that has a certificate ARN already configured, that sidecar can become unreachable. This happens because sidecar load balancer ports are incorrectly disabled when the new ARN is set.

Workaround: After editing the sidecar certificate ARN, follow these steps to re-enable the sidecar's load balancer ports:

  1. In your cloud stack deployment console for the sidecar stack, under Network and security configuration ➡️ SidecarPorts, make a note of all the sidecar ports. You'll be deleting them and will need to restore them.

  2. In the stack deployment console, remove all sidecar ports but one from the SidecarPorts field (preferably an unused one) and update the stack.

  3. After the update, add all the ports back to the SidecarPorts field and update the stack again. This restores the ports.

Helm-deployed sidecars do not support session stickiness​

A Cyral sidecar deployed with Helm 3 does not support session stickiness. Deploy using Cloudformation or Terraform to support session stickiness.

Can't unbind repository from sidecar​

First observed in 2.30. Users might find it impossible to unbind a data repository from a sidecar, or to delete the repository's association with the sidecar in the Data Repositories tab in Sidecar Details in the Cyral UI.

This happens because the repository has the sidecar configured as its Access Gateway. The Cyral UI should prompt the user to remove the Access Gateway assignment.

Workaround: To unbind a repository from a sidecar:

  1. Click Data Repos ➡️ click your repo's name ➡️ Advanced

  2. Set the Access Gateway to None.

  3. Now you can unbind the repo from the sidecar and optionally delete its assignment to the sidecar:

    • In the Cyral UI's main menu, click Sidecars ➡️ click the name of your sidecar ➡️ Data Repositories
    • Find the repository in the list and toggle ots Binding Status to OFF.
    • If you wish to delete the repository's assignment to the sidecar, click the wastebasket 🗑️ icon.

Deprovisioning a user from a group fails with Okta SCIM​​

First observed in 2.29. When an administrator removes a user from a group in Okta, Okta fails to provide the updated group membership list to Cyral. As a result, Cyral continues to treat the user as if they were part of the group.

note

This issue affects only those Cyral-Okta integrations that use SCIM. Cyral-Okta SSO integrations without SCIM are unaffected.

Workaround: Each time a user is removed from an Okta group that has been provisioned to Cyral via SCIM, the Okta admin must perform the following manual configuration steps:

  1. In the Okta Admin UI, delete the group from Cyral SCIM application:
    • Select the group.
    • Select Unlink pushed group
    • Select Delete the group in the target app in the pop-up.
  2. In the Cyral UI, push the group to Cyral again, as explained the Cyral SCIM instructions.