다음을 통해 공유


Azure Resource Manager 서비스 연결에 대한 워크로드 ID 페더레이션의 일반 공급

이제 워크로드 ID 페더레이션이 Azure Pipelines에서 일반 공급된다는 사실을 발표하게 되어 기쁩니다. Azure 서비스 연결에서 비밀 및 인증서를 관리할 필요 없이 간소화된 환경을 즐길 수 있습니다.

이 업데이트를 통해 Azure Boards와의 향상된 GitHub 통합의 일환으로 새로운 기능을 미리 보고 있습니다. 이제 GitHub 끌어오기 요청 또는 커밋에 직접 연결할 수 있습니다. 더 이상 창 간에 전환하거나 복사/붙여넣기를 하지 않습니다. 원하는 리포지토리를 선택하고, 끌어오기 요청을 찾거나, 필요한 커밋을 찾아서 연결하면 됩니다.

이러한 기능에 대해 자세히 알아보려면 릴리스 정보를 확인하세요.

일반

Azure DevOps용 GitHub Advanced Security

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

일반

대체 자격 증명 사용 중단에 대한 최종 통지

대체 자격 증명은 2020년 3월에 공식적으로 사용되지 않았지만 일부 기존 사용자는 기존 대체 자격 증명을 지속적으로 사용했습니다. 2024년 1월부터 모든 대체 자격 증명은 완전히 사용되지 않습니다. 잠재적인 중단을 방지하려면 개인 액세스 토큰 또는 관리 ID와 같이 제공되는 사용 가능한 인증 메커니즘 중 하나로 전환합니다.

Azure Devops OAuth 셀프 서비스 비밀 회전

5년마다 Azure DevOps OAuth 앱에 대한 클라이언트 비밀을 업데이트하여 Azure DevOps API를 활용하는 데 필요한 액세스 및 새로 고침 토큰을 지속적으로 생성해야 합니다. 클라이언트 암호가 만료에 가까워지면 이제 독립적으로 새 암호를 생성하여 팀에게 고객 지원에 의존하지 않고 자유롭게 관리할 수 있습니다. 비밀 회전을 예약하는 이러한 유연성은 만료된 비밀로 인해 교체를 기다리는 고객에게 잠재적인 중단 시간을 최소화합니다.

지리 선택 스크린샷

여기에서 프로필을 통해 액세스할 수 있는 각 Azure DevOps 앱 페이지에서 이 새로운 기능을 찾습니다. Azure DevOps OAuth 가이드에서 이 새로운 단계에 대해 자세히 알아봅니다.

Azure DevOps용 GitHub Advanced Security

이제 경고 세부 정보 보기에서 코드 조각을 사용할 수 있습니다.

이제 코드 검색 및 비밀 검색 경고에 대한 경고 세부 정보 페이지에 경고가 발생한 하나 이상의 코드 줄을 표시하는 코드 조각이 표시됩니다. Azure DevOps 리포지토리의 원래 파일로 이동하려면 코드 조각 위의 파일 이름을 클릭합니다.

대/소문자를 구분하는 미들웨어 경로의 스크린샷

경고 개요에 표시된 잘린 비밀

검색된 비밀의 잘린 마지막 6자가 이제 비밀 경고 개요 화면에 표시됩니다. 이 기능은 동일한 비밀 유형의 여러 비밀 노출이 있는 경우 특정 비밀이 있는 위치를 신속하게 식별할 수 있는 경우에 유용합니다.

비밀 경고 목록의 스크린샷.

코드 검색 경고에 대한 추가 경고 심각도 추가

이제 CodeQL quality 쿼리의 경고 결과(예: ErrorWarningNote 및 심각도)에 대한 새로운 경고 심각도가 존재합니다. 각 품질 경고 심각도에는 크기 조정 심각도를 나타내는 고유한 배지 및 색이 있습니다. 보안 경고의 심각도 규모와 유사하게 low 이러한 각 심각도를 필터링할 critical 수도 있습니다.

경고 목록 및 심각도 필터를 검사하는 코드 스크린샷

