Azure Pipelines 공개 미리 보기에 대한 워크로드 ID 페더레이션
Azure Pipelines에 대한 워크로드 ID 페더레이션이 공개 미리 보기로 제공됩니다. ARM(Azure) 서비스 연결은 워크로드 ID 페더레이션을 지원하기 위한 추가 체계로 업데이트되었습니다.
공개 미리 보기에 등록하는 방법을 알아보려면 릴리스 정보를 확인하세요.
Azure Boards
Azure Pipelines
Azure Repos
Azure Boards
영역 및 반복 경로에 대한 제한
제한은 대규모 글로벌 서비스의 상태 및 효율성을 기본 중요한 역할을 합니다. 이 스프린트에서는 영역 및 반복 경로 모두에 대해 프로젝트당 10,000의 하드 제한을 도입했습니다. 서비스의 다양한 제한에 대해 자세히 알아보려면 작업 추적, 프로세스 및 프로젝트 제한 페이지를 방문하세요.
Azure Pipelines
Azure Pipelines의 워크로드 ID 페더레이션(공개 미리 보기)
Azure 서비스 연결에 비밀 및 인증서 저장을 중지하시겠습니까? 만료 될 때마다 이러한 비밀을 회전에 대 한 걱정을 중지 하시겠습니까? 이제 Azure 서비스 연결에 대한 워크로드 ID 페더레이션의 공개 미리 보기를 발표합니다.워크로드 ID 페더레이션은 업계 표준 기술인 OIDC(Open ID 커넥트)를 사용하여 Azure Pipelines와 Azure 간의 인증을 간소화합니다. 이 인증을 용이하게 하기 위해 비밀 대신 연합 주제가 사용됩니다.
이 기능의 일부로 ARM(Azure) 서비스 연결이 워크로드 ID 페더레이션을 지원하기 위한 다른 체계로 업데이트되었습니다. 이렇게 하면 Azure 서비스 연결을 사용하는 파이프라인 태스크가 페더레이션 주체(sc://<org>/<project>/<service connection name>)를 사용하여 인증할 수 있습니다. 기존 인증 체계에 비해 이 체계를 사용하는 기본 이점은 다음과 같습니다.
- 간소화된 관리: 더 이상 Azure AD의 서비스 주체에서 Azure DevOps로 비밀을 생성, 복사 및 저장하지 않습니다. Azure 서비스 연결(예: 서비스 주체)의 다른 인증 체계에 사용되는 비밀은 특정 기간(현재 2년) 후에 만료됩니다. 만료되면 파이프라인이 실패합니다. 새 비밀을 다시 생성하고 서비스 연결을 업데이트해야 합니다. 워크로드 ID 페더레이션으로 전환하면 이러한 비밀을 관리할 필요가 없으며 서비스 연결을 만들고 관리하는 전반적인 환경이 향상됩니다.
- 향상된 보안: 워크로드 ID 페더레이션을 사용하면 Azure Pipelines와 Azure 간의 통신에 영구적 비밀이 없습니다. 따라서 파이프라인 작업에서 실행되는 작업은 프로덕션 환경에 액세스할 수 있는 비밀을 누출하거나 유출할 수 없습니다. 이것은 종종 우리의 고객에 대 한 관심사 되었습니다.
다음 두 가지 방법으로 이러한 기능을 활용할 수 있습니다.
- 새 Azure 서비스 연결을 만들 때마다 새 워크로드 ID 페더레이션 체계를 사용합니다. 앞으로 권장되는 메커니즘이 됩니다.
- 기존 Azure 서비스 연결(비밀 기반)을 새 스키마로 변환 합니다. 이 변환을 한 번에 하나의 연결로 수행할 수 있습니다. 무엇보다도 이러한 서비스 연결을 사용하는 파이프라인을 수정할 필요가 없습니다. 변환을 완료하면 새 구성표가 자동으로 적용됩니다.
워크로드 ID 페더레이션을 사용하여 새 Azure 서비스 연결을 만들려면 Azure 서비스 연결 만들기 환경에서 워크로드 ID 페더레이션(자동) 또는 (수동)을 선택하기만 하면 됩니다.
이전에 만든 Azure 서비스 연결을 변환하려면 연결을 선택한 후 "변환" 작업을 선택합니다.
이제 Azure Pipelines에 포함된 모든 Azure 작업이 이 새 체계를 지원합니다. 그러나 Marketplace의 작업 또는 집에서 만든 사용자 지정 작업을 사용하여 Azure에 배포하는 경우 워크로드 ID 페더레이션을 아직 지원하지 않을 수 있습니다. 이러한 경우 보안을 개선하기 위해 워크로드 ID 페더레이션을 지원하도록 작업을 업데이트하도록 요청합니다. 지원되는 작업의 전체 목록은 여기에서 찾을 수 있습니다.
이 미리 보기에서는 Azure 서비스 연결에 대해서만 워크로드 ID 페더레이션을 지원합니다. 이 체계는 다른 유형의 서비스 연결에서는 작동하지 않습니다. 자세한 내용은 문서를 참조하세요.
이 블로그 게시물에 는 자세한 내용이 포함되어 있습니다.
PAT 대신 Microsoft Entra ID를 사용하여 파이프라인 에이전트를 등록할 수 있습니다.
이제 Pipeline 에이전트는 서비스 주체 또는 사용자를 사용하여 에이전트를 등록하기 위해 더 많은 인수를 지원합니다. 보안 설정에서 에이전트 풀에 사용된 ID에 대한 액세스 권한을 부여해야 합니다. 이렇게 하면 에이전트의 일회성 설정에 PAT(Personal Access Token)를 사용할 필요가 없습니다.
서비스 주체를 사용하여 에이전트 등록
서비스 주체를 사용하여 Azure DevOps Services에 Pipelines 에이전트를 등록하려면 다음 인수를 제공합니다.
--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee
에이전트 VM 확장에서 서비스 주체 사용
Azure VM은 VM 확장을 사용하여 배포 그룹에 포함할 수 있습니다. 에이전트를 등록하기 위해 PAT 대신 서비스 주체를 사용하도록 VM 확장이 업데이트되었습니다.
"settings": {
"userServicePrincipal": true
}
"protectedSettings": {
"clientId": "[parameters('clientId')]"
"clientSecret": "[parameters('clientSecret')]"
"tenantId": "[parameters('tenantId')]"
}
디바이스 코드 흐름을 사용하여 대화형으로 에이전트 등록
웹 브라우저를 사용하여 설정을 쉽게 완료할 수 있습니다. 에이전트 구성 스크립트를 실행할 때 인증 유형에 대해 "AAD"를 입력합니다. 스크립트는 웹에서 이동하는 위치와 입력할 코드를 포함하여 다음 단계를 안내합니다. 웹에 코드를 입력한 후 콘솔로 돌아가서 에이전트 설정을 완료합니다.
환경에 대한 REST API
환경은 파이프라인의 배포를 사용하여 대상으로 지정할 수 있는 리소스 컬렉션입니다. 환경은 배포 기록, 작업 항목 및 커밋에 대한 추적 가능성 및 액세스 제어 메커니즘을 제공합니다.
프로그래밍 방식으로 환경을 만들려는 것을 알고 있으므로 REST API에 대한 설명서를 게시했습니다.
의도하지 않은 파이프라인 실행 방지
현재 YAML 파이프라인에서 섹션을 trigger 지정하지 않으면 해당 리포지토리에 푸시된 모든 변경 내용에 대해 실행됩니다. 이로 인해 파이프라인이 실행되고 의도하지 않은 실행이 많은 이유에 대한 혼란이 발생할 수 있습니다.
이 동작을 변경할 수 있는 암시적 YAML CI 트리거 사용 안 함이라는 조직 및 프로젝트 수준 파이프라인 설정을 추가했습니다. 트리거 섹션이 없는 경우 파이프라인을 트리거하지 않도록 선택할 수 있습니다.
기본적으로 GitHub 리포지토리를 안전하게 빌드
마지막 스프린트에서는 포크된 GitHub 리포지토리에서 PR을 빌드하기 위한 중앙 집중식 컨트롤을 도입했습니다.
이 스프린트를 사용하면 조직 수준에서 새 조직에 대한 옵션을 사용할 수 있습니다 Securely build pull requests from forked repositories . 기존 조직은 영향을 받지 않습니다.
빌드가 실패할 때 실패로 상태 코드 검사 정책의 재정의를 사용하지 않도록 설정
이전에는 PR에서 빌드가 실패하는 경우 코드 검사 정책 상태 '실패'로 재정의되었습니다. 이는 PR에 대한 필수 검사 인해 PR이 차단되는 선택적 검사 및 코드 검사 정책으로 빌드를 수행한 일부 사용자에게 차단기였습니다.
이 스프린트를 사용하면 빌드가 실패할 경우 코드 검사 정책이 '실패'로 재정의되지 않습니다. 이 기능은 모든 고객에 대해 사용하도록 설정됩니다.
Azure Repos
Blobless 및 트리리스 필터 지원
이제 Azure DevOps는 복제/페치하는 동안 두 가지 추가 필터링을 지원합니다. 다음과 같습니다. --filter=blob:none 및 --filter=tree:0첫 번째 옵션(Blobless clone)은 일반 개발에 가장 적합하며, 두 번째 옵션(트리리스 클론)은 빌드를 실행한 후 복제를 해제하는 경우에 더 적합합니다카드.
다음 단계
참고 항목
이러한 기능은 향후 2~3주 동안 출시될 예정입니다.
Azure DevOps로 이동하여 살펴보세요.
피드백을 제공하는 방법
이러한 기능에 대해 어떻게 생각하는지 듣고 싶습니다. 도움말 메뉴를 사용하여 문제를 보고하거나 제안을 제공합니다.
Stack Overflow에서 커뮤니티에서 조언과 질문에 답변할 수도 있습니다.
감사합니다,
실비우안드리카