Azure पाइपलाइनों में सुरक्षा छेद?

Aug 16 2020

मैं Azure DevOps पर शोध कर रहा हूं और मुझे Azure पाइपलाइनों में एक बहुत स्पष्ट सुरक्षा छेद जैसा दिखता है।

इसलिए, मैं YAML के रूप में अपनी पाइपलाइन बना रहा हूं और 2 चरणों को परिभाषित कर रहा हूं: एक बिल्ड स्टेज, और एक तैनाती चरण। परिनियोजन चरण इस तरह दिखता है:

- stage: deployApiProdStage
  displayName: 'Deploy API to PROD'
  dependsOn: buildTestApiStage
  jobs:
  - deployment: deployApiProdJob
    displayName: 'Deploy API to PROD'
    timeoutInMinutes: 10
    condition: and(succeeded(), eq(variables.isRelease, true))
    environment: PROD
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Deploy Azure web app'
            inputs:
              azureSubscription: '(service connection to production web app)'
              appType: 'webAppLinux'
              appName: 'my-web-app'
              package: '$(Pipeline.Workspace)/$(artifactName)/**/*.zip'
              runtimeStack: 'DOTNETCORE|3.1'
              startUpCommand: 'dotnet My.Api.dll'

Microsoft प्रलेखन पर्यावरण के लिए अनुमोदन और जाँच जोड़कर इसे सुरक्षित करने की बात करता है; उपरोक्त मामले में, PROD वातावरण। यह ठीक होगा यदि यहाँ संरक्षित संसाधन जो मेरे PROD वेब ऐप को प्रकाशित करने की अनुमति देता है - azureSubscription में सेवा कनेक्शन - PROD वातावरण से खींचा गया। दुर्भाग्य से, जहाँ तक मैं बता सकता हूँ, यह नहीं है। यह पाइप लाइन से ही जुड़ा हुआ है।

इसका मतलब है कि जब पाइप लाइन पहली बार चलती है, तो Azure DevOps UI मुझे पाइपलाइन कनेक्शन को सेवा कनेक्शन तक पहुंचने की अनुमति देता है , जो कि किसी भी तैनाती के लिए आवश्यक है। एक बार जब एक्सेस की अनुमति दी जाती है, तो उस पाइपलाइन के पास हमेशा के लिए उस सेवा कनेक्शन तक पहुंच होती है। इसका मतलब यह है कि तब से, उस सेवा कनेक्शन का उपयोग किया जा सकता है, जहां कोई भी काम के लिए पर्यावरण निर्दिष्ट नहीं है। इससे भी बदतर, किसी भी पर्यावरण का नाम निर्दिष्ट है जो मान्यता प्राप्त नहीं है, एक त्रुटि का कारण नहीं बनता है, लेकिन डिफ़ॉल्ट रूप से एक रिक्त वातावरण बनाने का कारण बनता है!

इसलिए, भले ही मैं PROD पर्यावरण के लिए एक मैनुअल अनुमोदन सेट करता हूं, अगर संगठन में कोई व्यक्ति हमारी कोड समीक्षा के माध्यम से एक बदलाव को पर्ची करने का प्रबंधन करता है (जो कि संभव है, नियमित बड़े कोड समीक्षाओं के साथ) जो azure में पर्यावरण के नाम को 'NewPROD' में बदल देता है -pipelines.yml फ़ाइल, CI / CD उस नए वातावरण का निर्माण करेगा, और आगे बढ़ेगा और तुरंत PROD पर नियोजित करेगा क्योंकि नए वातावरण की कोई जाँच या स्वीकृति नहीं है!

निश्चित रूप से इसके बजाय पर्यावरण से जुड़े सेवा कनेक्शन के लिए यह समझ में आएगा। यह भी समझ में आता है कि नए वातावरण के ऑटो-निर्माण पर प्रतिबंध लगाने का एक विकल्प है - मैं वास्तव में यह नहीं देखता कि यह वैसे भी कैसे उपयोगी है। अभी, जहां तक मैं बता सकता हूं, यह एक विशाल सुरक्षा छेद है जो किसी भी व्यक्ति द्वारा महत्वपूर्ण वातावरण में तैनाती की अनुमति दे सकता है, जो रेपो तक पहुंच रखता है या अनुमोदन प्रक्रिया के माध्यम से एज़्योर-पाइपलाइनों.आईएमएल फ़ाइल में परिवर्तन को पर्ची करने का प्रबंधन करता है। असफलता / कमजोरी का एक प्रमुख बिंदु है। आपकी पाइपलाइनों को हासिल करने के लिए बहुत प्रशंसित वृद्धिशील दृष्टिकोण का क्या हुआ? क्या मुझे यहां कुछ याद आ रहा है, या यह सुरक्षा छेद उतना ही बुरा है जितना मुझे लगता है कि यह है?

जवाब

1 CeceDong-MSFT Aug 17 2020 at 16:04

आपके उदाहरण में, ऐसा लगता है कि आपने खाली वातावरण बनाया / उपयोग किया, कोई परिनियोजन लक्ष्य नहीं है। वर्तमान में, केवल कुबेरनेट संसाधन और वर्चुअल मशीन संसाधन प्रकार एक वातावरण में समर्थित हैं।

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/environments?view=azure-devops

आपके उदाहरण में संसाधन एक सेवा कनेक्शन है, इसलिए आपको सेवा कनेक्शन पर जाने और इस सेवा कनेक्शन के लिए चेक परिभाषित करने की आवश्यकता है।