Skip to main content
Version: v4.14

What's new

4.14​

14 June 2024

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Activity log changes​

Cyral Activity logs are changed to replace policyViolations field by triggeredPolicies field. More details can be found here.

Azure Key Vault support for Database account secrets​

Introduces support for Azure Key Vault as a secrets storage. Database account secrets can now be securely stored in Azure Key Vault and accessed directly by a sidecar. More details can be found here.

CTAS, CVAS and INSERT INTO support for Redshift​

Now, Cyral users can leverage Create Table As Select (CTAS), Create View As Select (CVAS), and INSERT INTO operations within their Redshift environments. This enhancement empowers Cyral Admins with the ability to identify sensitive field access and apply policies when data users use these statements in their queries.

Improvements to Repo audit logging​

Repo audit logging functionality is enhanced to log repo level config changes related to alerting, authentication, logging, policy enforcement, and TLS.

Native ELK logging integration deprecation​

The native logging integration with ELK is deprecated in favor of the custom logging integration. Existing ELK integrations will work normally, but we recommend you to replace them by custom logging integrations, configured to send logs to Elasticsearch, as the native option will be removed in a future release.

New Helm chart for the Cyral sidecar​

A brand new Helm chart is available to deploy Cyral sidecars in Kubernetes clusters. This new chart has been completely rewritten to leverage the new features of the sidecar and is the recommended approach for Kubernetes deployments going forwards. More details can be found here.

Stored Procedure Governance repo-level policy​

Introduces a new repository-level policy, allowing Cyral Admins to regulate execute access to specified Stored Procedures within a designated data repository. This capability is now available for Denodo, MySQL, MariaDB, Oracle, PostgreSQL, Redshift, and SQL Server repository types.

4.13​

1 March 2024

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Amazon Redshift native IdP federation with Microsoft Azure AD​

This release introduces the support to secure Amazon Redshift repositories with Cyral where native identity provider (IdP) federation with Microsoft Azure Active Directory (Azure AD) is used. Once the Cyral sidecar is associated with a Amazon Redshift repository, you can monitor data access activity and write Cyral policies to restrict data access. More details can be found here.

UI improvements​

As we improve the product terminology and simplify the UI navigation to make it simple and easy to use, the following changes are introduced in this release:

  • Renamed tabs in the Data Repo details page:
    • Changed User Authentication to Access Rules.
    • Changed Datamap to Data Labels.
  • Updates in the left navigation bar:
    • Renamed Help & Support link Docs & Support.
    • Moved Cyral API Docs link to Docs & Support.

4.12​

28 December 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Cyral Access Token improvements​

This release introduces enhancements to the utilization, administration and configuration of Cyral Access Tokens. Users now have the ability to effectively manage (create, edit, and delete) multiple access tokens, each with its specified validity period set during creation.

Furthermore, administrators can now configure access tokens settings, specifying parameters such as the maximum and default token validity period, the maximum number of tokens allowed per user, and enabling offline access token validation.

The new offline access token validation, enabled by default, allows sidecars to validate and authenticate database access even when the Cyral control plane is temporarily inaccessible, like during a control plane upgrade or outage.

These enhancements are also supported by the Cyral CLI.

For more details, see:

Request Access form accessible through URL​

You are now able to directly access the Request Access form through a URL, allowing you to share it with users who need to request access to a repository. You can also pre-populate the form by adding specific query parameters to the URL.

For more details, see Directly link to the Request Access form

Service Account Resolution (SAR) for Custom Applications through CyralContext​

SAR through CyralContext annotations was already supported in previous releases. This release adds support to create and manage configuration through Cyral Control Plane as part of Apps and BI tools menu inside repository configuration.

For more details, see:

4.11​

16 November 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Dynamic queries using sp_executesql for SQL Server repositories​

