Skip to main content
Version: v4.5

What's new

4.5​

3 April 2023

Repo-level policies​

Cyral v4.5 adds repo-level policies, which are Cyral out-of-the-box policies you can quickly configure to control users' access to your data. A repo-level policy applies to a repository (for example, a specific database) in Cyral. Repo-level policies supplement Cyral's existing global policies.

Service account resolution for MySQL databases​

This release extends Cyral service account resolution to cover MySQL databases, in addition to the PostgreSQL, Redshift, Snowflake, and DynamoDB database types already supported. This feature allows Cyral to perform identity attribution, tracing requests back to the end users who generated them.

See more information in the Cyral documentation sections for Looker and Tableau.

Use the Cyral CLI Tool to change sidecar log levels​

The Cyral CLI Tool now provides a command to change the sidecar's log level.

To install the CLI Tool, type pip install cyral. To upgrade the CLI Tool, type pip install --upgrade cyral.

You can set the log level per sidecar service or for all sidecar services at once.

To set the log level for all services:

cyral sidecar set log-level --level <LEVEL>

To set the log level for specific services:

cyral sidecar set log-level --level <SERVICE_NAME>:<LEVEL>

where:

  • SERVICE_NAME is the name of the sidecar service and
  • LEVEL is the log level

You can set more than one level in a single command by adding additional --level <SERVICE_NAME>:<LEVEL> flags. For example:

cyral sidecar set log-level --level dispatcher:warn --level pg:debug

Known issues​

See the known issues list.

4.3​

27 March 2023

Snowflake Snowsight support​

This release introduces support for Snowflake's Snowsight client. Earlier Cyral versions supported only the Snowflake Classic Console. Beginning in Cyral 4.3, both the Snowflake Classic Console and Snowsight are supported.

SSO group support for Snowflake​

Cyral can now enforce SSO group-based policies to protect your data stored in Snowflake. To set this up, you must configure group information as part of your enterprise IdP SAML configuration (for example, in Okta or Azure AD) and you must enable SSO for Snowflake in Cyral. When configured in this way, Cyral can enforce group-based policy rules, and the Cyral data activity logs will show the group membership of each user who interacts with Snowflake.

SSO for Snowflake updated to use Snowflake's latest SAML v2 integratation​

Cyral's integration configuration for Snowflake has been updated to use Snowflake's latest SAML2 security integration. For setup steps, see the Cyral document, SSO for Snowflake.

caution

If your Cyral installation v4.2 or earlier uses the Cyral-Snowflake SSO integration, you must update it to the new configuration introduced in Cyral 4.3. Contact Cyral support for instructions.

Better sidecar metrics​

The Cyral sidecar now exposes a port that provides sidecar health metrics following the OpenMetrics specification. By default, all Cyral sidecar metrics are exposed through the metrics endpoint.

CyralContext custom logging for MySQL​

The CyralContext annotation utility now supports MySQL databases, in addition to the already-supported PostgreSQL, Redshift, Denodo, and Snowflake database types. By adding a custom connection driver that uses CyralContext, you can add fields to the Cyral activity logs, supplementing the default logged fields (action, user, description, and time).

4.2​

16 February 2023

Masking for Snowflake and SQL Server databases​

Cyral now enables administrators to configure masking policies for data in Snowflake and SQL Server databases.

Read-only permissions for admins and service accounts​

Cyral 4.2 introduces new administrator permissions you can use to create read-only roles and read-only API Access Keys. Users with these View permissions cannot make changes in the Cyral control plane.

For example, you might use these permissions to create an API Access Key for a read-only service account that runs the Cyral Terraform Provider (running only terraform plan) in a CI/CD pipeline that is only allowed to assess differences in the environment.

The new permissions are View Roles, View Users, View Policies, and View Integrations. For details, see Create an API access key.

4.1​

1 February 2023

Blocking and dataset rewriting are supported on SQL Server​

This release adds support for the following policy actions on SQL Server repositories:

4.0​

22 January 2023

Smart Ports​

Cyral 4.0 introduces Smart Ports, which let you configure multiple data repositories behind a single network port in the Cyral sidecar. This gives you a more straightforward sidecar infrastructure configuration by removing the need for managing multiple ports in network load balancers, VPNs, or routing tables. This is particularly useful when managing dozens or hundreds of data repositories behind a single Cyral sidecar.

Smart Ports are supported on MySQL, MariaDB, PostgreSQL, Denodo, and Redshift repositories.

3.2​

20 December 2022

Tags in datamaps and policies​

This release introduced support for tags in Postgres repositories only, allowing you to apply Cyral policies to categories of data, rather than just labelled data locations. While labels remain the primary classification for data items that you protect with Cyral policies, starting in this release we also support tags that you can apply to labels to sort them into categories.

As a rule of thumb, a label represents the real-world meaning of the data stored at a protected data location, and a tag represents regulatory class or categrory that location's data falls within.

Tags are not directly assigned to data locations but to labels. A tag represents a categorization for a particular kind of information. A given label may have more than one tag and a given tag may be applied to multiple labels. As an example, the label CCN might have the tags PII (personally identifiable information), FSI (financially sensitive information), and PCI (PCI relevant information). The tag PII may also be applied to other labels such as Name, Address, SSN, DOB, and so on.

Support for case-sensitive identifiers in queries.​

This release includes changes to Cyral's handling of Postgres, Oracle, SQL Server, MySQL and Redshift repositories, introducing support for case-sensitive identifiers in queries.

Postgres prepared statement support for Simple Query Protocol​

Fix for issue with Service Account Resolution ticker​

Improvements in handling of the search path for data repositories​

