Share via

Sjablonen gebruiken voor beveiliging

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

In dit artikel wordt beschreven hoe sjablonen de beveiliging voor Azure Pipelines kunnen stroomlijnen. Sjablonen kunnen de buitenste structuur van uw pijplijn definiëren en helpen schadelijke codeinfiltratie te voorkomen. Sjablonen kunnen ook automatisch stappen bevatten om taken uit te voeren, zoals het scannen van referenties. Als meerdere pijplijnen binnen uw team of organisatie dezelfde structuur delen, kunt u overwegen sjablonen te gebruiken.

Controles op beveiligde resources vormen het fundamentele beveiligingsframework voor Azure Pipelines. Deze controles zijn van toepassing, ongeacht de pijplijnstructuur, fasen en taken. U kunt sjablonen gebruiken om deze controles af te dwingen.

Sjablonen bevat en uitbreidt

Azure Pipelines bevat sjablonen en breidt deze uit.

  • Inclusief sjablonen bevatten de code van de sjabloon rechtstreeks in het buitenste bestand waarnaar wordt verwezen, vergelijkbaar met #include in C++. In de volgende voorbeeldpijplijn wordt de include-npm-steps.yml sjabloon in de steps sectie ingevoegd.

      steps:
  - template: templates/include-npm-steps.yml

  • Breidt sjablonen definiëren de buitenste structuur van de pijplijn en bieden specifieke punten voor gerichte aanpassingen. In de context van C++lijken extends sjablonen op overname.

Wanneer u sjablonen gebruikt extends , kunt u ook in zowel de sjabloon als de uiteindelijke pijplijn gebruiken includes om algemene configuratieonderdelen uit te voeren. Zie de naslaginformatie over sjabloongebruik voor een volledige verwijzing.

Sjablonen uitbreiden

Voor de veiligste pijplijnen begint u met het gebruik van uitbreidingssjablonen. Deze sjablonen definiëren de buitenste structuur van de pijplijn en voorkomen dat schadelijke code de pijplijn infiltreert.

Het volgende sjabloonbestand heeft bijvoorbeeld de naam template.yml.

parameters:
- name: usersteps
  type: stepList
  default: []
steps:
- ${{ each step in parameters.usersteps }}:
  - ${{ step }}

Met de volgende pijplijn wordt de template.yml-sjabloon uitgebreid.

# azure-pipelines.yml
resources:
  repositories:
  - repository: templates
    type: git
    name: MyProject/MyTemplates
    ref: refs/tags/v1

extends:
  template: template.yml@templates
  parameters:
    usersteps:
    - script: echo This is my first step
    - script: echo This is my second step

Tip

Wanneer u sjablonen instelt extends , kunt u overwegen deze te verankeren aan een bepaalde Git-vertakking of -tag, zodat bestaande pijplijnen niet worden beïnvloed als er wijzigingen optreden die fouten veroorzaken. In het voorgaande voorbeeld wordt deze functie gebruikt.

BEVEILIGINGSfuncties voor YAML-pijplijnen

De syntaxis van de YAML-pijplijn bevat verschillende ingebouwde beveiligingen. Een uitbreidingssjabloon kan het gebruik ervan afdwingen. Als u de beveiliging van pijplijnen wilt verbeteren, kunt u een van de volgende beperkingen implementeren.

Stapdoelen

U kunt bepaalde stappen beperken voor uitvoering in een container in plaats van op de host. Stappen in containers hebben geen toegang tot de host van de agent, waardoor deze stappen geen agentconfiguratie kunnen wijzigen of schadelijke code kunnen achterlaten voor latere uitvoering.

U kunt bijvoorbeeld de netwerktoegang beperken. Zonder open netwerktoegang kunnen gebruikersstappen geen pakketten ophalen uit niet-geautoriseerde bronnen of code en geheimen uploaden naar externe netwerklocaties.

In de volgende voorbeeldpijplijn worden stappen uitgevoerd op de agenthost voordat stappen in een container worden uitgevoerd.

resources:
  containers:
  - container: builder
    image: mysecurebuildcontainer:latest
steps:
- script: echo This step runs on the agent host, and it could use Docker commands to tear down or limit the container's network
- script: echo This step runs inside the builder container
  target: builder

Opdrachtbeperkingen voor agentlogboekregistratie

