• Notes
  • Endpoints
    • Public access to blobs
    • DNS
  • Storage account access
    • Shared key access
    • SAS token
• Tasks
  • Create storage account
  • Change access tier of storage account
  • Change replication mode of storage account
  • Retrieve storage account key
  • Renew storage account keys
  • Create Azure Key Vault
  • Create key in Azure Key Vault
  • Create Azure sync group
  • Add endpoints to Azure File Sync Group
  • Upload blob
  • Copy blob
  • Monitor progress of the async blob copy
  • Create SAS token
  • Create container
  • Ensure App Services, backup vault, and event hub have access to a storage account
  • Troubleshoot Azure File Sync
  • Monitoring using Log Analytics
  • Storage account endpoints
• Sources

There are four services provided within each storage account:

1. Blobs provides a highly scalable service for storing arbitrary data objects, such as text or binary data. There can be multiple containers within a storage account, and a container can have its own folder structure. There are three types of blob: page, block, and append blobs.
2. Tables provides a NoSQL-style store for storing structured data. Tables in Azure storage do not require a fixed schema, thus different entries in the same table can have different fields
3. Queues provides reliable message queueing between application components
4. Files provides managed file shares that can be used by VMs or on-premises servers

Options that must be selected when creating a storage account:

• Performance tier
  • Standard supports all storage services and uses magnetic disks to provide cost-efficient and reliable storage
  • Premium only supports page blobs with the locally-redundant (LRS) replication option, uses high-performance SSD disks
• Account kind
  • General-purpose V2: only kind to support ZRS
  • General-purpose V1: does not support various access tiers.
  • Blob storage: specialized storage account used to store block and append blobs
• Replication mode: Storage accounts can be freely moved between the following replication modes, except ZRS, in which case it is recommended to copy data to a new account.
  • Locally-redundant storage (LRS): makes 3 local sychronous within the same Azure facility (zone)
  • Zone-redundant storage (ZRS): makes 3 synchronous copies across multiple availability zones; available for general-purpose v2 storage accounts at Standard performance tier only.
  • Geographically-redundant storage (GRS): makes 3 local synchronous copies plus 3 additional asynchronous copies (typically within 15 minutes, but no SLA) to a second data center far away from the primary region
  • Read-access geographically redundant storage (RA-GRS): makes 3 local synchronous copies plus 3 additional asynchronous copies to a second data center far away from the primary region, which has only read-only access
• Access tier: Both Blob and StorageV1 can be upgraded to StorageV2, a process which is irreversible.
  • Hot blob storage access tier optimized for the frequent access of objects in the storage account
  • Cool blob storage access tier optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days
  • Archive blob storage access tier designed for long-term storage of infrequently-used data that can tolerate several hours of retrieval latency, remaining in the Archive tier for at least 180 days. It is stored offline and can take up to 15 hours for it to be "rehydrated" to the Cool or Hot tier before it can be accessed.
  • Premium providing high-performance access for frequently-used data on SSD, only available from the Block Blob storage account type.

Storage accounts are managed through Azure Resource Manager and management operations are authenticated and authorized using Azure Active Directory.

Every storage account service exposes its own Internet-facing endpoint, which must be secured in one of several ways. A firewall can be implemented by using network rules to limit traffic to particular networks. The storage firewall controls IP addresses and VNets can access the storage account and applies to all storage account services.

Access can be restricted to specific VNets by creating a Virtual Network Service Endpoint, however this still uses the public IP address. Private Link allows similar functionality using private IPs. ^{MS Docs}

Public access to blobs can be restricted at the container level on container creation. By default, no public read access is enabled for anonymous users, but users with RBAC rights or with the storage account name and key can have access. This can be done through ARM APIs, the Portal, or Azure Storage Explorer. Container access levels:

• No public read access: container and blobs can only be accessed by storage account owner (default for new containers)
• Public read-only access for blobs only (container data is not available, and anonymous clients cannot enumerate the blobs within the container)
• Full public read-only access: all container and blob data can be read by anonymous requests:

Access can also be switched between Shared Key-based authentication (relying on storage account keys) and Azure AD authentication, where a RBAC role determines access to a Container. 👉 Authorize access to blobs and queues using Azure Active Directory

Custom domains can be used by implementing CNAME DNS records, which are used in DNS to map alias domain names to the "canonical" name.

Access keys grant full access to all data in all services of a storage account and represent the simplest and most powerful control over access. Access keys are typically used by applications for access to Azure storage, either through a Shared Access Signature (SAS) token or directly accessing the storage itself with the name and key.

Storage account keys were implemented early in the history of Azure and grant full access to the entire storage account. However, it is considered an anti-pattern to distribute this key; a SAS token should be generated for every stored item to be distributed.

Because storage account keys provide write access, a storage account with a ReadOnly resource lock will not enumerate its storage account keys, and users with Read permission will not be able to retrieve the keys either.

