Skip to main content

OpenID Connect 참조

OIDC(OpenID Connect)를 사용하여 클라우드 공급자와 함께 GitHub Actions 워크플로를 인증하는 방법에 대한 정보를 찾습니다.

OIDC 토큰 클레임

GitHub의 OIDC 공급자에서 지원하는 모든 클레임을 보려면 https://token.actions.githubusercontent.com/.well-known/openid-configuration에서 claims_supported 항목을 검토합니다.

OIDC 토큰에는 다음 클레임이 포함됩니다.

표준 대상 그룹, 발급자, 주체 클레임

클레임클레임 유형설명
aud대상기본적으로 이 URL은 리포지토리를 소유한 조직과 같은 리포지토리 소유자의 URL입니다. 도구 키트 명령 core.getIDToken(audience)을 사용하여 사용자 지정 대상 그룹을 설정할 수 있습니다.
iss발급자OIDC 토큰의 발급자: https://token.actions.githubusercontent.com
sub주제클라우드 공급자가 유효성을 검사할 주체 클레임을 정의합니다. 이 설정은 액세스 토큰이 예측 가능한 방식으로만 할당되도록 하는 데 필수적입니다.

추가 표준 JOSE 헤더 매개 변수 및 클레임

머리글 매개 변수매개 변수 형식설명
alg알고리즘OIDC 공급자가 사용하는 알고리즘입니다.
kid키 식별자OIDC 토큰의 고유 키입니다.
typType토큰의 유형을 설명합니다. JWT(JSON Web Token)입니다.
클레임클레임 유형설명
exp만료 시간JWT의 만료 시간을 식별합니다.
iat발급 시간JWT가 발급된 시간입니다.
jtiJWT 토큰 식별자OIDC 토큰의 고유 식별자입니다.
nbf다음 날짜부터이 시간 전에는 JWT를 사용할 수 없습니다.

GitHub이 제공하는 사용자 지정 클레임

클레임설명
actor워크플로 실행을 시작한 개인 계정입니다.
actor_id워크플로 실행을 시작한 개인 계정의 ID입니다.
base_ref워크플로 실행에서 끌어오기 요청의 대상 분기입니다.
environment작업에 사용되는 환경의 이름입니다. environment 클레임이 포함된 경우(include_claim_keys를 통해서도 포함) 환경이 필요하며 제공해야 합니다.
event_name워크플로 실행을 트리거한 이벤트의 이름입니다.
head_ref워크플로 실행에서 끌어오기 요청의 소스 분기입니다.
job_workflow_ref재사용 가능한 워크플로를 사용하는 작업의 경우, 재사용 가능한 워크플로의 참조 경로입니다. 자세한 내용은 재사용 가능한 워크플로에서 OpenID Connect 사용을(를) 참조하세요.
job_workflow_sha재사용 가능한 워크플로를 사용하는 작업의 경우, 재사용 가능한 워크플로 파일에 대한 커밋 SHA입니다.
ref(참조) 워크플로 실행을 트리거한 git 참조입니다.
ref_typeref의 유형(예시: "branch")입니다.
repository_visibility워크플로가 실행 중인 리포지토리의 표시 여부입니다. 값 internal, private 또는 public 중에서 수락합니다.
repository워크플로가 실행 중인 리포지토리입니다.
repository_id워크플로가 실행 중인 리포지토리의 ID입니다.
repository_ownerrepository가 저장되는 조직의 이름입니다.
repository_owner_idrepository가 저장되는 조직의 ID입니다.
run_id워크플로를 트리거한 워크플로 실행의 ID입니다.
run_number이 워크플로가 실행된 횟수입니다.
run_attempt이 워크플로가 다시 시도된 횟수입니다.
runner_environment작업에 사용되는 실행기의 유형입니다. github-hosted 또는 self-hosted 값 중에서 수락합니다.
workflow워크플로의 이름입니다.
workflow_ref워크플로의 참조 경로입니다. 예를 들어 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch입니다.
workflow_sha워크플로 파일의 커밋 SHA입니다.

클라우드 역할에 대한 신뢰 조건을 정의하는 데 사용되는 OIDC 클레임