U kunt de services beperken die de Azure Pipelines-agent biedt voor gebruikersstappen. Gebruikersstappen vragen services aan met behulp van logboekregistratieopdrachten, die speciaal opgemaakte tekenreeksen zijn afgedrukt naar standaarduitvoer. In de beperkte modus zijn de meeste services van de agent, zoals het uploaden van artefacten en het koppelen van testresultaten, niet beschikbaar.

De volgende voorbeeldtaak mislukt omdat target de eigenschap de agent opdracht geeft om publicatieartefacten niet toe te staan.

- task: PublishBuildArtifacts@1
  inputs:
    artifactName: myartifacts
  target:
    commands: restricted

In restricted de modus blijft de setvariable opdracht toegestaan, dus voorzichtigheid is nodig omdat pijplijnvariabelen worden geëxporteerd als omgevingsvariabelen naar volgende taken. Als taken door de gebruiker verstrekte gegevens uitvoeren, zoals openstaande problemen die zijn opgehaald via een REST API, zijn ze mogelijk kwetsbaar voor injectieaanvallen. Schadelijke gebruikersinhoud kan omgevingsvariabelen instellen die kunnen worden misbruikt om de agenthost te misbruiken.

Om dit risico te beperken, kunnen pijplijnauteurs expliciet declareren welke variabelen zijn ingesteld met behulp van de setvariable opdracht logboekregistratie. Wanneer u een lege lijst opgeeft, is alle variabele instelling niet toegestaan.

De volgende voorbeeldtaak mislukt omdat de taak alleen de expectedVar variabele of een variabele met voorvoegsel okmag instellen.

- task: PowerShell@2
  target:
    commands: restricted
    settableVariables:
    - expectedVar
    - ok*
  inputs:
    targetType: 'inline'
    script: |
      Write-Host "##vso[task.setvariable variable=BadVar]myValue"

Voorwaardelijke fase of taakuitvoering

U kunt fasen en taken beperken tot alleen worden uitgevoerd onder specifieke voorwaarden. In het volgende voorbeeld zorgt de voorwaarde ervoor dat beperkte code alleen wordt gebouwd voor de hoofdbranch.

jobs:
- job: buildNormal
  steps:
  - script: echo Building the normal, unsensitive part
- ${{ if eq(variables['Build.SourceBranchName'], 'refs/heads/main') }}:
  - job: buildMainOnly
    steps:
    - script: echo Building the restricted part that only builds for main branch

Syntaxiswijziging

Azure Pipelines-sjablonen hebben de flexibiliteit om de YAML-syntaxis te herhalen en te wijzigen. Met iteratie kunt u specifieke YAML-beveiligingsfuncties afdwingen.

Een sjabloon kan ook gebruikersstappen herschrijven, zodat alleen goedgekeurde taken kunnen worden uitgevoerd. U kunt bijvoorbeeld inlinescriptuitvoering voorkomen.

Met de volgende voorbeeldsjabloon voorkomt u dat de staptypen bash, powershellen pwshde script stappen worden uitgevoerd. Voor volledige vergrendeling van ad-hocscripts kunt u ook blokkeren BatchScript en ShellScript.

# template.yml
parameters:
- name: usersteps
  type: stepList
  default: []
steps:
- ${{ each step in parameters.usersteps }}:
  - ${{ if not(or(startsWith(step.task, 'Bash'),startsWith(step.task, 'CmdLine'),startsWith(step.task, 'PowerShell'))) }}:  
    - ${{ step }}
  # The following lines replace tasks like Bash@3, CmdLine@2, PowerShell@2
  - ${{ else }}:  
    - ${{ each pair in step }}:
        ${{ if eq(pair.key, 'inputs') }}:
          inputs:
            ${{ each attribute in pair.value }}:
              ${{ if eq(attribute.key, 'script') }}:
                script: echo "Script removed by template"
              ${{ else }}:
                ${{ attribute.key }}: ${{ attribute.value }}
        ${{ elseif ne(pair.key, 'displayName') }}:
          ${{ pair.key }}: ${{ pair.value }}

          displayName: 'Disabled by template: ${{ step.displayName }}'

In de volgende pijplijn die deze sjabloon uitbreidt, worden de scriptstappen verwijderd en niet uitgevoerd.