SAS tokens are generated from a storage account key; if the key is invalidated then so are all SAS tokens generated from it. The user delegation SAS token itself is meant to be appended to the end of the blob's URI.^{CloudSkills: 40:00}

Click Create a resouce, then Storage, then Storage account. Choose a globally unique name for the account, containing lower-case characters and digits only.

New-AzStorageAccount -ResourceGroupName ExamRefRG -Name mystorage112300 -SkuName Standard_LRS -Location WestUS -Kind StorageV2 -AccessTier Hot

az storage account create --name $accountName --resource-group $resourceGroup -location $location --sku $sku

Set-AzStorageAccount -ResourceGroupName RG -Name $accountName -AccessTier Cool -Force

Set-AzStorageAccount -ResourceGroupName $resourceGroup -Name $accountName -SkuName $type

1. Open storage account
2. Open Access keys blade

New-AzStorageAccountKey

az storage account keys renew

New-AzKeyVault -VaultName $vaultName -ResourceGroupName $g -Location $location 
$key = Add-AzKeyVaultKey -VaultName $vaultName -Name $keyName -Destination 'Software' 
$storageKey = Get-AzStorageAccountKey -ResourceGroupName $g -Name $storageAccount 
$secretvalue = ConvertTo-SecureString $storageKey[0].Value -AsPlainText -Force
$secret = Set-AzKeyVaultSecret -VaultName $vaultName -Name $secretName -SecretValue  $secretvalue

az keyvault create --name $vaultName --resource-group $g --location $location
az keyvault key create --vault-name "$vaultName" --name $keyName --protection "software"
az keyvault secret set --vault-name "$vaultName" --name "$secretName" --value "$secretValue"

$key = Add-AzKeyVaultKey -VaultName $vaultName -Name $keyName -Destination 'Software'
$storageKey = Get-AzStorageAccountKey -ResourceGroupName $g -Name $storageAccount 
$secretvalue = ConvertTo-SecureString $storageKey[0].Value -AsPlainText -Force

$secret = Set-AzKeyVaultSecret -VaultName $vaultName -Name $secretName -SecretValue $secretvalue

az keyvault key create --vault-name $vaultName --name $keyName --protection "software"
az keyvault secret set --vault-name $vaultName --name $secretName --value $secretValue

Specify name of sync group in dialog after creating an Azure File Sync

1. Register a server to the sync group by installing Azure File Sync agent on each server. When installing, you sign in with your subscription's credentials, then register the server by providing the Subscription, Resource Group, and Storage Sync Service names.
2. Click Add Server Endpoint. This will display a dropdown of all servers with the agent installed and associated with the sync service.

az storage blob upload --container-name $containerName --account-name $accountName --account-key $accountKey --file $file --name $blobName

Upload a blob to a container (AzCopy)

AzCopy copy localFilePath https://storageAccount.blob.core.windows.net/destinationContainer/path/to/blob?SASToken

Download a blob from a container (AzCopy)

AzCopy copy https://storageAccount.blob.core.windows.net/sourceContainer/path/to/blob?SASToken localFilePath

$blobCopyState = Start-AzStorageBlobCopy -SrcBlob $blobName -SrcContainer $srcContainer -Context $srcContext -DestContainer $destContainer -DestBlob $vhdName -DestContext $destContext
$srcStorageKey = Get-AzStorageAccountKey -ResourceGroupName $sourceg -Name $srcStorageAccount
$destStorageKey = Get-AzStorageAccountKey -ResourceGroupName $destg -Name $destStorageAccount
$srcContext = New-AzStorageContext -StorageAccountName $srcStorageAccount -StorageAccountKey $srcStorageKey.Value[0]
$destContext = New-AzStorageContext -StorageAccountNAme $destStorageAccount -StorageAccountKey $destStorageKey.Value[0]

# Create new container in destination account
New-AzStorageContainer -Name $destContainer -Context $destContext

# Make the copy
$copiedBlob = Start-AzStorageBlobCopy -SrcBlob $blobName -SrcContainer $srcContainer -Context $srcContext -DestContainer $destContainer -DestBlob $blobName -DestContext $destContext

az storage blob copy start --account-name $destStorageAccount --account-key $destStorageKey --destination-blob $blobName --source-account-name $srcStorageAccount --source-container $srcContainer --source-blob $blobName --source-account-key $srcStorageKey

Use AzCopy to copy a blob

AzCopy /Source:https://sourceblob.blob.core.windows.net/sourcecontainer/ /Dest:https://deststorage.blob.core.windows.net/destcontainer/ /SourceKey:sourcekey /DestKey:destkey /Pattern:disk1.vhd

$copiedBlob | Get-AzStorageBlobCopyState

az storage blob show --account-name $destStorageAccount --account-key $destStorageKey --container-name $destContainer --name $blobName

$storageKey = Get-AzStorageAccountKey -ResourceGroupName $g -Name $accountName
$context = New-AzStorageContext -StorageAccountName $accountName -StorageAccountKey $storageKey[0].Value
$startTime = Get-Date
$endTime = $startTime.AddHours(4)