대상 그룹 및 주체 클레임은 일반적으로 클라우드 역할/리소스에 대한 조건을 설정하여 GitHub 워크플로에 대한 액세스 범위를 지정할 때 함께 사용됩니다.

  • 대상 그룹: 기본적으로 이 값은 조직 또는 리포지토리 소유자의 URL을 사용합니다. 특정 조직의 워크플로만 클라우드 역할에 액세스할 수 있는 조건을 설정하는 데 사용할 수 있습니다.
  • 주체: 기본적으로 미리 정의된 형식을 가지며 GitHub 조직, 리포지토리, 분기 또는 연결된 job 환경과 같은 워크플로에 대한 일부 주요 메타데이터를 연결한 것입니다. 연결된 메타데이터에서 주체 클레임이 어셈블되는 방법을 보려면 주체 클레임 예제를 참조하세요.

더 세부적인 신뢰 조건이 필요한 경우 주체(sub) 클레임을 JWT에 포함할 수 있습니다. 자세한 내용은 토큰 클레임 사용자 지정을 참조하세요.

이러한 조건을 설정하는 데 사용할 수 있는 OIDC 토큰에서 지원되는 많은 추가 클레임이 있습니다. 또한 클라우드 공급자를 사용하면 액세스 토큰에 역할을 할당할 수 있으므로 보다 세부적인 권한을 지정할 수 있습니다.

참고 항목

클라우드 공급자가 액세스 토큰을 발급하는 방법을 제어하려면 신뢰할 수 없는 리포지토리가 클라우드 리소스에 대한 액세스 토큰을 요청할 수 없도록 하나 이상의 조건을 정의해야 합니다.

주체 클레임 예시

다음 예시에서는 "주체"를 조건으로 사용하는 방법과 연결된 메타데이터에서 "주체"가 어셈블되는 방법을 설명합니다. 주체job 컨텍스트의 정보를 사용하며, 특정 분기, 환경에서 실행되는 워크플로의 요청에 대해서만 액세스 토큰 요청을 부여할 수 있음을 클라우드 공급자에 알립니다. 다음 섹션에서는 사용할 수 있는 몇 가지 일반적인 주체에 대해 설명합니다.

특정 환경에 대한 필터링

주체 클레임에는 작업이 환경을 참조할 때의 환경 이름이 포함됩니다.

특정 환경 이름을 필터링하는 주체를 구성할 수 있습니다. 이 예시에서 워크플로 실행은 octo-org 조직이 소유한 octo-repo라는 리포지토리에 Production이라는 환경이 있는 작업에서 시작되어야 합니다.

  • 구문: repo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME
  • 예시: repo:octo-org/octo-repo:environment:Production

pull_request 이벤트 필터링

워크플로가 끌어오기 요청 이벤트에 의해 트리거되는 경우 주체 클레임에 pull_request 문자열이 포함됩니다. 단, 작업에서 환경을 참조하지 않아야만 합니다.

pull_request 이벤트를 필터링하는 주체를 구성할 수 있습니다. 이 예시에서 워크플로 실행은 octo-org 조직이 소유한 octo-repo라는 리포지토리의 pull_request 이벤트에 의해 트리거되어야 합니다.

  • 구문: repo:ORG-NAME/REPO-NAME:pull_request
  • 예시: repo:octo-org/octo-repo:pull_request

특정 분기 필터링

주체 클레임에는 워크플로의 분기 이름이 포함됩니다. 단, 작업이 환경을 참조하지 않고 워크플로가 끌어오기 요청 이벤트에 의해 트리거되지 않는 경우에만 해당됩니다.

특정 분기 이름을 필터링하는 주체를 구성할 수 있습니다. 이 예시에서 워크플로 실행은 octo-org 조직이 소유한 octo-repo라는 리포지토리에 demo-branch라는 분기에서 시작되어야 합니다.

  • 구문: repo:ORG-NAME/REPO-NAME:ref:refs/heads/BRANCH-NAME
  • 예시: repo:octo-org/octo-repo:ref:refs/heads/demo-branch

특정 태그 필터링

주체 클레임에는 워크플로의 태그 이름이 포함됩니다. 단, 작업이 환경을 참조하지 않고 워크플로가 끌어오기 요청 이벤트에 의해 트리거되지 않는 경우에만 해당됩니다.