3.1​

17 November 2022

Local account discovery​

Use Cyral local account discovery to find all the database accounts that have access to your repository. This helps you find accounts that should have been deprovisioned but remain active as well as accounts that lack known provenance and might be used for unauthorized access.

Local account discovery is supported only on Oracle and SQL Server repositories.

Support for PostgreSQL 14 databases​

Cyral can now protect PostgreSQL databases of all recent versions including PostgreSQL 14.

3.0​

28 September 2022

Access rules and identity maps​

Cyral has always provided controls to administrators specify who can connect to a repository via a given database account, ways to set preconditions for and limits on the user's connection time. In the 3.0 release, we have consolidated these parts of the product into access rules, which you can manage in the User Authentication tab of your repository's page in the Cyral control plane UI, or via the Access Rules endpoints of the API.

As in earlier releases, Cyral logs the SSO identity associated with every data action. Each access rule is also an identity map that maps an SSO user to the database account they're using to connect to the repository. In earlier releases, this was managed in the "Track Account" and "Local Account" sections of the repository management page.

Approvals: Better ways to handle user access requests​

Earlier versions of Cyral allowed users to request access to repositories and get administrators' approvals on those requests. In the 3.0 release, Cyral has made this feature easier to use with the following changes:

  • a new approvals tab in the repository management page to make it easy for administrators to track and approve access requests;
  • a new Approvals API that allows your organization to build its own data access request and approval applications; and
  • improvements to the Access Portal to make it easier for data users to request access.

With Cyral, data users can request access to a repository, get an approval from an admin, and connect to the repository for the approved amount of time. Administrators (we call them "approvers" in this context) manage and view approval requests in the Approvals tab of each repository.

New names in Cyral​

We've renamed a few things for clarity:

  • Cyral activity logs are now called Cyral audit logs. The data activity logs that record queries and other interaction with repositories keep the same name, data activity logs.

  • Cyral service accounts are now called API access keys.

  • Cyral identity maps are now called access rules and local accounts are now called database accounts.

Known issues​

See the known issues list.

2.34​

2 August 2022

Support for Amazon DynamoDB​

This release adds the ability to track a DynamoDB repository. Data users can connect using the AWS CLI or an AWS SDK.

Failover-to-passthrough mode has been renamed to resiliency mode and is enabled by default​

Sidecars can be run in a mode that preserves uninterrupted access to data by maintaining database connections, even if a partial software failure happens in the sidecar. Previously this mode was called failover to passthrough mode. It has been renamed to resiliency mode.

In earlier versions, this mode was turned OFF by default for a new sidecar. It is now turned ON by default.

Resiliency mode is available for Amazon S3 storage​

Cyral sidecars protecting S3 storage can now be run in resiliency mode.

Network shield is available for Oracle databases​

Cyral's Network Shield is now available for Oracle repositories.

2.33​

18 July 2022

Multi-factor authentication with Duo MFA​

You can use Cyral to require Duo multi-factor authentication for data users. Add an access condition on any supported repository to require its users to complete Duo MFA authentication each time they access the repository.

Generic SAML-2.0 integration to support more SSO identity providers​

With Cyral, you can SSO-authenticate database users and Cyral administrators against your SAML 2.0 identity provider (IdP). For SAML 2.0-based identity providers that are not already covered by Cyral's standard integrations, this release introduces a generic SAML-2.0 integration capability.

2.32​

3 June 2022

Secrets management: Store credentials in Kubernetes Secrets or GCP Secrets​

When adding local accounts for registered repos in Cyral, local account credentials can now be stored in either Kubernetes Secrets or Google Cloud Secret Manager (GCP Secrets). This adds two more storage alternatives on top of Cyral's existing support for AWS Secrets Manager and Hashicorp Vault.

The Cyral control plane does not read local account credentials. Instead, the Cyral sidecar retrieves them from your secrets manager and uses them to authenticate to the data repository. For details, see this Cyral documentation page and click the tab for your secrets manager.

New tags to help users find repositories in the Cyral Access Portal​

Administrators have been able to add tags to repositories they've registered in Cyral, making it easier to find each repository in the Cyral UI.

Starting in the 2.32 release, you can use tags to label a repository in the Cyral Access Portal. For example, for a team that uses hundreds of RDS instances, adding memorable tags to the most frequently used RDS instances makes them easy to find.

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.

Pre-built SIEM dashboard for Splunk to centralize data activity monitoring​

Cyral's new SIEM dashboard for Splunk helps administrators identify suspicious activity and anomalies in the data stack. Contact Cyral support to get the dashboard.

Cyral activity logs show when a data repository's tracking in Cyral is added or modified​

The Cyral activity logs now show when a data repository's tracking in Cyral is added or modified. Logged event types include when a data repository's entry in Cyral is created, updated, or deleted, and also when a repository is bound to a new sidecar or removed from its sidecar in Cyral.

To see these events in your logs, look for the action types like repo.create and repo-binding.upsert.

Port multiplexing for MySQL in the Access Portal​

The Cyral Access Portal now supports port multiplexing for RDS MySQL repositories. This allows the administrator to provide Cyral-assisted login when multiple RDS MySQL instances are accepting user connections on the same port. For a user who has successfully authenticated using the configured identity provider, the Access Portal provides a connection string that includes the repository name.

This feature works for identity provider-authenticated users only, and not for users who sign in with native MySQL credentials.

To set this up, configure the multiplexed port on both the Cyral control plane and sidecar using the CFT parameter MySQLMultiplexedPort. Make sure the sidecar's multiplexed port and the control plane's configured multiplexed port are set to the same value.

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.