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 andLEVEL
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:
- Blocking access to data
- Rewriting datasets returned by queries
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.
Oracle database links supported through the Cyral sidecar
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 viaservice.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.
- The
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
orSELECT set_config
statements. SeeuserConfigParameters
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.