Azure DevOps용 GitHub Advanced Security 사용 설정에 필요한 연결된 Azure 구독

이전에 연결된 Azure 구독 없이 Azure DevOps 조직의 리포지토리에 대해 Advanced Security를 사용하도록 설정한 경우 해당 리포지토리에서 Advanced Security가 자동으로 비활성화된 것을 알 수 있습니다. Advanced Security를 다시 사용하도록 설정하려면 연결된 Azure 구독을 조직에 추가합니다. 구독을 추가하거나 변경하는 방법에 대한 자세한 내용은 Azure 구독 변경을 참조하세요.

고급 보안 API 업데이트

최근에 제공된 고급 보안 API 대한 다양한 업데이트:

  • 이제 GET Alerts API는 경고의 증분 목록을 반환하고 이 날짜 이후 수정된 경고만 반환하는 새 매개 변수 ModifiedSince를 지원합니다. 자세한 내용은 경고 - 목록을 참조 하세요.
  • 조직 또는 프로젝트의 고급 보안 사용 상태를 가져오거나 업데이트하는 두 개의 새 엔드포인트가 있습니다. 두 엔드포인트 모두 고급 보안을 사용하도록 설정된 리포지토리 목록을 반환합니다. 자세한 내용은 조직 - 사용 또는 프로젝트 - 활성화를 참조하세요.
  • 예상 고급 보안 미터 사용량을 반영하기 위해 조직 또는 프로젝트에 대한 활성 커밋자 수의 예상을 가져오는 두 가지 새로운 엔드포인트가 있습니다. 자세한 내용은 조직 미터 사용량 예측 또는 프로젝트 미터 사용량 추정치를 참조하세요.

이제 고급 보안 권한이 영구적으로 표시됩니다.

과거에는 Advanced Security를 사용하도록 설정한 경우에만 3개의 고급 보안 권한 비트가 리포지토리별 할당 가능 권한으로 존재했습니다. 이제 이러한 사용 권한은 기본적으로 리포지토리 > 보안 권한 창에서 사용할 수 있으며 고급 보안을 사용하도록 설정하지 않고도 할당할 수 있습니다.

고급 보안 권한의 스크린샷.

Azure Boards

작업 항목을 GitHub 끌어오기 요청 또는 커밋에 연결하는 두 가지 옵션이 있습니다. 끌어오기 요청에서 AB# 구문을 사용하거나 작업 항목에서 직접 연결할 수 있습니다. 현재 프로세스에는 GitHub 끌어오기 요청의 URL을 복사하고 링크를 추가할 때 붙여넣는 작업이 포함됩니다. 이렇게 하려면 여러 창을 열고 GitHub와 Azure DevOps 간에 전환해야 합니다.

이 스프린트에서는 GitHub 끌어오기 요청 또는 커밋에 연결할 때 검색 기능을 사용하도록 설정하여 향상된 환경을 발표하게 되어 기쁩니다. 원하는 리포지토리를 검색하여 선택하고 드릴다운하여 특정 끌어오기 요청 또는 커밋을 찾아 연결합니다. 더 이상 여러 창을 변경하고 복사/붙여넣을 필요가 없습니다(여전히 해당 옵션이 있지만).

Gif를 사용하여 링크를 추가합니다.

참고 항목

이 기능은 새 보드 허브 미리 보기에서만 사용할 수 있습니다.

이 기능에 액세스하려면 조직 이름(dev.azure.com/{조직 이름})과 함께 이메일을 직접 보내주세요.

새로운 Boards 허브 개선 사항

이 릴리스에서는 접근성 및 페이지 재배치에 초점을 맞춘 다양한 향상된 기능을 New Boards Hub 미리 보기에 도입했습니다.

다음은 최대 400% 확대/축소에 맞게 조정되는 페이지 재배치 변경의 예입니다.

Gif를 사용하여 새로운 보드 허브 개선 사항을 시연합니다.

또한 작업 항목 양식, 보드 및 백로그 페이지에서 성능 향상을 롤아웃했습니다. 이러한 변경으로 새 보드가 이전 보드로 설정된 성능 표준과 일치할 것으로 예상할 수 있습니다.

