Table of Contents
Open Table of Contents
Résumé pour la direction
Scenario
Dans ce laboratoire, l’objectif était de provisionner un compte de stockage Azure ainsi qu’un conteneur Blob configuré avec un accès en lecture anonyme de type Container/Public. Le besoin technique consistait à activer l’accès public au niveau du compte de stockage, puis à créer un conteneur accessible sans authentification.
D’un point de vue métier, ce type de configuration peut répondre à des cas d’usage très spécifiques, comme la diffusion de contenus statiques publics. Toutefois, lorsqu’il est question de données de migration, de fichiers internes, de journaux techniques ou de contenus non destinés au public, cette approche entre directement en conflit avec les principes de sécurité, de confidentialité et de gouvernance cloud.
Le principe même de ce laboratoire est fortement déconseillé pour toute donnée métier réelle. Stocker des données de migration dans un conteneur Blob public constitue un risque majeur de fuite d’information et peut mener à une violation de données. Tout utilisateur disposant de l’URL peut lire les objets publiés, sans authentification. Les conteneurs publics ne doivent être utilisés que pour des ressources web non sensibles comme des images publiques, des feuilles de style CSS, des polices ou des fichiers JavaScript destinés à être diffusés librement. Pour tout contenu métier, il faut privilégier des mécanismes sécurisés : conteneurs privés, SAS temporaires, RBAC Azure, Private Endpoints, et des politiques de gouvernance bloquant l’exposition publique.
Resolution
Le déploiement a abouti à la création logique d’un compte de stockage datacenterst32222 et d’un conteneur datacenter-blob-8567 configuré en accès public au niveau Container. La validation attendue consistait à confirmer que l’accès anonyme était autorisé au niveau du compte, puis que le conteneur héritait bien d’une stratégie de lecture publique.
La valeur livrée sur le plan technique réside dans la démonstration d’un déploiement reproductible via Azure CLI et PowerShell, en remplacement d’une opération purement graphique. La valeur métier, elle, est surtout pédagogique : montrer comment cette configuration fonctionne, tout en documentant clairement pourquoi elle ne doit pas être utilisée pour des données sensibles.
Technical Implementation
Topology
The implementation targets a simple Azure Blob Storage exposure pattern:
- Storage Account:
datacenterst32222 - Blob Container:
datacenter-blob-8567 - Anonymous Access Setting: Enabled at the storage account level
- Container Access Level:
blobpublic access equivalent to container-level anonymous read exposure for listed content, depending on command semantics and platform behavior
This is a headless / CLI-first deployment model intended for repeatable lab execution and portfolio demonstration. The design avoids unnecessary complexity and focuses on native Azure capabilities rather than over-engineered orchestration.

Public blob access requires alignment between the storage account setting and the container access level. If anonymous access is disabled at the account level, public container permissions alone are not sufficient.
A minimal parameter set is enough for this lab. The only prerequisite is an Azure resource group and a globally unique storage account name.
Action
The steps below convert the lab objective into reproducible Infrastructure as Code style execution using both Azure CLI and Azure PowerShell.
1. Create the storage account with anonymous blob access enabled
#!/usr/bin/env bash
set -euo pipefail
# Remplacer par le nom du groupe de ressources fourni dans le laboratoire
RESOURCE_GROUP="<RESOURCE_GROUP_NAME>"
LOCATION="eastus"
STORAGE_ACCOUNT="datacenterst32222"
CONTAINER_NAME="datacenter-blob-8567"
az storage account create \
--name "$STORAGE_ACCOUNT" \
--resource-group "$RESOURCE_GROUP" \
--location "$LOCATION" \
--sku Standard_LRS \
--kind StorageV2 \
--allow-blob-public-access truecreate-public-blob-container.sh
2. Create the public blob container with anonymous read access
#!/usr/bin/env bash
set -euo pipefail
STORAGE_ACCOUNT="datacenterst32222"
CONTAINER_NAME="datacenter-blob-8567"
az storage container create \
--name "$CONTAINER_NAME" \
--account-name "$STORAGE_ACCOUNT" \
--auth-mode login \
--public-access containercreate-container-cli.sh
3. Validate the configuration with Azure CLI
#!/usr/bin/env bash
set -euo pipefail
STORAGE_ACCOUNT="datacenterst32222"
CONTAINER_NAME="datacenter-blob-8567"
az storage account show \
--name "$STORAGE_ACCOUNT" \
--query "{name:name,allowBlobPublicAccess:allowBlobPublicAccess}" \
--output table
az storage container show \
--name "$CONTAINER_NAME" \
--account-name "$STORAGE_ACCOUNT" \
--auth-mode login \
--query "{name:name,publicAccess:properties.publicAccess}" \
--output tablevalidate-container-cli.sh
4. Equivalent Azure PowerShell implementation
# Remplacer par le nom du groupe de ressources fourni dans le laboratoire
$ResourceGroup = "<RESOURCE_GROUP_NAME>"
$Location = "eastus"
$StorageAccount = "datacenterst32222"
$ContainerName = "datacenter-blob-8567"
$storage = New-AzStorageAccount `
-ResourceGroupName $ResourceGroup `
-Name $StorageAccount `
-Location $Location `
-SkuName Standard_LRS `
-Kind StorageV2 `
-AllowBlobPublicAccess $true
New-AzStorageContainer `
-Name $ContainerName `
-Context $storage.Context `
-Permission Containercreate-public-blob-container.ps1
5. Validate the configuration with PowerShell
$ResourceGroup = "<RESOURCE_GROUP_NAME>"
$StorageAccount = "datacenterst32222"
$ContainerName = "datacenter-blob-8567"
$storage = Get-AzStorageAccount `
-ResourceGroupName $ResourceGroup `
-Name $StorageAccount
$container = Get-AzStorageContainer `
-Name $ContainerName `
-Context $storage.Context
[PSCustomObject]@{
StorageAccount = $storage.StorageAccountName
AllowBlobPublicAccess = $storage.AllowBlobPublicAccess
ContainerName = $container.Name
PublicAccess = $container.PublicAccess
}validate-public-blob-container.ps1
Do not use this pattern for confidential files, migration datasets, exports, backups, or internal application data. If anonymous access is needed temporarily, prefer short-lived SAS tokens instead of a permanently public container.
This lab demonstrates a successful transition from portal-based configuration to script-based deployment using Azure CLI and Azure PowerShell, improving repeatability, auditability, and operational consistency.