Skip to main content

What's new

2.31

6 May 2022

Sidecars support session stickiness

Cyral sidecars now support session stickiness (or affinity) for data users' client sessions that connect through the sidecar. A single user's client session on certain repository types such as Snowflake can result in multiple connections being established for the session. Since a single Cyral sidecar can run as multiple instances, the sidecar in earlier versions could not guarantee consistent state for the user when that user's session consisted of multiple client sessions handled by multiple instances of the sidecar. This has been fixed in the 2.31 release.

This feature requires that a valid certificate is installed on the sidecar to support TLS communication. Cyral installs these certificates automatically, but you also have the option to use your own certificate.

Custom certificates for sidecars

The Cyral sidecar now supports three types of certificates:

  • Sidecar-created certificates that can be generated automatically at deployment time.
  • Custom certificates signed by the Let's Encrypt certificate authority.
  • Custom certificates that you've self-signed or had signed by the CA of your choice.

Known issues

See the known issues list.

2.30

12 April 2022

Network Shield for Microsoft SQL Server

This release introduces Network Shield rules for Microsoft SQL Server repositories. With these rules, administrators can set limits on who can connect to a repository based on where (source IP address) they're trying to connect from.

2.29

30 March 2022

Service account resolution in Looker and Tableau

This release introduces service account resolution, allowing organizations that use SaaS BI tools to disambiguate the SSO end user's identity from that of the service account used to connect to the data repository. In the 2.29 release, we support the following SaaS BI tools:

This feature allows Cyral to perform identity attribution, tracing requests back to the end users who generated them for activity monitoring, performance debugging, and responding to audit requests to comply with security standards like SOC-2, ISO 27001, and HIPAA.

If you're using a BI tool other than Looker or Tableau, contact Cyral support for help creating a custom connection driver in Cyral to provide service account resolution.

Use SCIM services to load SSO user group information

Cyral now supports the use of Azure AD-based SCIM and Okta-based SCIM to retrieve group information for use in reporting and policy enforcement.

Earlier Cyral releases supported other ways to retrieve group information from major identity providers, and these mechanisms continue to be supported. The SCIM approach adds the ability to get group information during login workflows in which the user does not visit the Cyral Access Portal.

For example, when a user connects to a Denodo repository via Tableau, Cyral's SCIM integration provides user and group information to identify the actual SSO user who logged in, even when the database connection is established using a service account.

Cyral Activity Logs (audit logs) exportable to logging platforms

The Cyral Activity Logs (audit logs from the Cyral control plane) can now be published to integrated SIEM platforms to centralize log analysis. These logs track administrators' connections to and disconnections from the Cyral control plane, as well as any changes made to service account records in Cyral.

Automated fail-open for more repository types

Cyral now offers the option to Snowflake (without SSO), MongoDB and SQL Server.

Support for Sequel Pro

Cyral now supports users connecting from Sequel Pro, the Mac database management application for working with MySQL & MariaDB databases.

SQL Server: Memory budgeting and resiliency improvements

This release adds improved Cyral sidecar resiliency when connected to a SQL Server repository, as well as support for sidecar memory budgeting when connected to SQL Server.

To create an Oracle-to-Oracle database link to a Cyral-protected database using a TCPS connection (CREATE DATABASE LINK), you must install the Cyral certificate bundle in a wallet on the source Oracle database server. See Set up clients for TLS connections for more information.

Fixed: SSO does not work when using TNS names with SQL*Plus and Oracle

In earlier releases, SSO users with @ in their username could not connect using a tnsnames.ora file. This has been fixed. See Using a connect identifier for Oracle.

Known issues

See the known issues list.

2.28

31 January 2022

Automated fail open for Denodo, MariaDB, Oracle, PostgreSQL and Redshift

This release introduces the option to deploy the Cyral sidecar in a DNS-based fail-open mode on AWS. We refer to this as DNS fail-open for AWS.

This public GitHub repository contains the CloudFormation template that deploys the Cyral sidecar fail-open feature. This feature provides automatic fail-open/fail-closed operation for a Cyral sidecar and its respective target repositories, allowing customers to keep existing databases reachable even when the Cyral sidecar experiences a transient failure.