개발 및 배포 컨트롤

이제 프로젝트 구성 방법에 따라 작업 항목에서 개발 및/또는 배포 컨트롤을 제거합니다. 예를 들어 리포지토리 및/또는 파이프라인을 해제하도록 프로젝트 설정을 구성할 수 있습니다.

DevOps 서비스의 스크린샷.

작업 항목으로 이동하면 해당 개발 및 배포 컨트롤이 양식에서 숨겨집니다.

관련 작업의 스크린샷.

GitHub 리포지토리를 Azure Boards에 연결하려는 경우 GitHub 리포지토리에 대한 개발 컨트롤이 표시됩니다.

개발 컨트롤의 스크린샷.

Azure Pipelines

이제 Azure Resource Manager 서비스 연결에 대한 워크로드 ID 페더레이션을 일반 공급

9월에 는 비밀을 사용하지 않고 Azure 서비스 연결을 구성하는 기능을 발표 했습니다. 그 이후로 많은 고객이 이 기능을 채택했으며 이제 이 기능을 일반 공급할 수 있게 되어 기쁩니다.

워크로드 ID 페더레이션을 아직 사용하지 않는 경우 다음과 같은 방법으로 만료 비밀이 없는 걱정 없는 Azure 서비스 연결을 활용할 수 있습니다.

워크로드 ID 페더레이션을 사용하여 새 Azure 서비스 연결을 만들려면 Azure 서비스 연결 만들기 환경에서 워크로드 ID 페더레이션(자동)을 선택합니다.

워크로드 ID 페더레이션(자동)의 스크린샷.

이전에 만든 Azure 서비스 연결을 변환하려면 연결을 선택한 후 "변환" 작업을 선택합니다.

변환 작업의 스크린샷.

여러 서비스 연결을 변환하려면 자동화를 사용할 수 있습니다( 예: 이 PowerShell 스크립트).

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

자세한 내용은 설명서를 참조하세요.

Pipelines 에이전트는 리소스 사용률 문제를 더 두드러지게 표시합니다.

지난 10월에 는 Pipelines 에이전트에서 메모리 및 디스크 공간 사용량을 추적하는 기능을 추가했습니다.

고객이 에이전트에 대한 메모리 또는 디스크 공간 제한과 같은 리소스 제약 조건을 인식할 수 있도록 리소스 제약 조건을 더 잘 표시했습니다.

제한된 메모리 및 디스크 공간 경고의 스크린샷.

위의 메시지가 표시되면 에이전트가 차원화된 것보다 더 많은 리소스를 사용하는 작업으로 인해 에이전트가 응답하지 않고 파이프라인 작업이 실패할 수 있습니다.

"우리는 에이전트로부터 듣기를 중단했습니다"

이러한 경우 자세한 정보 표시 로그를 사용하여 보다 세분화된 리소스 사용률 메시지를 얻고 에이전트가 리소스가 부족했던 위치를 추적할 수 있습니다. 자체 호스팅 에이전트를 사용하는 경우 에이전트에 적절한 리소스가 있는지 확인합니다.

노드 6 작업 실행기의 대역 외 설치

Azure Pipelines는 두 가지 버전의 에이전트 패키지를 제공합니다.

  • vsts-agent-* 패키지는 노드 6을 사용하여 실행하는 작업을 지원합니다.
  • pipelines-agent-* 패키지는 노드 6을 실행해야 하는 작업을 지원하지 않습니다.

자체 호스팅 에이전트를 만드는 고객은 파이프라인 에이전트 릴리스 페이지에서 다운로드할 수 있습니다. 에이전트에 포함된 노드 버전은 작업을 실행하는 데 사용됩니다. 노드 실행기 버전을 참조하세요.

에이전트 등록 후 pipelines-agent-* 패키지에서 설치된 에이전트는 이제 에이전트에 포함되지 않고 조직 설정의 '작업 제한'에 따라 차단되지 않은 노드 버전을 다운로드합니다. 이를 통해 고객은 pipelines-agent-* 에이전트 패키지를 사용하고 조직 설정에서 '작업 제한'을 사용하여 노드 6의 설치를 제어할 수 있습니다.