특정 태그를 필터링하는 주체를 만들 수 있습니다. 이 예시에서 워크플로 실행은 octo-org 조직이 소유한 octo-repo라는 리포지토리의 demo-tag 태그로 시작되어야 합니다.

  • 구문: repo:ORG-NAME/REPO-NAME:ref:refs/tags/TAG-NAME
  • 예시: repo:octo-org/octo-repo:ref:refs/tags/demo-tag

클라우드 공급자에서 주체 구성

클라우드 공급자의 트러스트 관계에서 주체를 구성하려면 해당 트러스트 구성에 주체 문자열을 추가해야 합니다. 다음 예시에서는 다양한 클라우드 공급자가 서로 다른 방식으로 동일한 repo:octo-org/octo-repo:ref:refs/heads/demo-branch 주체를 수락하는 방법을 보여줍니다.

클라우드 공급자예시
Amazon Web Services"token.actions.githubusercontent.com:sub": "repo:octo-org/octo-repo:ref:refs/heads/demo-branch"
Azurerepo:octo-org/octo-repo:ref:refs/heads/demo-branch
Google Cloud Platform(assertion.sub=='repo:octo-org/octo-repo:ref:refs/heads/demo-branch')
HashiCorp Vaultbound_subject="repo:octo-org/octo-repo:ref:refs/heads/demo-branch"

특정 클라우드 공급자를 구성하는 방법에 대한 자세한 내용은 배포 보안 강화에 나열된 가이드를 참조하세요.

토큰 클레임 사용자 지정

JWT에 포함된 클레임을 사용자 지정하여 OIDC 구성의 보안을 강화할 수 있습니다. 다음 사용자 지정을 사용하면 워크플로가 클라우드에서 호스팅되는 리소스에 액세스할 수 있도록 허용할 때 클라우드 역할에 대해 보다 세부적인 신뢰 조건을 정의할 수 있습니다.

  • audience 클레임에 대한 값을 사용자 지정할 수 있습니다. audience 값 사용자 지정을 참조하세요.
  • 특정 리포지토리, 재사용 가능한 워크플로 또는 기타 소스에서 발생하는 데 JWT 토큰이 필요한 주체(sub) 클레임에 대한 조건을 설정하여 OIDC 구성의 형식을 사용자 지정할 수 있습니다.
  • repository_idrepository_visibility 등과 같은 추가 OIDC 토큰 클레임을 사용하여 세분화된 OIDC 정책을 정의할 수 있습니다. OpenID Connect을(를) 참조하세요.

audience 값 사용자 지정

워크플로에서 사용자 지정 작업을 사용하는 경우 해당 작업은 GitHub Actions 도구 키트를 사용하여 audience 클레임에 대한 사용자 지정 값을 제공할 수 있습니다. 일부 클라우드 공급자 또한 공식 로그인 작업에서 이를 사용하여 audience 클레임에 대한 기본값을 적용합니다. 예를 들어 Azure 로그인에 대한 GitHub 작업에서 api://AzureADTokenExchange라는 기본 aud 값을 제공하거나, 사용자가 워크플로에서 사용자 지정 aud 값을 설정할 수 있습니다. GitHub Actions 도구 키트에 대한 자세한 내용은 설명서에서 "OIDC 토큰" 섹션을 참조하세요.

작업에서 제공하는 기본 aud 값을 사용하지 않으려는 경우 audience 클레임에 대한 사용자 지정 값을 제공할 수 있습니다. 그러면 특정 리포지토리 또는 조직의 워크플로만 클라우드 역할에 액세스할 수 있도록 조건을 설정할 수 있습니다. 사용 중인 작업이 이를 지원하는 경우 워크플로에 with 키워드를 사용하여 사용자 지정 aud 값을 작업에 전달할 수 있습니다. 자세한 내용은 메타데이터 구문 참조을(를) 참조하세요.

조직 또는 리포지토리에 대한 주체 클레임 사용자 지정

보안, 규정 준수, 표준화를 개선하기 위해 필요한 액세스 조건에 맞게 표준 클레임을 사용자 지정할 수 있습니다. 클라우드 공급자가 주체 클레임에 대한 조건을 지원하는 경우 sub값이 재사용 가능한 워크플로의 경로와 일치하는지 여부를 확인하는 조건을 만들 수 있습니다(예시: "job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"). 정확한 형식은 클라우드 공급자의 OIDC 구성에 따라 달라집니다. GitHub에서 일치 조건을 구성하려면 REST API를 사용하여 sub 클레임에 항상 특정 사용자 지정 클레임(예: job_workflow_ref)을 포함하도록 요구할 수 있습니다. REST API를 사용하여 OIDC 주체 클레임에 대한 사용자 지정 템플릿을 적용할 수 있습니다. 예를 들어, OIDC 토큰 내의 sub 클레임에 항상 특정 사용자 지정 클레임(예시: job_workflow_ref)을 포함하도록 요구할 수 있습니다. 자세한 내용은 GitHub Actions OIDC에 대한 REST API 엔드포인트을(를) 참조하세요.

