Modelos de segurança

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

Os modelos do Azure Pipelines permitem definir conteúdo reutilizável, lógica e parâmetros em pipelines YAML. Este artigo descreve como os modelos podem ajudar a aprimorar a segurança do pipeline:

• Definir a estrutura externa de um pipeline para ajudar a evitar infiltração de código mal-intencionada.
• Incluindo automaticamente as etapas para realizar tarefas como a verificação de credenciais.
• Ajudando a impor verificações sobre recursos protegidos, que formam a estrutura de segurança fundamental para o Azure Pipelines e se aplicam a todas as estruturas e componentes de pipeline.

Este artigo faz parte de uma série que ajuda você a implementar medidas de segurança para o Azure Pipelines. Para obter mais informações, consulte Secure Azure Pipelines.

Pré-requisitos

Inclui e estende modelos

O Azure Pipelines fornece modelos de inclusão e extensão.

• Um includes modelo inclui seu código diretamente no arquivo externo que faz referência a ele, de maneira semelhante a #include em C++. O pipeline de exemplo a seguir insere o modelo include-npm-steps.yml na seção steps.

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

• Um extends modelo define a estrutura externa do pipeline e oferece pontos específicos para personalizações direcionadas. No contexto do C++, extends os modelos se assemelham à herança.

Ao usar modelos extends, você também pode usar includes para configurar elementos comuns tanto no modelo quanto no pipeline final. Para obter mais informações, consulte Usar modelos YAML em pipelines para processos reutilizáveis e seguros.

Estende modelos

Para os pipelines mais seguros, comece usando extends templates. Esses modelos definem a estrutura externa do pipeline e ajudam a evitar infiltração de código mal-intencionado.

O exemplo a seguir mostra um arquivo de modelo chamado template.yml.

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

O pipeline de exemplo a seguir estende o 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

Recursos de segurança para pipeline

A sintaxe do pipeline YAML inclui várias proteções internas. Extends os modelos podem impor seu uso para aprimorar a segurança do pipeline. Você pode implementar qualquer uma das restrições a seguir.

Destinos de etapa

Você pode restringir as etapas especificadas para execução em um contêiner em vez de no host. As etapas em contêineres não podem acessar o host do agente, portanto, elas não podem modificar a configuração do agente ou deixar código mal-intencionado para execução posterior.

Por exemplo, você pode executar as etapas do usuário em um contêiner para impedir que eles acessem a rede, para que eles não possam recuperar pacotes de fontes não autorizadas ou carregar código e segredos em locais externos.

O pipeline de exemplo a seguir executa uma etapa no host do agente que poderia potencialmente alterar a rede de host, seguida por uma etapa dentro de um contêiner que limita o acesso à rede.

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

Parâmetros de segurança de tipo

Antes de um pipeline ser executado, os modelos e seus parâmetros se transformam em constantes. Os parâmetros de template podem aprimorar a segurança do tipo para parâmetros de entrada.

No modelo de exemplo a seguir, os parâmetros restringem as opções de pool de pipeline disponíveis enumerando opções específicas em vez de permitir qualquer cadeia de caracteres.

# 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

Para estender o modelo, o pipeline deve especificar uma das opções de pool disponíveis.

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

Imposição de modelo

A eficácia dos modelos como um mecanismo de segurança depende da imposição. Os principais pontos de controle para impor o uso do modelo são recursos protegidos.

Você pode configurar aprovações e verificações para o pool de agentes ou outros recursos protegidos, como repositórios. Para obter um exemplo, consulte Adicionar uma verificação de recursos do repositório.

Modelos necessários

Para impor o uso de um modelo específico, configure a verificação de modelo necessária na conexão de serviço para um recurso. Essa verificação se aplica somente quando o pipeline se estende de um modelo.

Ao exibir o trabalho do pipeline, você pode monitorar o status da verificação. Se o pipeline não se estender do modelo necessário, a verificação falhará.

Quando você usa o modelo necessário, a verificação é aprovada.

Por exemplo, o modelo de params.yml a seguir deve ser referenciado em qualquer pipeline que o estenda.

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

O exemplo de pipeline a seguir estende o modelo de params.yml e requer sua aprovação. Para demonstrar uma falha de pipeline, comente a extends referência a 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'

Conteúdo relacionado

• Uso de modelo
• Parâmetros de modelo
• Segurança de recursos
• Aprovações e verificações