지연된 승인

승인을 사용하여 배포에서 로그오프할 수 있습니다. 그러나 승인이 지정된 시간과 배포를 시작해야 하는 시간이 일치하지 않는 경우가 있습니다. 예를 들어 검토하는 특정 배포의 경우 범위를 벗어난 배포라는 것을 알 수 있습니다. 그것은 즉시 진행할 수 없습니다 상상, 오히려 그것은 밤 동안 발생 해야.

이러한 시나리오를 다루기 위해 YAML 파이프라인에 대한 승인을 연기하는 옵션을 추가했습니다. 이제 파이프라인 실행을 승인하고 승인이 적용되는 시기를 지정할 수 있습니다.

파이프라인 실행 승인의 스크린샷

승인 연기를 선택하면 승인이 적용되는 시간을 구성할 수 있습니다.

승인 연기 스크린샷

after_approval_deferred 스크린샷

승인은 검사 패널에 지연된 것으로 표시됩니다. 지연된 시간이 지나면 승인이 적용됩니다.

승인 스크린샷이 적용됩니다.

승인 및 검사 시퀀싱

이 스프린트를 사용하면 승인 및 검사가 실행되는 순서를 지정할 수 있습니다.

승인 및 검사를 사용하면 프로덕션에 대한 배포를 제어할 수 있습니다. 예를 들어 리포지토리의 분기에서 main 실행되는 파이프라인만 프로덕션 ARM 서비스 연결을 사용할 수 있도록 지정할 수 있습니다. 또한 사용자 승인이 필요하고 시스템이 성능 검사를 통과하도록 할 수 있습니다.

오늘까지 모든 승인 및 검사는 배타적 잠금을 제외하고 병렬로 실행되었습니다. 즉, 수동 승인이 부여되기 전에 배포 프로세스에서 성능 검사를 통과해야 하는 경우 Azure Pipelines에서 이를 적용할 수 없습니다. 승인 지침 및 내부 프로세스 설명서에 의존해야 했습니다.

이 스프린트에서는 승인 및 검사 시퀀싱을 소개합니다. 이제 5가지 범주의 승인 및 검사가 있습니다.

  1. 정적 검사: 분기 컨트롤, 필수 템플릿 및 아티팩트 평가
  2. 사전 동적 검사 승인
  3. 동적 검사: 승인, Azure 함수 호출, REST API 호출, 업무 시간, Azure Monitor 경고 쿼리
  4. 사후 동적 검사 승인
  5. 배타적 잠금

추가 확인 스크린샷

주문은 승인 및 검사 탭에도 표시됩니다.

승인 및 검사 탭의 스크린샷.

각 범주 내에서 검사는 병렬로 실행됩니다. 즉, Azure Function 호출 확인 및 업무 시간 검사가 있는 경우 동시에 실행됩니다.

배포에 대한 검사의 스크린샷

검사 범주는 하나씩 실행되고 한 범주가 실패하면 나머지 검사는 실행되지 않습니다. 즉, 분기 컨트롤 검사 및 승인이 있는 경우 분기 컨트롤이 실패하면 승인도 실패합니다. 따라서 불필요한 전자 메일이 전송되지 않습니다.

배포 실패에 대한 검사 스크린샷

모든 동적 검사가 실행된 후, 사후 동적 검사 승인을 사용하여 배포에서 로그오프하거나, 동적 검사를 계속하기 전에 사전 동적 검사 승인을 사용하여 수동 유효성 검사를 수행할 수 있습니다.

YAML 파이프라인을 편집할 때 기본적으로 유효성 검사 및 저장

YAML 파이프라인이 잘못되어 시간과 노력이 낭비될 수 있습니다. 파이프라인 편집 생산성을 향상시키기 위해 편집기에서 저장 단추를 변경하여 YAML 유효성 검사도 수행합니다.

새 단추의 스크린샷

