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:
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.
In the stack deployment console, remove all sidecar ports but one from the SidecarPorts field (preferably an unused one) and update the stack.
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:
Click Data Repos ➡️ click your repo's name ➡️ Advanced
Set the Access Gateway to
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
- 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.
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:
- 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.
- 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
execute operation has a limit on the number of returned
results. This can occur, for example, when running a query from
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
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