Rate limiting for the Amazon S3 data sources

Users of Amazon S3 storage can now use Cyral to limit the number of files a user is allowed to read, update, and/or delete per hour.

To set this up, add an entry in your Cyral policy for the S3 data repository, and in the rules block of that entry, add a rateLimit for any operation you wish to limit (in the reads, updates, and/or deletes sections or the rule).

For example, to set a limit of 20 files per user per hour on the S3 bucket that you have tracked as "MY_S3_EXAMPLE" in Cyral, you would add this rule:

rules:
- reads:
- data: [MY_S3_EXAMPLE]
rows: any
severity: low
rateLimit: 20

2.27

11 January 2022

Automatic Data Map

Cyral's Automatic Data Map capability finds and helps you secure the data locations you care about. This enables administrators to maintain their data governance posture over time by partially automating the creation and maintenance of Data Maps in Cyral with coverage for all the databases that need protection.

  • Includes out-of-the-box, predefined data field labels
  • Scans each database to identify data fields relevant to those predefined labels
  • Provides field-to-label mapping recommendations to the administrator; if approved, these new mappings are added to the Data Map
  • Custom security policies can be created based on the Data Map

This feature is available to AWS customers only. The following repository types are supported:

  • PostgreSQL
  • Redshift
  • Denodo
  • Snowflake
  • MySQL
  • MSSQL
  • Oracle

Data masking supported on Denodo repositories

Cyral now enables administrators to configure masking policies for data in Denodo databases.

Access Portal

The new Cyral Access Portal simplifies access management for teams who work with data. The portal lets users quickly find a database and copy their login credentials in the right format for their BI tool, or click to access certain data repository types.

Admins configure access rules from the Cyral control plane to define how databases or repositories can be accessed by users and groups defined in their IDP provider. The Access Portal then gives users a central location with personalized connection information for the databases or repositories they use. The portal:

  • Provides a simple, consistent workflow by which all users can access repositories.
  • Provides clear instructions and delineation on how to access repositories of different types using tools like DBeaver, Postico, or the command line.

Cyral S3 File Browser

Within the new Access Portal, the Cyral S3 File Browser streamlines the process for reading from and uploading to S3 buckets.

  • One-click access to the Cyral S3 File Browser from the Access Portal
  • You specify users' access rights in your Cyral policies.
  • The user can choose from the available IAM roles approved for their use, and the view updates automatically to show only those S3 buckets and folders available to that role.
  • Likewise, based on the user's currently chosen IAM role, they can perform the allowed actions (upload, download, delete) on allowed resources.
  • S3 interaction is routed through the Cyral sidecar to log data activity.

Sidecar memory budget

For deployments that need to keep sidecar memory usage under a certain threshold, Cyral now provides the option to enforce a memory budget.

2.26

3 December 2021

Data masking

Version 2.26 introduces the ability to mask the results of queries so that you can protect information and comply with privacy regulations. This feature is currently available for Redshift repositories. See the Mask data setup instructions.

Reliability improvements

Memory thresholds for PostgreSQL

Beginning in 2.26, Cyral imposes memory thresholds for reads from PostgreSQL repositories. By default, the minimum is 1MB and max is 4MB. This introduces the min-read-allocation-size and max-read-allocation-size parameters.

Metrics and logging improvements for Aptible-deployed environments

Until now, Aptible-based sidecars provided limited metrics compared with sidecars deployed in EC2 or Kubernetes. Starting in version 2.26, Cyral captures metrics from all instances of the containers. Newly reported metrics include:

  • Number of connections
  • Total memory in use
  • Dispatcher connection distribution data

Sidecars

New default for fail-to-wire mode of operation

New sidecars deployed using the Cyral control plane version 2.26 or later have the fail-to-wire option disabled by default. See "Fail-to-wire mode of operation" below for details.

2.25

5 November 2021

