Known issues

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 SSO fails if the Okta SAML setup is set to require signed requests

Cyral SSO for Snowflake with Okta fails if signed requests are required (sign_get_request is set to true) in the SAML 2 configuration.

Workaround: If you're using Cyral for Snowflake SSO with Okta, make sure the following Okta setting is turned OFF: Signed Requests: Validate SAML requests with signature certificates.

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.

Snowsight can't run the same query twice if Cyral row limiting, masking or dataset rewriting is applied

When a user runs a query via Snowsight and triggers a Cyral row limiting, masking or dataset rewriting policy rule, then any subsequent attempt to run that same query in the same Snowsight session will fail.

Workaround: The data user must modify the query (remove the semicolon and add it back for example) and run the query again.

Single-container sidecars do not support Snowflake repositories

Cyral does not currently support protecting Snowflake repositories with a sidecar deployed as a single container. Please use a cloud-deployed sidecar, instead.

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 Snowflake

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

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.

PostgreSQL PortalSuspended messages may result in incorrect query tracking​

First observed in 2.29. For SQL clients that use PostgreSQL's Extended Query Protocol to create and execute prepared statements, PostgreSQL may send a PortalSuspended message during the handling of a query whose execute operation has a limit on the number of returned results. This can occur, for example, when running a query from Tableau.

When Cyral encounters a PortalSuspended, Cyral's tracking of the query may be disrupted, resulting in incorrect logging and application of policy rules. The effects of this issue will not modify any query results unless you are using Cyral policy-based blocking. In that case, Cyral could block the wrong query.