New-AzStorageBlobSASToken -Container $container -Blob $blob -Permission "rwd" -StartTime $startTime -ExpiryTime $startTime.AddHours(4) -Context $context

az storage blob generate-sas --account-name "storageAccount" --account-key $storageAccountKey --container-name $container --name $blobName --permissions r --expiry "2019-05-31"

$storageKey = Get-AzStorageAccountKey -Name $storageAccount -ResourceGroupName $resourceGroup
$context = New-AzStorageContext -StorageAccountName $storageAccount -StorageAccountKey $storageKey.Value[0]
Set-AzCurrentStorageAccount -Context $context

New-AzStorageContainer -Name $container -Permission Off

Upload file as blob to new container

Set-AzStorageBlobContent -File $localFile -Container $container -Blob $blobName

az storage container create --account-name $storageaccount --name $containername --public-access off

Get-AzVirtualNetwork -ResourceGroupName RG01 -Name VNET01 |
Set-AzVirtualNetworkSubnetConfig -Name VSUBNET01 -AddressPrefix 10.0.0.0/24 -ServiceEndpoint Microsoft.Storage |
Set-AzVirtualNetwork

$subnet = Get-AzVirtualNetwork -ResourceGroupName RG01 -Name VNET01 |
Get-AzVirtualNetworkSubnetConfig -Name VSUBNET01
Add-AzStorageAccountNetworkRule -ResourceGroupName VNET01 -Name Storage01 -VirtualNetworkResourceId $subnet.Id
Update-AzStorageAccountNetworkRuleSet -ResourceGroupName RG01 -Name STORAGE01 -Bypass Azure.Services

Several procedures to be used when Azure File Sync is having issues

Collect logs to troubleshoot issues with Azure File Sync agent installation

StorageSyncAgent.msi /l*v AFSInstaller.log

Remove the server from registered sync group Error message "This server is already registered during registration"

Import-Module "C:\Program Files\Azure\StorageSyncAgent\StorageSync.Management.ServerCmdlets.dll"
Reset-StorageSyncServer

Access Activity Log data (Portal)

1. Find Management + Governance in All Services
2. Open Activity Log
3. Click Logs icon at top of Activity Log view to select an existing Log Analytics (OMS) workspace or create a new one

Display the status of the default NetworkRule for a storage account

Get-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -AccountName $n | Select-Object DefaultAction

az storage account show -$g -n $n --query networkRuleSet.defaultAction

Set default rule

Update-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -Name $n -DefaultAction Deny
Update-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -Name $n -DefaultAction Allow

az storage account update -g $g -n $n --default-action Deny
az storage account update -g $g -n $n --default-action Allow

Sources

• AZ-103 p. 112
• Configure Azure Storage firewalls and virtual networks

1. Specify Microsoft.Storage in the service endpoint settings of the VNet subnet
2. Configure which VNets can access a particular storage account

Display virtual network rules

Get-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -AccountName $n | Select-Object VirtualNetworkRules

az storage account network-rule list -g $g -n $n --query virtualNetworkRules

Enable service endpoint for Azure Storage on an existing virtual network and subnet.

Get-AzVirtualNetwork -ResourceGroupName $g -Name $n | Set-AzVirtualNetworkSubnetConfig -Name "mysubnet" -AddressPrefix "10.0.0.0/24" -ServiceEndpoint "Microsoft.Storage" |   Set-AzVirtualNetwork

az network vnet subnet update -g $g --vnet-name $n --name "mysubnet" --service-endpoints "Microsoft.Storage"

Add network rule for VNet and subnet

$subnet = Get-AzVirtualNetwork -ResourceGroupName $ng -Name $nn | Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"

Add-AzStorageAccountNetworkRule -ResourceGroupName $sg -Name $sn -VirtualNetworkResourceId $subnet.Id

subnetid=$(az network vnet subnet show -g $ng --vnet-name $nn -n "mysubnet" --query id --output tsv)
az storage account network-rule add -g $sg -n $sn --subnet $subnetid

Remove network rule

$subnet = Get-AzVirtualNetwork -ResourceGroupName $ng -Name $nn | 
  Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"

Remove-AzStorageAccountNetworkRule -ResourceGroupName $sg -Name $sn -VirtualNetworkResourceId $subnet.Id

Display exceptions for the storage account network rules

Get-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -Name $n | Select-Object Bypass

az storage account show -g $g -n $n --query networkRuleSet.bypass

Configure exceptions to storage account network rules

Update-AzStorageAccountNetworkRuleSet -ResourceGroupName $g -Name $n -Bypass AzureServices,Metrics,Logging

az storage account update -g $g -n $n --bypass Logging Metrics AzureServices

• AZ-103: 2.1

• AZ-104: 2.1

• Configure Azure Storage firewalls and virtual networks

• AZ-103: p. 107, 114, 127

• Configure Azure Storage firewalls and virtual networks