Sidecars

  • Fail-to-wire mode of operation for sidecars: When running in this mode (also known as "passthrough mode"), the sidecar allows database connections to be made and maintained, even if one or more one of the sidecar's services remains unavailable. For example, the sidecar will enter passthrough mode if the Cyral sidecar's logging service fails.

    The default setting depends on your Cyral version:

    • New sidecars deployed using the Cyral control plane version 2.26 or later have this option disabled by default.
    • New sidecars deployed using the Cyral control plane version 2.25 have this option disabled by default.

    Existing sidecars are unaffected. You can change this setting on a sidecar in the Cyral control plane UI under Repository details ➡️ Advanced ➡️ Enter passthrough mode on failure.

  • Fail-open deployment configuration for sidecars: Cyral 2.25 introduces the first version of the sidecar fail-open deployment option for sidecars deployed via Cloudformation. This feature provides automatic fail-open/fail-closed operation for a Cyral sidecar and its respective target repositories, allowing customers to keep existing databases reachable even when the Cyral sidecar experiences transient failures.

    Not to be confused with fail-to-wire mode, the fail-open deployment option relies on a periodic health check of the sidecar. If the health check fails, a DNS change is made, allowing clients to connect to the data repository directly.

Repository support

  • Resiliency and logging improvements for Oracle, PG, Redshift, Denodo, MySQL and Snowflake repositories

Authorization and repository access

Flexible port configuration with Cloudformation

Cyral 2.25 adds flexibility for sidecar port definitions in the CloudFormation sidecar template. Users may now freely define ports for the CloudFormation sidecar without being restricted to a predefined set of ports as they were in earlier Cloudformation sidecar templates.

MySQL port multiplexing is disabled by default

For a set of MySQL repositories you've configured to use SSO via Cyral, Cyral allows users to connect to any of these MySQL repositories through a single database port (until now, always port 3306). Database users specify the repository name as part of their username when connecting. Cyral refers to this as "MySQL port multiplexing".

In Cyral 2.24 and earlier, the MySQL port multiplexing feature was enabled by default on port 3306. In Cyral 2.25 and later, this feature is no longer enabled by default. To enable it, you must configure your sidecar to specify the port that will be used as the multiplexed port.

The port chosen as the multiplexed port will fail if it receives a non-multiplexed connection attempt. This means that binding a repository to that port will not work. There is no warning at the UI level, and connections may hang.

Helm template: Enabling a multiplexed port

Templates for Helm-deployed sidecars now have a mysql.multiplexedPort parameter that can be set to enable the feature and specify port will act as the multiplexed port. You can set this parmater in the sidecar deployment file downloaded from the control plane, or set it directly via the CLI.

Editing the yaml file:

mysql:
...
multiplexedPort: 3309

Directly from the CLI

helm upgrade -i cyral-abcdef cyral-sidecar ... --set mysql.multiplexedPort=3309

To disable the multiplexed port, set the variable to 0.

Terraform template: Enabling a multiplexed port

Templates for Terraform-deployed sidecars now have a mysql_multiplexed_port variable that can be set to enable the feature and specify port will act as the multiplexed port.

module "cyral_sidecar" {
...
## Port that will be used by the sidecar to multiplex connections to MySQL.
mysql_multiplexed_port = 3307
...
}

To disable the multiplexed port, set the variable to 0.

Cloudformation template: Enabling a multiplexed port

Templates for Cloudformation-deployed sidecars now have a MySQLMultiplexedPort parameter that can be set to enable the feature and specify port will act as the multiplexed port.

To disable the multiplexed port, set the variable to 0.

Terraform deployment

  • Okta IdP support: New release of Okta IdP module with latest bug fixes

  • Terraform Provider: New release of Cyral Terraform Provider with latest IdP integration and local account fixes

2.24

18 October 2021

Authorization and repository access

  • Early access feature: Granular and dynamic repository access management with ChatOps: Cyral’s app in Slack handles just-in-time repository access requests and approvals.
  • Early access feature: Auto-approval: If an access request falls within the duration limits set by your administrators, Cyral can automatically approve it.