유효성 검사 및 저장 스크린샷

파이프라인에 오류가 있는 경우 여전히 저장할 수 있습니다.

파이프라인의 스크린샷이 유효합니다.

검색된 오류의 스크린샷

또한 유효성 검사 환경이 개선되어 이해하기 쉬운 목록의 오류를 볼 수 있습니다.

오류 목록의 스크린샷.

Azure Repos

권한이 없는 사용자가 파이프라인을 빌드 정책으로 구성하지 않음 방지

권한이 없는 사용자가 파이프라인을 빌드 정책으로 구성하지 않음 방지

이전에는 새 빌드 정책을 추가했을 때 드롭다운 목록에서 모든 파이프라인을 실행하도록 구성할 수 있었습니다(큐 빌드 권한이 없는 파이프라인 포함). 마찬가지로 큐 빌드 권한이 없는 파이프라인을 실행하도록 구성된 경우에도 기존 빌드 정책을 편집할 수 있습니다 .

이제 사용자가 이 작업을 수행할 수 없도록 하고 있습니다. 사용자가 지정된 파이프라인에 대한 큐 빌드 권한을 거부하면 새 빌드 정책을 추가할 때 해당 파이프라인이 드롭다운에서 비활성화됨(회색으로 표시됨)으로 표시됩니다.

큐 빌드 권한이 거부되는 "샌드박스" 라는 파이프라인을 보여 주는 아래 이미지를 참조하세요.

샌드박스에 대한 사용 권한의 스크린샷.

큐 빌드 권한이 거부된 사용자가 새 빌드 정책을 추가하려고 할 때 드롭다운에서 "샌드박스"라는 파이프라인이 비활성화(회색으로 표시됨)된 것을 보여 주는 아래 이미지를 참조하세요.

빌드 정책 추가 스크린샷

"샌드박스"라는 파이프라인을 실행하도록 구성된 빌드 정책이 이미 있는 경우 큐 빌드 권한이 없는 사용자는 빌드 정책을 편집하거나 볼 수 없습니다. 이 경우는 다음 이미지에 표시됩니다.

빌드 유효성 검사 스크린샷

이 정책을 삭제하려고 하면 삭제 확인을 요청하는 팝업 대화 상자가 표시됩니다.

삭제 확인 스크린샷

이러한 변경 내용은 빌드 정책을 만들거나 편집하는 API 호출에도 적용됩니다. 큐 빌드 권한이 없는 사용자 ID를 사용하여 이러한 작업을 실행하면 호출에서 적절한 오류 코드와 이 작업을 수행하려면 이 파이프라인에 대한 QueueBuild 권한이 필요하다는 “TFS.WebApi.Exception: TF401027: 오류 메시지를 반환하지 못합니다."

큐 빌드 권한이 없는 API를 user identity 사용하여 수행된 빌드 정책을 삭제하면 성공하며 경고 또는 방지가 수행되지 않습니다(API를 통한 삭제 작동 방식은 변경되지 않음).

Azure Artifacts

Rust Crates에 대한 지원은 일반적으로 사용할 수 있습니다.

2024년 2월 16일부터 Rust 크레이트 지원은 Azure Artifacts에 일반적으로 사용할 수 있는 기능이 됩니다. 청구 미터는 지원되는 다른 프로토콜에 적용되는 동일한 가격 책정 모델을 사용하여 활성화됩니다.

npm 감사에 대한 Azure Artifacts 지원

이제 Azure Artifacts에서 npm audit 명령과 npm audit fix 지원을 지원합니다. 이 기능을 사용하면 안전하지 않은 패키지 버전을 자동으로 업데이트하여 프로젝트의 취약성을 분석하고 수정할 수 있습니다. 자세한 내용은 npm 감사를 사용하여 패키지 취약성을 감지하고 수정합니다.

다음 단계

참고 항목

이러한 기능은 향후 2~3주 동안 출시될 예정입니다.

Azure DevOps로 이동하여 살펴보세요.

피드백을 제공하는 방법

이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.

제안하기

Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.

감사합니다,

댄 헬렘