robcaronUsed to work on Visual Studio, now on Azure.
Niner since 2004
US Navy nuke veteran (S1C/A4W/D2G). Visual Basic & ASP dev back in the day. Technical writer, developer marketing, etc. Now at Microsoft working on Azure, snowboarding Whistler or traveling when I'm not.
When we talk about CI/CD, we're really talking about several related processes: Continuous integration, continuous delivery, and continuous deployment.
Continuous integration. Code changes are frequently merged into the main branch. Automated build and test processes ensure that code in the main branch is always production-quality.
Continuous delivery. Any code changes that pass the CI process are automatically published to a production-like environment. Deployment into the live production environment may require manual approval, but is otherwise automated. The goal is that your code should always be ready to deploy into production.
Continuous deployment. Code changes that pass the previous two steps are automatically deployed into production.
The requirement for RBAC reader role no longer applies to the variety of tools & frameworks that integrate with ADLS Gen2. This means that you can choose coarse-grained access mechanisms via RBAC or fine-grained access via ACL or a combination of both.
Access control via ACLs-only does require special handling is some tools (eg. for Azure Storage Explorer you need the v1.9+ to ‘mount’ an ADLS Gen2 container as the user will not be able to browse to that account).
I am able to confirm that Azure SQL Data Warehouse’s Polybase capability does indeed work in being able to reference data in ADLS Gen2 using the system-assigned MSI when that MSI only has ACL access and not RBAC access.
There are 2 things to consider when applying ACLs in ADLS Gen2:
1. Irrespective on where the MSI is granted read ‘R’ and/or write ‘W’ access, the principal MUST have execute ‘X’ permission from the root directory all the way down to the data directory. This allows the MSI to traverse the directory structure and will fail without this permission.
2. The ‘Principal ID’ of the MSI must be the guid value specified in the ACL. This can be obtained using the Powershell ‘Get-AzSqlServer’ cmdlet.
Correct - we kept the title for consistency with how it was billed at Build; unfortunately, we were pressed for time and didn't get through all of Ralph's content. We're going to schedule him for an in-studio episode soon.
@Bazul - With an ASE there's no public endpoint. When using the hosted agent for Azure Pipelines, they're not placed in a VNet, so they can't communicate with a node inside ASE ("myappservice.scm.na.cloud.mycompany" won't resolve in the public internet).
Azure DevOps Portal can see the ASE only because Azure DevOps is communicating with the Azure Resource Manager APIs, which are confirming that the resource exists and are giving the endpoint. But the Azure Resource Manager APIs cannot allow deployments, which require a communication with Kudu running on the ASE nodes.