Szablony zabezpieczeń

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

Szablony usługi Azure Pipelines umożliwiają definiowanie zawartości, logiki i parametrów wielokrotnego użytku w potokach YAML. W tym artykule opisano, jak szablony mogą pomóc zwiększyć bezpieczeństwo potoku poprzez:

• Definiowanie zewnętrznej struktury pipeline w celu zapobiegania infiltracji złośliwego kodu.
• Automatyczne dołączanie kroków do wykonywania zadań, takich jak skanowanie poświadczeń.
• Pomaganie w egzekwowaniu kontroli chronionych zasobów, które tworzą podstawowy framework zabezpieczeń dla usługi Azure Pipelines i mają zastosowanie do wszystkich struktur i komponentów pipelines.

Ten artykuł jest częścią serii, która ułatwia implementowanie środków zabezpieczeń dla usługi Azure Pipelines. Aby uzyskać więcej informacji, zobacz Secure Azure Pipelines.

Wymagania wstępne

Dołącza i rozszerza szablony

Usługa Azure Pipelines udostępnia szablony i rozszerza je.

• Szablon includes zawiera kod szablonu bezpośrednio w pliku zewnętrznym, który odwołuje się do szablonu, podobnie jak #include w języku C++. Przykładowy potok poniżej wstawia szablon include-npm-steps.yml do sekcji steps.

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

• Szablon extends definiuje ogólną strukturę potoku i oferuje określone punkty dla ukierunkowanych dostosowań. W kontekście języka C++ extends szablony przypominają dziedziczenie.

W przypadku korzystania z extends szablonów można również użyć includes do wykonywania standardowych czynności konfiguracyjnych zarówno w szablonie, jak i w końcowym potoku. Aby uzyskać więcej informacji, zobacz Używanie szablonów YAML w potokach na potrzeby procesów wielokrotnego użytku i zabezpieczania.

Rozszerza szablony

W przypadku najbardziej bezpiecznych potoków zacznij od używania extends szablonów. Te szablony definiują zewnętrzną strukturę potoku i pomagają zapobiegać infiltracji złośliwego kodu.

Poniższy przykład przedstawia plik szablonu o nazwie template.yml.

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

Poniższy przykładowy potok rozszerza szablon template.yml.

# 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

Funkcje zabezpieczeń pipeline

Składnia potoku YAML obejmuje kilka wbudowanych zabezpieczeń. Extends szablony mogą wymuszać ich użycie w celu zwiększenia bezpieczeństwa potoku. Można zaimplementować dowolne z poniższych ograniczeń.

Cele kroków

Można ograniczyć określone kroki do uruchamiania w kontenerze, a nie na hoście. Kroki w kontenerach nie mogą uzyskać dostępu do hosta agenta, więc nie mogą modyfikować konfiguracji agenta ani pozostawiać złośliwego kodu do późniejszego wykonania.

Można na przykład uruchomić kroki użytkownika w kontenerze, aby uniemożliwić im dostęp do sieci, aby nie mogli pobierać pakietów z nieautoryzowanych źródeł ani przekazywać kodu i wpisów tajnych do lokalizacji zewnętrznych.

Poniższy przykładowy potok zadań uruchamia krok na hoście agenta, który może potencjalnie zmodyfikować sieć hosta, a następnie krok wewnątrz kontenera, ograniczający dostęp sieciowy.

resources:
  containers:
  - container: builder
    image: mysecurebuildcontainer:latest
steps:
- script: echo This step runs on the agent host
- script: echo This step runs inside the builder container
  target: builder

Parametry bezpieczne dla typu

Przed uruchomieniem potoku szablony i ich parametry są przekształcane w wartości stałe. Parametry szablonu mogą zwiększyć bezpieczeństwo typów dla parametrów wejściowych.

W poniższym przykładowym szablonie parametry ograniczają dostępne opcje puli potoków, wyliczając określone opcje zamiast zezwalać na dowolny ciąg.

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

pool: ${{ parameters.userpool }}
steps:
- script: echo Hello world

Aby rozszerzyć szablon, pipeline musi określić jedną z dostępnych opcji puli.

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

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

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

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

# 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 }}'

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

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()

Wymuszanie szablonu

Skuteczność szablonów jako mechanizmu zabezpieczeń opiera się na wymuszaniu. Kluczowymi punktami kontrolnymi wymuszania użycia szablonu są chronione zasoby.

Możesz skonfigurować zatwierdzenia i kontrole dla puli agentów lub innych chronionych zasobów, takich jak repozytoria. Aby zapoznać się z przykładem, zobacz Dodaj sprawdzanie zasobów repozytorium.

Wymagane szablony

Aby wymusić użycie określonego szablonu, skonfiguruj wymagane ustawienie szablonu w połączeniu usługowym dla zasobu. Ta kontrola ma zastosowanie tylko wtedy, gdy potok rozszerza się z szablonu.

Podczas wyświetlania zadania potoku można monitorować stan sprawdzania. Jeśli potok nie rozszerza się z wymaganego szablonu, sprawdzanie zakończy się niepowodzeniem.

Jeśli używasz wymaganego szablonu, sprawdzanie jest sprawdzane.

Na przykład, w dowolnym potoku, który go rozszerza, należy odwołać się do poniższego szablonu params.yml.

# 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 }}

Poniższy przykładowy potok rozszerza szablon params.yml i wymaga zatwierdzenia. Aby zademonstrować błąd potoku, oznacz extends jako komentarz odwołanie do 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'

Powiązana zawartość

• Użycie szablonu
• Parametry szablonu
• Zabezpieczenia zasobów
• Zatwierdzenia i kontrole