참고 항목

조직 템플릿이 적용되면 리포지토리에서 사용자 지정 조직 템플릿을 선택하지 않는 한 이미 OIDC를 사용하고 있는 워크플로에는 영향을 미치지 않습니다. 기존 및 신규 리포지토리의 모든 리포지토리에서 리포지토리 소유자는 리포지토리 수준 REST API를 사용하여 use_default을(를) false(으)로 설정하여 이 구성을 수신하도록 옵트인해야 합니다. 또는 리포지토리 소유자가 REST API를 사용하여 리포지토리에 특정한 다른 구성을 적용할 수도 있습니다. 자세한 내용은 GitHub Actions OIDC에 대한 REST API 엔드포인트을(를) 참조하세요.

클레임을 사용자 지정하면 전체 sub 클레임에 대해 새 형식이 생성되며, 이는 예제 주체 클레임에 설명된 토큰의 기본 미리 정의된 sub 형식을 대체합니다.

참고 항목

sub클레임은 리포지토리를 참조할 때 repository 대신 축약된 형식인(예시: repo:ORG-NAME/REPO-NAME)을(를) 사용합니다repo. 컨텍스트 값 내의 :모든 항목이 %3A로 대체됩니다.

다음 예시 템플릿에서는 제목 클레임을 사용자 지정하는 다양한 방법을 보여줍니다. GitHub에서 이러한 설정을 구성하기 위해 관리자는 REST API를 사용하여 주체(sub) 클레임에 포함되어야 하는 클레임 목록을 지정합니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

주체 클레임을 사용자 지정하려면 먼저 REST API를 사용하여 구성을 사용자 지정하기 전에 클라우드 공급자의 OIDC 구성에서 일치하는 조건을 만들어야 합니다. 구성이 완료되면 새 작업이 실행될 때마다 해당 작업 중에 생성된 OIDC 토큰이 새 사용자 지정 템플릿을 따릅니다. 작업이 실행되기 전에 일치하는 조건이 클라우드 공급자의 OIDC 구성에 없는 경우 클라우드 조건이 동기화되지 않을 수 있으므로 생성된 토큰이 클라우드 공급자에 의해 수락되지 않을 수 있습니다.

예시: 표시 유형 및 소유자에 따라 리포지토리 허용

이 예시 템플릿을 사용하면 sub 클레임이 repository_ownerrepository_visibility를 사용하여 새 형식을 가질 수 있습니다.

{
   "include_claim_keys": [
       "repository_owner",
       "repository_visibility"
   ]
}

클라우드 공급자의 OIDC 구성에서 클레임에 repository_ownerrepository_visibility에 대한 특정 값을 포함해야 하는 sub 조건을 구성합니다. 예시: "sub": "repository_owner:monalisa:repository_visibility:private" 이 접근 방식을 사용하면 클라우드 역할 액세스를 조직 또는 엔터프라이즈 내의 프라이빗 리포지토리로만 제한할 수 있습니다.

예시: 특정 소유자에게 모든 리포지토리에 대한 액세스 허용

이 예시 템플릿을 사용하면 sub 클레임에 repository_owner의 값만 있는 새 형식을 사용할 수 있습니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

{
   "include_claim_keys": [
       "repository_owner"
   ]
}

클라우드 공급자의 OIDC 구성에서 클레임에 repository_owner에 대한 특정 값을 포함해야 하는 sub 조건을 구성합니다. 예시: "sub": "repository_owner:monalisa"

예시: 재사용 가능한 워크플로 필요

이 예시 템플릿을 사용하면 sub 클레임에 job_workflow_ref 클레임의 값이 포함된 새 형식을 갖도록 할 수 있습니다. 이를 통해 엔터프라이즈는 재사용 가능한 워크플로를 사용하여 조직 및 리포지토리에 일관된 배포를 적용할 수 있습니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

  {
     "include_claim_keys": [
         "job_workflow_ref"
     ]
  }

