Azure Files artıq SMB girişləri üçün managed identity modelini ümumi istifadəyə açıb. Bu, Windows və Linux sistemlərində storage account key, parol və ya ayrıca secret paylaşmadan SMB share mount etməyə imkan verir. Əsas şərtlər bunlardır: storage account üzərində SMBOAuth aktiv olmalıdır, uyğun Azure RBAC rolu — məsələn Storage File Data SMB MI Admin — verilməlidir və klient tərəfdə Kerberos credential yenilənməsi düzgün qurulmalıdır. AKS üçün isə vacib bir detal var: Azure Files capability-si GA olsa da, AKS CSI üzərindən managed identity və workload identity mount ssenariləri hələ sənədlərdə preview kimi göstərilir; managed identity AKS 1.34-dən, workload identity isə AKS 1.35.0-dan başlayır və Linux node-lar üçün sənədləşdirilib.
İcra xülasəsi
20 aprel 2026 tarixli bu yenilik ona görə əhəmiyyətlidir ki, Azure Files üçün SMB girişini shared key modelindən identity-first modelinə keçirir. Microsoft-un elanında üç əsas dəyişiklik vurğulanır: managed identity ilə SMB auth üçün GA statusu, eyni storage account-da həm tətbiq identikliyi, həm də son istifadəçi girişinin birlikdə işləməsi və portaldan daha sadə aktivləşdirmə prosesi. Learn sənədləri isə bunun texniki idarəetmə nöqtəsini çox aydın göstərir: storage account səviyyəsində SMBOAuth aktivləşdirilməlidir və Windows, Linux, AKS üçün konkret inteqrasiya addımları mövcuddur.
Arxitektura baxımından incə, amma vacib məqam budur: storage tərəfdə capability GA-dır, amma AKS CSI inteqrasiyasının managed identity və workload identity hissələri Learn sənədlərində hələ preview kimi qeyd olunub. Yəni baza capability production-ready sayıla bilər, amma Kubernetes üzərindən istifadə edən komandalar preview idarəetmə qaydalarını nəzərə almalıdır.
Fon
Bu yenilikdən əvvəl bir çox komanda SMB girişlərini storage account key və ya digər credential əsaslı workflow ilə idarə edirdi. Microsoft açıq şəkildə bildirir ki, məqsəd secret paylanmasını aradan qaldırmaq, identity attribution-u yaxşılaşdırmaq və file access modelini Zero Trust və least-privilege prinsiplərinə yaxınlaşdırmaqdır. Learn sənədləri əlavə olaraq iki kritik əməliyyat qaydasını qeyd edir: storage account-da SMBOAuth mütləq aktiv olmalıdır və managed identity ilə autentifikasiya edən klientlər domain-joined olmamalıdır.
Portalda artıq bu capability üçün ayrıca parametr var. CLI və PowerShell səviyyəsində isə eyni idarəetmə --enable-smb-oauth true və ya -EnableSmbOAuth $true ilə aparılır. İcazə modelində isə sənədlər Storage File Data SMB MI Admin rolunu managed identity üzərindən files və directories üçün admin səviyyəli giriş rolu kimi göstərir.
Ətraflı izah
İdarəetmə ardıcıllığı sadədir: əvvəl storage account yaradılır və ya yenilənir, SMBOAuth aktivləşdirilir, file share yaradılır, sonra managed identity-yə uyğun RBAC verilir, daha sonra klient tərəfdə token/Kerberos hazırlığı görülür və mount edilir. Windows-da Microsoft-un rəsmi yolu AzFilesSmbMIClient modulu və AzFilesSmbMIClient.exe refresh üzərindən gedir. Linux-da azfilesauth paketi, azfilesauthmanager set və sec=krb5 ilə CIFS mount istifadə olunur. AKS tərəfdə isə mountWithManagedIdentity: "true" və mountWithWorkloadIdentityToken: "true" kimi CSI parametrləri işə düşür.
Aşağıdakı sadə flow bu arxitekturanı göstərir.
VM və ya AKS workloadManaged identity və ya workload identityMicrosoft Entra tokenKerberos credential cacheAzure Files SMB endpointStorage account-da SMBOAuth = trueAzure RBAC: Storage File Data SMB MI AdminShow code
Microsoft sənədlərinə uyğun minimal CLI və klient nümunəsi belə görünür. Buradakı komandalar vendor sənədlərindəki rəsmi əmr və parametrlərin yığcamlaşdırılmış formasıdır.
Əgər bu işi AKS üzərindən edirsinizsə, hazırkı Learn sənədləri deyir ki, managed identity mount-lar preview olaraq AKS 1.34-dən, workload identity mount-ları isə preview olaraq AKS 1.35.0-dan etibarən Linux node-larda mövcuddur. Burada əsas CSI parametrləri mountWithManagedIdentity və mountWithWorkloadIdentityToken-dır. Static PV istifadə edilirsə, storage account üzərində SMBOAuth əvvəlcədən aktiv edilməlidir.
# Storage account: SMB OAuth aktiv et
az storage account create \
--resource-group <resource-group> \
--name <storage-account-name> \
--location <region> \
--sku Standard_LRS \
--enable-smb-oauth true
az storage share create \
--account-name <storage-account-name> \
--name <file-share-name>
# Linux VM: system-assigned managed identity ilə credential al
sudo azfilesauthmanager set https://<storage-account-name>.file.core.windows.net --system
# Linux mount
sudo mount -t cifs \
//<storage-account-name>.file.core.windows.net/<file-share-name> /mnt/smb \
-o sec=krb5,cruid=<credential-id>,dir_mode=0755,file_mode=0755,serverino,nosharesock,mfsymlinks,actimeo=30
AKS storage class üçün yığcam bir nümunə:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: azurefile-csi-wi
provisioner: file.csi.azure.com
parameters:
storageAccount: EXISTING_STORAGE_ACCOUNT_NAME
mountWithWorkloadIdentityToken: "true"
clientID: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
reclaimPolicy: Delete
allowVolumeExpansion: true
mountOptions:
- dir_mode=0755
- file_mode=0755
- mfsymlinks
- cache=strict
- nosharesock
- actimeo=30
- nobrl
Troubleshooting tərəfdə rəsmi sənədlər və Azure-nin auth utility reposu kifayət qədər konkret məlumat verir. Windows-da SmbAuth üçün verbose logging açılır və AzFilesSmbMILog.log faylı yaranır. Linux-da azfilesrefresh log-u /var/log/azfilesrefresh.log altında, əsas auth log-ları isə /var/log/syslog və ya /var/log/messages altında olur; əlavə olaraq dmesg | grep cifs faydalıdır. Repo iki çox praktik xəta nümunəsi də göstərir: mount error(126): Required key not available, adətən Kerberos açarı və ya cifs-utils problemi deməkdir; mount error(13): Permission denied isə çox vaxt etibarsız/bitmiş ticket və ya çatışmayan RBAC icazəsini göstərir.
Redaktə olunmuş, amma sənədlərdəki məntiqə uyğun nümunə belə görünə bilər:
2026-04-24T08:12:31Z azfilesauthmanager: credential lookup failed for https://<redacted>.file.core.windows.net
mount error(13): Permission denied
Atılmış addımlar:
1. sudo azfilesauthmanager list
2. RBAC yoxlanıldı: Storage File Data SMB MI Admin
3. Yenidən işə salındı: sudo azfilesauthmanager set https://<redacted>.file.core.windows.net --system
4. Refresh daemon aktiv edildi: sudo systemctl enable --now azfilesrefresh
Developer inteqrasiyası üçün də capability artıq kifayət qədər yetişib. Managed identity sənədi .NET tərəfdə 1.2.3168.94 versiyalı paketdən danışır; Azure auth utility reposu isə Linux üçün azfilesauthmanager, refresh daemon, log faylları və ən çox rast gəlinən mount xətaları barədə konkret bələdçi verir.
Təsir qiymətləndirilməsi
Platforma baxımından ən böyük fayda yalnız security tərəfdə deyil; əməliyyat sadələşməsindədir. File share artıq “hələ də key ilə işləyən istisna komponent” olmaqdan çıxır və standart identity modelinə qoşulur. Microsoft həm də bildirir ki, capability HDD və SSD SMB share-larda, müxtəlif billing modellərində dəstəklənir və əlavə xərc tələb etmir.
İkinci böyük üstünlük isə daha təmiz məsuliyyət bölgüsüdür. GA elanında Microsoft eyni storage account-da həm tətbiq identikliyi, həm də son istifadəçi girişinin yanaşı işlədiyini qeyd edir. Deməli, əməliyyat komandaları və tətbiqlər sırf auth səbəbilə ayrı storage topologiyası qurmağa məcbur qalmır. AKS workload identity hissəsi isə xüsusilə tənzimlənən mühitlərdə maraqlıdır, çünki səlahiyyəti node yox, pod səviyyəsinə yaxınlaşdırır.
Mitigasiya və best practice-lər
Production rollout üçün ən sağlam yanaşma SMBOAuth aktivləşməsi, RBAC verilməsi, klient credential refresh-i və real mount testini eyni dəyişiklik paketi kimi idarə etməkdir. Sadəcə storage account parametrini dəyişib, mount testini sonraya saxlamaq risklidir. Microsoft həmçinin eyni VM üzərində sistem-assigned və user-assigned kimlikləri qarışdırmaqdansa, mümkün olduqda birini seçməyi tövsiyə edir.
Linux tərəfində ilk uğurlu mount-dan sonra azfilesrefresh xidmətini dərhal aktiv edin. Azure repo-sunda açıq məqaləlıb ki, enable edilməsə, reboot-dan sonra xidmət qalxmayacaq və ticket expiry sonradan mount failure-a çevrilə bilər. AKS-də isə mount icazələrini ehtiyacdan artıq geniş verməyin; Microsoft-un nümunələrində həm sərt, həm yumşaq variantlar var, amma default olaraq daha məhdud icazə modeli daha doğrudur.
Ən sonda, sənədləşmədə GA və preview sərhədini qarışdırmayın. Azure Files capability-si GA-dır, amma siz onu AKS preview CSI ssenarisi ilə istehlak edirsinizsə, bunu production readiness review və support planında ayrıca qeyd edin.