Release Notes for Styra DAS
This page provides Styra DAS SaaS Release Notes for May 2024.
May 22, 2024
The Styra DAS 20240522 release delivers the following changes.
New Features and Changes
Improved Git sync frequency
The Git sync process has been improved to decouple syncs from Tenant sync cycles to ensure Git syncs occur more closely to every 60 seconds. Git sync status now also includes additional metrics to assist in identifying slow Git syncs, including previous sync timestamp, current sync start timestamp, and sync duration.
Fixed Issues
Creation and subsequent deletion of system could trigger bundle rebuilds
Bundle rebuilds for all systems could be triggered after the creation and subsequent deletion of a system.
Decision mask drop action in Stack was not applied
Adding a drop action to a Stack decision mask did not drop decisions as expected.
Entitlements built-in library rules shown outside of Policy package
The built-in library rules for the Entitlements system type were shown outside of the Policy package namespace.
Editor autocomplete shown when moving cursor or clicking
The DAS UI editor autocomplete suggestions were shown on cursor move or mouse click rather than just after keyboard changes.
May 15, 2024
The Styra DAS 20240515 release delivers the following changes.
New Features and Changes
Beta UI Additions
The Push datasource contents are now editable in the new Beta UI.
May 10, 2024
The Styra DAS 20240510 release delivers the following changes.
New Features and Changes
HTTP Datasource timeout parameter
HTTP datasources now support specifying an optional timeout parameter via the PUT /v1/datasources/{datasource} endpoint, which defaults to 60 seconds. Previously HTTP datasources had an implicit 1 hour timeout which was not configurable by the user. This parameter will be added to the UI in an upcoming release.
Fixed Issues
Git sync failure and errors when fetching policies from Git branches
In rare cases, Git sync could fail for a tenant due to a conflict between multi-thread processes accessing the same Git repository copy in DAS. This could also result in API request errors when fetching files from a Git branch for that repository.
May 6, 2024
The Styra DAS 20240506 release delivers the following changes.
New Features and Changes
Datasource Agent status in Deployments
The Deployments tab now reports the status and version of the Datasource Agent connected to the System when using Datasource Agent v1.5.4 or later. Customers with existing Datasource Agent deployments who would like to see the Datasource Agent status reported should delete the existing Datasource Agent API token (token ending in datasources-agent) in the associated system, download a new manifest from the Install instructions for that system, and update their Datasource Agent deployment.
Fixed Issues
Git status update failure for some new tenants
Some new tenants with Git-backed resources experienced Git status update failures resulting in failed Git syncs.
May 2, 2024
The Styra DAS 20240502 release delivers the following changes.
New Features and Changes
Upgraded to OPA v0.64.1
The internal version of OPA used by Styra DAS has now been upgraded to OPA 0.64.1.
Beta UI Additions
Added support for the Okta datasource in the new UI.
Git sync status improvements
Improved the speed and consistency of Git sync status updates by batching and unifying update processes.
Fixed Issues
Datasource Agent receives 403 for agent status publishing with authz v2
Agent status updates from the Datasource Agent without an associated System ID receive a 403 when the tenant has authz v2 enabled. In these scenarios, the Datasource Agent will stop further agent status update requests, and the Datasource Agent version will not be displayed in the Deployments tab. This behavior only affects agent status updates (i.e., agent version and status) and does not impact datasource status updates. The Datasource Agent manifest for the Kubernetes System install instructions has been updated to include the STYRA_SYSTEM_ID env variable. Customers using the Datasource Agent in other Systems can manually update their Datasource Agent configurations to include the System ID. Customers using a single Datasource Agent to run datasources for multiple Systems or Stacks should omit the System ID from the configuration to prevent the agent from filtering datasources to only those for the configured System ID.
Decision replay fails for Systems with invalid policies
For Systems with invalid policies (e.g., an invalid import reference), decision replay would fail without any error indication.
Decision replay fails for Custom Systems without Library data
For some Custom system configurations, decision replay could fail if the system did not import any Library data.
Library with default name conflicts with Workspace policies
Using the package name default for a Git-backed Library name could result in conflicts with Workspace-level Git-backed policies.