كيفية تشغيل اختبارات التكامل لواجهات برمجة التطبيقات المحمية بنظام Azure AD عبر مسارات Azure DevOps

غالباً ما تواجه أتمتة اختبارات التكامل لواجهات برمجة التطبيقات الآمنة عقبات عند التعامل مع بيانات الاعتماد في مسارات التكامل المستمر (CI/CD). بالنسبة لفرق التطوير التي تعتمد على بيئة شركة Microsoft، يتطلب نقل هذه الاختبارات من البيئات المحلية إلى منصة Azure DevOps طريقة آمنة لحقن تفاصيل المصادقة. من خلال الاستفادة من خدمة Azure Key Vault والكيانات الخدمية (Service Principals)، يمكن للمطورين المصادقة بأمان وتشغيل الاختبارات ضد واجهات برمجة التطبيقات المحمية بنظام Azure AD دون تضمين بيانات حساسة في مستودعات الأكواد (Repositories).

يعتمد سير العمل هذا على الأساليب السابقة المستخدمة في منصة GitHub Actions، مع تكييف تكوين ملف YAML ليتناسب مع مسارات Azure Pipelines. يظل التحدي الأساسي كما هو: لم تعد الاختبارات تُنفذ على جهاز المطور المحلي، مما يعني أنه يجب استبدال المصادقة القائمة على المستخدم ببيانات اعتماد قوية خاصة بالتطبيق. يوضح هذا الدليل الخطوات الدقيقة المطلوبة لتكوين المسار، وتوفير الوصول اللازم، وتنفيذ الاختبارات تلقائياً.

للسماح للمسار بالمصادقة، يجب عليك أولاً إنشاء بيانات اعتماد التطبيق باستخدام أداة Azure CLI متعددة المنصات. ستمنح هذه البيانات الاختبارات المؤتمتة حق الوصول إلى خدمة Azure Key Vault، والتي تحتوي على الأسرار الضرورية للمستخدم والتطبيق.

ابدأ بتسجيل الدخول إلى حساب Azure الخاص بك وتعيين الاشتراك الافتراضي الذي يحتوي على خدمة Key Vault:

az login

az account set -s "id-of-subscription"

بعد ذلك، قم بإنشاء الكيان الخدمي لنظام Azure AD. يوصى بشدة بتعيين اسم وصفي للتعرف بسهولة على الغرض منه لاحقاً. يقوم الأمر التالي بإنشاء الكيان دون تعيين دور التحكم في الوصول القائم على الأدوار (RBAC) الافتراضي، حيث أنه غير ضروري لسير العمل المحدد هذا:

az ad sp create-for-rbac -n "AzurePipelinesAADTestingDemo" --sdk-auth --skip-assignment

سيؤدي تنفيذ هذا الأمر إلى إخراج كائن JSON يحتوي على بيانات الاعتماد الجديدة. يجب عليك حفظ هذا المخرج، حيث سيكون مطلوباً عند تكوين متغيرات المسار لاحقاً:

