Azure Data Explorer breaking changes [Action Required]

Published Jul 27 2022 09:19 AM 785 Views
Microsoft

Making storage url encoding consistent for different export operations (regular and continuous)

Detailed description

The results of export operations (regular or continuous) contain the list of written blobs.

Today url encoding of these blobs’ paths is inconsistent:

  • Exporting to ADLS results with encoded paths
  • Exporting to Blob Storage results with paths that only few special characters in them are encoded.

E.g.:

https://storgaexxx.blob.core.windows.net/xtable/Name='user1'/2022/01/07/41925d7b-c720-479e-aeab-1f74...

abfss://xtable@storgaexxx.dfs.core.windows.net/Name%3D%27User1i%27/2022/01/09/41925d7b-c720-479e-aeab-1f7492eca345_1_8420ac6ce1d44811a3e73bcda12c11c6.csv

 

As the result of the upcoming change, all the special characters will be encoded in the export result paths for both ADLS and Blob Storage

 E.g.:

https://storgaexxx.blob.core.windows.net/xtable/Name%3D%27User1i%27/2022/01/07/41925d7b-c720-479e-ae...

abfss://xtable@storgaexxx.dfs.core.windows.net/Name%3D%27User1i%27/2022/01/09/41925d7b-c720-479e-aeab-1f7492eca345_1_8420ac6ce1d44811a3e73bcda12c11c6.csv

 

Required change 

Check the usage of the export result paths and validate the change above so that it doesn’t break your workflow.

 

Schedule & plan 

Support for non-encoded special characters will be blocked - ETA: October 31, 2022

 

Making tenant name or tenant id a mandatory property for the current_principal_is_member_of() KQL function

Detailed description 

Planned change in the current_principal_is_member_of() KQL function

 

Change details

The `current_principal_is_member_of()` function checks if the principal who runs the query is a member in any of the users, apps or groups provided as arguments.

Up until now, it was allowed to specify the AAD group details in multiple forms, including the display name of the AAD group, without specifying the tenant id or name, for example `current_principal_is_member_of(“mygroup”)`.

There’s a security risk in such usage, since if a user from another tenant has access to the database, he can create a “mygroup” group in his tenant, and suddenly get access to sensitive data, because he’ll now belong to “mygroup” (even though it’s not in the same tenant).

The secure way to do it would be to explicitly specify the tenant’s name or id, next to the group display name, e.g.:

mygroup@mycompany.com”, “mygroup;mycompany.com” or “mygroup;12f94abf-a2fa-91aa-41af-3d71dcd0fb37”.

Another option would be to supply the object-id of the group.

To tighten the security, we’re introducing a change that will fail queries with such insecure use.

 

Required change 

Change the queries that use current_principal_is_member_of() in an insecure way, by adding the tenant name or id to the group name, or switch to using the group’s object-id.

 

Schedule & plan 

The command will no longer work without tenant id, tenant name or group object id - ETA: October 31, 2022

Co-Authors
Version history
Last update:
‎Aug 14 2022 12:46 AM
Updated by: