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