{
  "clientId": "",
  "clientSecret": "",
  "subscriptionId": "",
  "tenantId": "",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

بعد إنشاء الكيان الخدمي، يتطلب الآن إذناً صريحاً لقراءة الأسرار من خدمة Azure Key Vault الخاصة بك. ستحتاج إلى قيمة clientId من مخرجات JSON التي تم إنشاؤها في الخطوة السابقة.

قم بتشغيل الأمر التالي لمنح الكيان الخدمي حق الوصول للقراءة لجميع الأسرار داخل خدمة Key Vault المحددة:

az keyvault set-policy -n "key-vault-name" --secret-permissions get list --spn "clientId-from-previous-output"

يجب تعديل مشروع الاختبار لقبول بيانات الاعتماد التي يتم تمريرها من مسار Azure DevOps. على وجه التحديد، يحتاج التطبيق إلى البحث عن متغير بيئة يسمى AZURE_CREDENTIALS.

إذا كان هذا المتغير غائباً، يفترض التطبيق أنه يعمل محلياً ويعود إلى مصادقة المستخدم المحلي. أما إذا كان المتغير موجوداً، فإنه يقوم بإلغاء تسلسل كائن JSON لاستخراج معرف العميل والسر. قم بتحديث منشئ التكوين الخاص بك على النحو التالي:

builder.ConfigureAppConfiguration(configBuilder =>
{
    // Adds user secrets for the integration test project
    configBuilder.AddUserSecrets();

// Build temporary config, get Key Vault URL, add Key Vault as config source
    var config = configBuilder.Build();
    string keyVaultUrl = config["IntegrationTest:KeyVaultUrl"];
    if (!string.IsNullOrEmpty(keyVaultUrl))
    {
        // CI / CD pipeline sets up a credentials environment variable to use
        string credentialsJson = Environment.GetEnvironmentVariable("AZURE_CREDENTIALS");
        // If it is not present, we are running locally
        if (string.IsNullOrEmpty(credentialsJson))
        {
            // Use local user authentication
            configBuilder.AddAzureKeyVault(keyVaultUrl);
        }
        else
        {
            // Use credentials in JSON object
            var credentials = (JObject)JsonConvert.DeserializeObject(credentialsJson);
            string clientId = credentials?.Value("clientId");
            string clientSecret = credentials?.Value("clientSecret");
            configBuilder.AddAzureKeyVault(keyVaultUrl, clientId, clientSecret);
        }

config = configBuilder.Build();
    }

Settings = config.GetSection("IntegrationTest").Get();
});

انتقل إلى مشروع Azure DevOps الخاص بك وقم بإنشاء مسار جديد. قبل تحديد خطوات ملف YAML، يجب عليك تكوين متغيرات البيئة الضرورية. انقر فوق قسم المتغيرات في الزاوية العلوية اليمنى من محرر المسار وأضف المتغيرات الستة التالية:

• AZURE_CREDENTIALS: مخرجات JSON الكاملة التي تم إنشاؤها بواسطة أمر إنشاء الكيان الخدمي. يجب وضع علامة على هذا كسر.
• API_APP_ID_URI: معرف URI لتطبيق واجهة برمجة التطبيقات (API) داخل مستأجر Azure AD الاختباري الخاص بك.
• API_CLIENT_ID: معرف العميل لتسجيل تطبيق واجهة برمجة التطبيقات.
• API_AUTHORITY: المعرف لمستأجر Azure AD الذي ستقبل واجهة برمجة التطبيقات الرموز المميزة له.
• API_AUTHORIZATION_URL: عنوان URL لنقطة نهاية المصادقة المستخدمة في واجهة Swagger UI (مفيد للحفاظ على تكوين التطبيق متسقاً).
• KEY_VAULT_URL: عنوان URL الأساسي لخدمة Azure Key Vault التي تحتوي على بيانات الاعتماد الخاصة بك.

الخطوة الأخيرة هي بناء تعريف ملف YAML لتنفيذ البناء وتشغيل الاختبارات. تم تكوين المسار للتشغيل عند وجود التزامات (Commits) جديدة على الفرع الرئيسي (Master) ويستخدم أحدث وكيل لنظام Ubuntu Linux.

يضمن سير العمل تثبيت حزمة.NET Core SDK الصحيحة، ويبني الحل، ويشغل الاختبارات مع حقن المتغيرات المحددة مسبقاً. تتيح إضافة علامة --logger trx لمنصة Azure DevOps تحليل نتائج الاختبار ونشرها بشكل أصلي.

trigger:
  - master

pool:
  vmImage: "ubuntu-latest"

steps:
  - task: UseDotNet@2
    displayName: Setup .NET Core
    inputs:
      packageType: "sdk"
      version: "3.1.x"

- script: dotnet build --configuration Release
    displayName: Build with dotnet

- script: dotnet test --configuration Release --logger trx
    displayName: Test with dotnet
    workingDirectory: Joonasw.AadTestingDemo.IntegrationTests
    env:
      IntegrationTest__KeyVaultUrl: $(KEY_VAULT_URL)
      Authentication__Authority: $(API_AUTHORITY)
      Authentication__AuthorizationUrl: $(API_AUTHORIZATION_URL)
      Authentication__ClientId: $(API_CLIENT_ID)
      Authentication__ApplicationIdUri: $(API_APP_ID_URI)
      AZURE_CREDENTIALS: $(AZURE_CREDENTIALS)

- task: PublishTestResults@2
    displayName: Publish test results
    condition: succeededOrFailed()
    inputs:
      testRunner: VSTest
      testResultsFiles: "**/*.trx"

يعد نقل اختبارات التكامل من البيئات المحلية إلى منصة CI/CD قوية مثل Azure DevOps علامة فارقة في نضج أي فريق تطوير مؤسسي. يمثل النهج الموضح هنا، والذي يستخدم كياناً خدمياً مخصصاً لجلب الأسرار ديناميكياً من خدمة Azure Key Vault، المعيار الذهبي لممارسات DevSecOps. فهو يقضي تماماً على خطر تسريب بيانات الاعتماد المضمنة في مستودعات الأكواد، والذي لا يزال أحد أكثر النواقل شيوعاً لاختراقات بيانات المؤسسات.

ومع ذلك، يتطلب الواقع التشغيلي لهذا الإعداد إدارة صارمة لدورة الحياة. كما لوحظ في سير العمل، فإن بيانات اعتماد الكيان الخدمي ورموز المستخدم تنتهي صلاحيتها بطبيعتها. يجب على الفرق التي تنفذ هذا المسار إنشاء تنبيهات مؤتمتة أو تذكيرات في التقويم لتدوير هذه الأسرار قبل انقضاء صلاحيتها. يمكن أن يؤدي فشل المسار بسبب سر منتهي الصلاحية في خدمة Key Vault إلى إيقاف مسارات النشر بالكامل، مما يتسبب في اختناقات غير ضرورية خلال فترات الإصدار الحرجة.

في النهاية، على الرغم من أن بناء جملة ملف YAML يختلف قليلاً عن منصة GitHub Actions، إلا أن الفلسفة المعمارية الأساسية متطابقة. يضمن نهج شركة Microsoft الموحد عبر كلتا المنصتين أن تتمكن الفرق من نقل ممارساتها الأمنية بسلاسة. بالنسبة للمؤسسات المستثمرة بكثافة في بيئة Azure، فإن مركزية هذه الاختبارات المؤتمتة داخل مسارات Azure Pipelines توفر رؤية فائقة وتكاملاً أوثق مع إدارة هوية المؤسسة الحالية الخاصة بهم.