클라우드 공급자의 OIDC 구성에서 클레임에 job_workflow_ref에 대한 특정 값을 포함해야 하는 sub 조건을 구성합니다. 예시: "sub": "job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"

예시: 재사용 가능한 워크플로 및 기타 클레임 필요

다음 예시 템플릿은 재사용 가능한 특정 워크플로의 요구 사항을 추가 클레임과 결합합니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

이 예시에서는 "context"를 사용하여 조건을 정의하는 방법도 보여줍니다. 이 부분은 리포지토리를 기본 sub 형식으로 따르는 부분입니다. 예를 들어 작업이 환경을 참조할 때 컨텍스트에는 environment:ENVIRONMENT-NAME이 포함됩니다.

{
   "include_claim_keys": [
       "repo",
       "context",
       "job_workflow_ref"
   ]
}

클라우드 공급자의 OIDC 구성에서 클레임에 repo``contextjob_workflow_ref에 대한 특정 값을 포함해야 하는 sub 조건을 구성합니다.

이 사용자 지정 템플릿을 사용하려면 subrepo:ORG-NAME/REPO-NAME:environment:ENVIRONMENT-NAME:job_workflow_ref:REUSABLE-WORKFLOW-PATH 형식을 사용해야 합니다. 예시: "sub": "repo:octo-org/octo-repo:environment:prod:job_workflow_ref:octo-org/octo-automation/.github/workflows/oidc.yml@refs/heads/main"

예시: 특정 리포지토리에 대한 액세스 권한 부여

이 예시 템플릿을 사용하면 모든 분기/태그 및 환경에서 특정 리포지토리의 모든 워크플로에 클라우드 액세스 권한을 부여할 수 있습니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

{
   "include_claim_keys": [
       "repo"
   ]
}

클라우드 공급자의 OIDC 구성에서 필요한 값과 일치하는 repo 클레임을 요구하도록 sub 조건을 구성합니다.

예시: 시스템 생성 GUID 사용

이 예시 템플릿은 엔터티 이름 바꾸기(예시: 리포지토리 이름 바꾸기) 간에 변경되지 않는 시스템 생성 GUID를 사용하여 예측 가능한 OIDC 클레임을 사용하도록 설정합니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

  {
     "include_claim_keys": [
         "repository_id"
     ]
  }

클라우드 공급자의 OIDC 구성에서 필요한 값과 일치하는 repository_id 클레임을 요구하도록 sub 조건을 구성합니다.

또는:

{
   "include_claim_keys": [
       "repository_owner_id"
   ]
}

클라우드 공급자의 OIDC 구성에서 필요한 값과 일치하는 repository_owner_id 클레임을 요구하도록 sub 조건을 구성합니다.

예: :이 있는 컨텍스트 값

이 예제에서는 :을 사용하여 컨텍스트 값을 처리하는 방법을 보여 줍니다. 예를 들어 작업이 production:eastus라고 명명된 환경을 참조하는 경우입니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

{
   "include_claim_keys": [
       "environment",
       "repository_owner"
   ]
}

클라우드 공급자의 OIDC 구성에서 environmentrepository_owner에 대한 특정 값을 포함하도록 클레임에 sub 조건을 구성합니다. 예: "sub": "environment:production%3Aeastus:repository_owner:octo-org"

조직 템플릿 사용자 지정 재설정

이 예시 템플릿은 주체 클레임을 기본 형식으로 초기화합니다. 이 템플릿은 조직 수준 사용자 지정 정책을 효과적으로 옵트아웃합니다.

이 구성을 적용하려면 API 엔드포인트에 요청을 제출하고 요청 본문에 필요한 구성을 포함합니다. 조직의 경우 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하고 리포지토리는 GitHub Actions OIDC에 대한 REST API 엔드포인트 항목을 참조하세요.

{
   "include_claim_keys": [
       "repo",
       "context"
   ]
}

클라우드 공급자의 OIDC 구성에서 클레임에 repocontext에 대한 특정 값을 포함해야 하는 sub 조건을 구성합니다.

리포지토리 템플릿 사용자 지정 재설정

