Skip to main content
Version: v4.1

Known issues

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.

Masking function limitations​​

First observed in 2.29. Behavior is inconsistent for constant_mask rules whose constant does not match that of the column to which they're applied. This can result in the mask not being applied.

Workaround: When creating a constant_mask masking rule in Cyral, make sure the datatype of the constant matches that of the column whose data it will replace