# azure-pipelines.yml
extends:
  template: template.yml
  parameters:
    usersteps:
    - task: MyTask@1
    - script: echo This step will be stripped out and not run!
    - bash: echo This step will be stripped out and not run!
    - powershell: echo "This step will be stripped out and not run!"
    - pwsh: echo "This step will be stripped out and not run!"
    - script: echo This step will be stripped out and not run!
    - task: CmdLine@2
      displayName: Test - Will be stripped out
      inputs:
        script: echo This step will be stripped out and not run!
    - task: MyOtherTask@2

Typeveilige parameters

Voordat een pijplijn wordt uitgevoerd, worden sjablonen en hun parameters omgezet in constanten. Sjabloonparameters kunnen de veiligheid van het type verbeteren voor invoerparameters.

In de volgende voorbeeldsjabloon beperken de parameters de beschikbare opties voor pijplijngroepen door een opsomming van specifieke opties op te geven in plaats van vrije-vormtekenreeksen toe te staan.

# template.yml
parameters:
- name: userpool
  type: string
  default: Azure Pipelines
  values:
  - Azure Pipelines
  - private-pool-1
  - private-pool-2

pool: ${{ parameters.userpool }}
steps:
- script: # ... removed for clarity

Wanneer de pijplijn de sjabloon uitbreidt, moet deze een van de beschikbare poolopties opgeven.

# azure-pipelines.yml
extends:
  template: template.yml
  parameters:
    userpool: private-pool-1

Sjabloonstappen

Een sjabloon kan automatisch stappen in een pijplijn bevatten. Deze stappen kunnen taken uitvoeren, zoals het scannen van referenties of statische codecontroles. Met de volgende sjabloon worden stappen voor en na de gebruikersstappen in elke taak ingevoegd.

parameters:
  jobs: []

jobs:
- ${{ each job in parameters.jobs }}: 
  - ${{ each pair in job }}:  
      ${{ if ne(pair.key, 'steps') }}:
        ${{ pair.key }}: ${{ pair.value }}
    steps:                            
    - task: CredScan@1 
    - ${{ job.steps }} 
    - task: PublishMyTelemetry@1 
      condition: always()

Sjabloon afdwingen

Sjablonen zijn een waardevol beveiligingsmechanisme, maar hun effectiviteit is afhankelijk van afdwinging. De belangrijkste besturingspunten voor het afdwingen van sjabloongebruik zijn beveiligde resources. U kunt goedkeuringen en controles voor uw agentgroep of andere beveiligde resources, zoals opslagplaatsen, configureren. Zie Een controle van een opslagplaatsresource toevoegen voor een voorbeeld.

Vereiste sjablonen

Als u het gebruik van een specifieke sjabloon wilt afdwingen, configureert u de vereiste sjablooncontrole voor een resource. Deze controle is alleen van toepassing wanneer de pijplijn van een sjabloon wordt uitgebreid.

Wanneer u de pijplijntaak bekijkt, kunt u de status van de controle controleren. Als de pijplijn niet van de vereiste sjabloon uitbreidt, mislukt de controle. De uitvoering stopt en meldt u van de mislukte controle.

Schermopname van een mislukte goedkeuringscontrole.

Wanneer u de vereiste sjabloon gebruikt, wordt de controle geslaagd.

Schermopname van een geslaagde goedkeuringscontrole.

De volgende params.yml sjabloon moet worden verwezen in elke pijplijn die deze uitbreidt.

# params.yml
parameters:
- name: yesNo 
  type: boolean
  default: false
- name: image
  displayName: Pool Image
  type: string
  default: ubuntu-latest
  values:
  - windows-latest
  - ubuntu-latest
  - macOS-latest

steps:
- script: echo ${{ parameters.yesNo }}
- script: echo ${{ parameters.image }}

De volgende voorbeeldpijplijn breidt de params.yml-sjabloon uit en vereist deze voor goedkeuring. Als u een pijplijnfout wilt demonstreren, markeert u de verwijzing naar params.yml.

# azure-pipeline.yml

resources:
 containers:
     - container: my-container
       endpoint: my-service-connection
       image: mycontainerimages

extends:
    template: params.yml
    parameters:
        yesNo: true
        image: 'windows-latest'

Gerelateerde inhoud