조직의 모든 리포지토리에는 사용자 지정 sub 클레임 템플릿을 옵트인 또는 옵트아웃(조직 및 리포지토리 수준)할 수 있는 기능이 있습니다.

리포지토리를 옵트아웃하고 기본 sub 클레임 형식으로 재설정하려면 리포지토리 관리자가 GitHub Actions OIDC에 대한 REST API 엔드포인트의 REST API 엔드포인트를 사용해야 합니다.

기본 sub 클레임 형식을 사용하도록 리포지토리를 구성하려면 다음 요청 본문과 함께 PUT /repos/{owner}/{repo}/actions/oidc/customization/sub REST API 엔드포인트를 사용합니다.

{
   "use_default": true
}

예시: 조직 템플릿을 사용하도록 리포지토리 구성

조직에서 사용자 지정 sub 클레임 템플릿을 만든 후에는 REST API를 사용하여 조직 내 리포지토리에 템플릿을 프로그래밍 방식으로 적용할 수 있습니다. 리포지토리 관리자는 조직의 관리자가 만든 템플릿을 사용하도록 리포지토리를 구성할 수 있습니다.

조직의 템플릿을 사용하도록 리포지토리를 구성하려면 리포지토리 관리자는 다음 요청 본문과 함께 PUT /repos/{owner}/{repo}/actions/oidc/customization/sub REST API 엔드포인트를 사용해야 합니다. 자세한 내용은 GitHub Actions OIDC에 대한 REST API 엔드포인트을(를) 참조하세요.

{
   "use_default": false
}

OIDC 클레임 디버깅

github/actions-oidc-debugger 작업을 사용하여 클라우드 공급자와 통합하기 전에 전송될 클레임을 시각화할 수 있습니다. 이 작업은 JWT를 요청하고 GitHub Actions에서 수신한 JWT 내에 포함된 클레임을 출력합니다.

OIDC 토큰을 요청하는 워크플로 권한

필요한 권한

  • 작업 또는 워크플로는 GitHub의 OIDC 공급자가 JWT(JSON Web Token)를 만들 수 있는 id-token: write 권한을 부여해야 합니다.

    permissions:
      id-token: write
    
  • id-token: write이 없으면 OIDC JWT ID 토큰을 요청할 수 없습니다. 이 설정을 사용하면 OIDC 토큰을 가져오고 설정할 수 있습니다. 다른 리소스에 대한 쓰기 액세스 권한을 부여하지 않습니다.

권한 설정

  • 워크플로에 대한 OIDC 토큰을 가져오려면 워크플로 수준에서 권한을 설정하세요.

    permissions:
      id-token: write # This is required for requesting the JWT
      contents: read # This is required for actions/checkout
    
  • 단일 작업에 대한 OIDC 토큰을 가져오려면 해당 작업 내에서 사용 권한을 설정하세요.

    permissions:
      id-token: write # This is required for requesting the JWT
    
  • 워크플로 요구 사항에 따라 추가 권한이 필요할 수 있습니다.

재사용 가능한 워크플로

  • 호출자 워크플로와 동일한 사용자, 조직, 엔터프라이즈가 소유한 재사용 가능한 워크플로의 경우, 호출자의 컨텍스트에서 재사용 가능한 워크플로에서 생성된 OIDC 토큰에 액세스할 수 있습니다.
  • 엔터프라이즈 또는 조직 외부에서 재사용 가능한 워크플로의 경우 호출자 워크플로 또는 작업 수준에서 id-token에 대한 permissions 설정을 명시적으로 write으로 설정하세요. 이렇게 하면 의도한 호출자 워크플로에서만 OIDC 토큰을 사용할 수 있습니다.

OIDC 토큰을 요청하는 메서드

사용자 지정 작업은 다음을 사용하여 OIDC 토큰을 요청할 수 있습니다.

  • Actions 도구 키트의 getIDToken() 메서드입니다. 자세한 내용은 npm 패키지 설명서에서 OIDC 토큰을 참조하세요.

  • 실행기에서 환경 변수는 다음과 같습니다.

    변수설명
    ACTIONS_ID_TOKEN_REQUEST_URLGitHub의 OIDC 공급자에 대한 URL
    ACTIONS_ID_TOKEN_REQUEST_TOKENOIDC 공급자에 대한 요청의 전달자 토큰

    예시:

    Shell
    curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=api://AzureADTokenExchange"