Deployment and provisioning

  • Helm chart changes: Earlier versions of Cyral's Helm chart for the sidecar did not follow best practices for parameter naming. In version 2.24, we've addressed this with a wide-ranging refactor of the chart, including renaming of parameters. See the support article for details. In summary, the changes are:
    • The serviceSidecar.repositoriesSupported variable has been removed. In its place there are specific fields for configuring each repository type.
    • Per-repository image configurations each have their own section in a <repositoryName>.image block.
    • Port configuration can be set in two different ways, either via its <repositoryName>.ports.sidecar section, or via service.ports which overrides other settings.
    • Log integration configurations are no longer set via environment variables, and are now set via specific fields in the filebeat container configuration.
    • Vault integrations no longer need extra volumes to be mounted. Instead, the chart provides a field for specifying the secret to be mounted.

2.23

13 September 2021

Repository support

  • Denodo support
  • Connections to Redshift and Denodo via Tableau

2.22

17 August 2021

Repository support

  • Inline data classification on Snowflake

Identity and SSO

  • Snowflake users who connect from Tableau are now looged with their Tableau identity data
  • Snowflake SSO with Azure Active Directory now supported

Authorization and repository access

  • Support for non-TLS versions of the SQL Server client

2.21

14 July 2021

Repository support

  • MongoDB cluster support
  • Connections to Snowflake via Tableau, R with ODBC, Java JDBC, others

Identity and SSO

  • ADFS (on-premises Active Directory) support
  • Easier integration with Okta

Secrets management

  • Ability to use Cyral's Vault secrets management integration in a Hashicorp Nomad environment

Logging and auditing

  • Logging of blocked queries on Snowflake repositories

2.20

4 June 2021

Repository support

  • New clients supported for SQL Server 2016: SQL Server Management Studio and Powershell

Identity and SSO

  • G Suite identity provider

Authorization and repository access

  • Ability to expose the Cyral auth token in native applications
  • Ability to block PostgreSQL queries that have no LIMIT clause

Secrets management

  • Keycloak support for environments that use Aptible deployment
  • Add sidecar support for Hashicorp Nomad

Logging and auditing

  • Audit logging of connect and disconnect events
  • Ability to insert user's session data as comments in queries, allowing logging to the repository's native log facility.

2.19

7 May 2021

Repository support

  • SQL Server

Identity and SSO

  • ForgeRock
  • Azure Active Directory

Secrets management

  • Support for Hashicorp Vault
  • Keycloak support for environments running all major deployment frameworks

Deployment and provisioning

  • Control plane can be hosted in Google Kubernetes Engine (GKE)

Logging

  • Cyral query log captures session parameters set via SET or SELECT set_config statements. See userConfigParameters in the Log Specification.

2.18

5 April 2021

Repository support

  • Oracle
  • Redshift

Identity and SSO

  • SSO with Forgerock Identity Management (Forgerock IDM)

Authorization and repository access

  • On-call access management integrated with PagerDuty schedules
  • Cyral policies now support rate limiting
  • Cyral policies now support query rewriting on PostgreSQL and Snowflake repositories

2.17

5 March 2021

Upgrade and deployment features

  • Downloadable sidecar templates to simplify rolling upgrades and redeployments
  • Ability to clone a sidecar for blue-green, or parallel, upgrades
  • Standard sidecar template can now contain G Suite SSO settings for Snowflake repositories

2.16

5 February 2021

Identity and SSO

  • Identity mappings are introduced as an improved replacement for explicit grants

Deployment and provisioning

  • Support for autoprovisioning of the Cyral control plane and sidecars
  • Sidecar deployment templates now support enabling/disabling support for a particular repository type. For example, when deploying a sidecar, you can use this feature to turn off PostgreSQL support in that sidecar.
  • Support for provisioning CNAMEs and certificates for Snowflake sidecars
  • Support for Google's GCR and Amazon's ECR container registries for both Cyral control plane and sidecars
  • Improved variable names in sidecar templates to make them more intuitive for users

Logging

  • All sidecar templates now support logging to Sumologic
  • Helm-deployed sidecars now support logging to Splunk and Kafka
  • Improvements in log volume settings: Logging can be set to log full table scans, and the logging facility now supports mixing sensitive log groups with DQL, DML, and DDL log groups.
  • Log volume settings are now customizable on Dremio repositories

Alerts

  • Some Cyral preconfigured alerts are now supported on Snowflake repositories.