EXEC|EXECUTE command support was introduced in previous [release][https://cyral.com/docs/release-notes/whats-new#execute-command-support-for-sql-server-repository] of Cyral for SQL Server. This release extends this support for executing Dynamic queries using sp_executesql command.

Revamped navigation experience for Cyral documentation​

The Cyral documentation is reorganized with a revamped navigation experience for increased clarity and efficiency. The restructuring focuses on optimizing the layout and information flow to enhance the user experience. The goal is to provide users with an easily navigable and logically structured documentation resource.

Tags in datamaps and policies for Snowflake repositories​

Introduces support for tags in Snowflake repositories, 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.

4.10​

11 October 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

1-click upgrade​

Starting in v4.10, sidecars running on our AWS EC2 deployment templates support upgrades with a click of a button in the Cyral control plane. This means that administrators can use an automated process that does not require interaction with the underlying deployment infrastructure to apply a patch or a minor version upgrade of a sidecar.

Refer to the sidecar upgrade procedures for more information.

Cyral control planes now support AWS PrivateLink for customers looking for enhanced security.

Reach out to our customer success team for more information.

Datadog metrics support changes​

Native sidecar support for Datadog metrics has been removed in sidecars v4.10+ (Datadog logging support remains unchanged). If you are using the Datadog metrics integration, and wish to keep using a Datadog agent container within the sidecar follow the v4.10 upgrade procedures.

dbt Core for Snowflake​

dbt is a data transformation workflow used by data teams. This release introduces support for Snowflake repositories used in dbt Core deployments.

Snowsight improvements in visualizing rewritten queries in worksheets​

When Cyral row limiting, masking or dataset rewrite policies are enabled for a Snowflake repository, Cyral sidecar rewrites user queries in order to apply the policies. In previous releases, the original user query was replaced with a rewritten query which brought in an inconvenience of not being able to rerun the rewritten query.

This release fixes this issue where the original user query is not rewritten, but retained as is allowing it to be executed after. In certain scenarios, data users will observe that the end of the worksheet is populated by the rewritten query or a catalog query with a note asking users to ignore this section and not to use.

Here is an example section that is shown at the end of a snowsight worksheet

// ***>>> IGNORE EVERYTHING BELOW THIS LINE.
// ***>>> The following modified query stamps auto generated by the company's governance and privacy policies and do not impact your worksheet.

EXECUTE command support for SQL Server repository​

EXEC|EXECUTE command is now supported for SQL Server. The command EXEC/EXECUTE (@local_variable | <query string>) lets you create and execute SQL queries, which is commonly used for Dynamic SQL execution.

IAM Authentication support for MongoDB Atlas​

AWS IAM Role based authentication is now supported, enabling data users and services to authenticate to Cyral using AWS IAM authentication while connecting to a database. This feature is currently available for MongoDB repositories. For more details, see AWS IAM Role based authentication.

Public sidecar images​

Sidecar images are now available in a public registry, meaning that container registry credentials are no longer needed to deploy or upgrade a sidecar.

The new public registry is part of all examples in our Cyral Quickstart page and will be used transparently by all new sidecars created with one of our Cyral Quickstart guides.

Refer to the sidecar upgrade procedures to upgrade an existing sidecar.

Public sidecar templates​

Sidecar deployment templates will no longer be downloaded from the control plane and are now publicly available in our Cyral Quickstart page.

This change entails for less impact in upgrades after v4.10.0 as the upgrade steps will no longer require re-downloading a template, managing new credentials or comparing source code changes.

Simplified credentials management​

Up to v4.9, sidecar credentials (client id and client secret) were managed automatically by the control plane. In these previous releases, the control plane marks all old credentials for deletion once a new set of credentials for that same sidecar is used to connect to the control plane.

Starting in v4.10, sidecar credentials are completely managed by the administrators as any conventional system, meaning that once created, a set of credentials will still be valid until the administrator explicitly deletes them and replaces by a new set of client id and client secret. Read more in the sidecar credentials page.

Smart Ports for SQL Server repositories​

Smart Ports lets you configure multiple data repositories behind a single network port in the Cyral sidecar. This release adds Smart Ports feature support for SQL Server repositories. This feature is already supported for Denodo, MariaDB, MySQL, PostgreSQL and Redshift repositories.

Support for Redshift UNLOAD​

To unload data from database tables to a set of files in Amazon S3 bucket, you can use UNLOAD command with a SELECT statement. This release introduces support for UNLOAD command, i.e., Cyral can identify sensitive field access and lets you apply policies.

4.9​

4 August 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Data Masking for Oracle​

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

Custom Data Masking functions​

Custom Data Masking functionality allows administrators to bring their own data masking techniques catering to any custom data masking use cases and integrate with Cyral. Cyral currently provides null mask, constant mask and format preserving mask as out of the box data masking techniques. Custom data masking is an extension to this, providing customizability, extensibility and flexibility that caters to custom use cases.

Metabase BI tool for PostgreSQL and Oracle​

Metabase can now be used with Cyral for PostgreSQL and Oracle repositories.

New UI for log integrations​

The process of configuring logging integrations has been streamlined and simplified. All logging integrations should now be configured via the Logging card on the Integrations page. The integration cards for Datadog, ELK, Splunk, and Sumo Logic have been removed and consolidated under the single Logging card. Please refer to the Integrations -> Logs -> Overview page for more details.

Support for Amazon CloudWatch and custom (Fluent Bit) logging integrations​

Amazon CloudWatch can now be configured as a logging integration. Please see Integrations -> Logs -> Amazon CloudWatch for more details.

Custom (Fluent Bit) logging integrations can now be configured as well. Custom logging integrations opens the door for users to customize how sidecar logs are shipped to various log management destinations, if they do not wish to use Cyral's standard set of existing logging integrations. Please see Integrations -> Logs -> Custom (Fluent Bit) for more details.

4.8​

30 June 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Blocking, dataset rewriting and row limiting are supported on Oracle​

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

Repo audit logging​

Introduces new audit logging capability at repository level. Administrators can now access the repository audit logs from the Audit Report tab from each repository. The repository audit logs lists events triggered by Datamap, Access Rules, Network Access and Approval operations.

Repo crawler improvements​

The Repo Crawler has been enhanced to simplify its usage. It no longer requires a local DynamoDB or SQLite cache to keep track of its past classification recommendations, and will default to using the Cyral Control Plane as its source of record (the DynamoDB and SQLite caches are still supported). Additionally, the repository type, hostname, port, and database username are now optional runtime parameters. If omitted, these will be retrieved from the Control Plane (note that the database username is still required there are more than one database accounts registered to the Cyral repository). Finally, the database name parameter is now optional. If omitted, the Crawler will attempt to crawl all the discoverable databases on the server.

Separate sidecar configurations for activity and diagnostic logs​

Sidecars can now have independent logging integrations for data activity logs and diagnostic logs. This can be useful for users who wish to manage their Cyral data activity logs separately from their diagnostic logs. For example, one might chose to send activity logs to their monitoring system (e.g. Datadog), but diagnostic logs to their local Elasticsearch cluster. The sidecar's mapped logging integrations can be configured using the Cyral Terraform provider or via the API, by setting the logIntegrationID and diagnosticLogIntegrationID properties respectively.

Service account resolution for SQL Server databases​

This release extends Cyral service account resolution to cover SQL Server databases, in addition to the PostgreSQL, MySQL, 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.

4.7​

8 June 2023

note

Refer to the Sidecar upgrade procedures page if you are upgrading an existing sidecar.

Automatic Instance Refresh​

The existing Terraform module for deploying sidecars to AWS EC2 was updated to perform automatic instance refresh to the Auto Scaling Group when changes are made to the launch template, like version upgrades. See the module change log for more details.

Data Masking for MySQL​

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

Enhanced Certificate Handling​

Administrators can now provide a custom CA certificate to be used by S3 and DynamoDB repositories, similarly to the existing support for custom certificates for TLS connectivity. This change simplifies the configuration to supply certificates (CA and TLS) to sidecars as the whole setup is performed exclusively during sidecar deployment on the customer environment, eliminating the previous configuration step in the control plane.

New Terraform resource for configuring logging integrations​

The new Cyral Terraform provider resource, cyral_integration_logging, offers a simplified and uniform way for users to configure how the sidecar sends logs to various log management destinations. See the resource documentation for more details and examples.

Sidecar monitoring​

Introduces a single port to allow administrators to monitor sidecar instances. Metrics conforming to OpenMetrics specification and a detailed health check status can be retrieved from different routes on port 9000 from each sidecar instance. This update simplifies the sidecar deployment configuration as a single port is configured to monitor the whole instance. See the metrics and health monitoring pages for more details.

Support for MongoDB sharded clusters and SRV entry for clusters​

Added support for MongoDB sharded clusters. MongoDB standalone servers and MongoDB replica set clusters are already supported. For MongoDB sharded clusters and replica set clusters, there is a provision to add SRV instead of adding individual node details.

Tags in datamaps and policies​

Introduces support for tags in MySQL repositories, 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.

4.6​

1 May 2023

Deprecation of vendor-specific IdP integrations​

The vendor-specific Identity Provider (IdP) integrations Azure, GSuite, Microsoft ADFS and Okta have been deprecated in favor of a unified SAML IdP integration option in the UI, API and Terraform provider. Existing vendor-specific IdP integrations will continue to work normally, and end users logging in to Cyral using SSO will not be affected. Creation of new vendor-specific IdP integrations is no longer supported - use the SAML integration to configure new IdP integrations.

Rate Limit policies for Snowflake​

Rate limit policies are now supported for Snowflake. This is used to limit the number of rows a user is allowed to read, update, and/or delete per hour. Please see Rate Limit Policies for more information.

Enhanced Dynamic Logging integration configuration​

Introduces improvements that streamline the management of Cyral data activity logs emitted by the sidecar. This update empowers Cyral Administrators with dynamic control over configuring the sidecar logging destination to Datadog, ELK, Sumo Logic, or Splunk directly from the control plane. Changes to logging integration configurations will take effect without the need to re-deploy the sidecar. Please note that this feature is supported in all sidecar deployment profiles, with the exception of the Linux sidecar (rpm/deb package).

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 Access Rules 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 Sidecar Logging.

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.