워크로드 아이덴티티와 Azure Federated Credentials 구성

요약

Teleport 워크로드 아이덴티티는 JWT 형식으로 유연한 단기 유효 신원을 발급합니다. 이는 머신이 장기 자격 증명 없이 Azure 서비스에 안전하게 인증해야 하는 경우에 유용합니다. 이 가이드에서는 Teleport 워크로드 아이덴티티와 Azure를 구성하여 워크로드가 Azure Blob Storage에 인증하고 컨테이너에 콘텐츠를 업로드할 수 있도록 합니다.

Teleport 워크로드 아이덴티티는 JWT 형식으로 유연한 단기 유효 신원을 발급합니다. Azure Federated Credentials를 사용하면 이러한 JWT를 Azure 서비스에 인증하는 데 활용할 수 있습니다.

이는 머신이 장기 자격 증명 없이 Azure 서비스에 안전하게 인증해야 하는 경우에 유용합니다. 머신은 위임된 조인 방법 중 하나를 사용하여 공유 시크릿 없이 Teleport에 인증할 수 있기 때문입니다.

이 가이드에서는 Teleport 워크로드 아이덴티티와 Azure를 구성하여 워크로드가 Azure Blob Storage에 인증하고 컨테이너에 콘텐츠를 업로드할 수 있도록 합니다.

작동 방식#

이 구현은 Teleport Application Service를 사용하여 Azure API를 보호하는 것과 몇 가지 차이점이 있습니다:

Azure에 대한 요청이 Teleport Proxy Service를 통해 프록시되지 않아 지연 시간이 줄어들지만, 이러한 요청이 Teleport의 감사 로그에 기록되지 않아 가시성도 낮아집니다.
워크로드 아이덴티티는 명령줄 도구뿐만 아니라 SDK를 포함한 모든 Azure 클라이언트와 함께 작동합니다.
Teleport Application Service를 사용하여 Azure에 접근하는 것은 머신 및 워크로드 아이덴티티와 함께 작동하지 않으므로 머신이 Azure에 인증해야 할 때는 사용할 수 없습니다.

사전 요구 사항#

A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.
The tctl and tsh clients.
Installing `tctl` and `tsh` clients
1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:
```
$ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
```
2. Follow the instructions for your platform to install tctl and tsh clients:

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

Teleport 워크로드 아이덴티티에 접근해야 하는 워크로드가 실행될 호스트에 tbot이 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.
워크로드에 접근 권한을 부여할 Azure 리소스 그룹 및 구독.

SPIFFE ID 구조 결정#

Teleport 워크로드 아이덴티티 내에서 모든 신원은 SPIFFE ID를 사용하여 표현됩니다. 이는 신원이 나타내는 엔티티를 고유하게 식별하는 URI입니다. 스키마는 항상 spiffe://이며, 호스트는 Teleport 클러스터의 이름이 됩니다. 이 URI의 경로 구조는 사용자가 결정합니다.

이 가이드의 목적을 위해 spiffe://example.teleport.sh/svc/example-service SPIFFE ID에 Azure 접근 권한을 부여합니다.

Teleport 워크로드 아이덴티티를 이미 배포했다면 SPIFFE ID 구조가 이미 갖춰져 있을 것입니다. 그렇지 않다면 SPIFFE ID 구조를 결정해야 합니다.

Azure Federated Credentials와 함께만 Teleport 워크로드 아이덴티티를 사용하는 경우, SPIFFE ID가 맡을 수 있는 Azure 사용자 관리 신원을 명시적으로 지정하도록 구조화할 수 있습니다. 그러나 SPIFFE ID를 사용할 워크로드나 사람의 이름을 지정하는 것이 더 합리적인 경우가 많습니다. 추가적인 조언은 모범 사례 가이드를 참조하세요.

1/4단계. Azure 구성#

워크로드 아이덴티티 JWT SVID를 인증으로 수락하도록 Azure를 구성하려면 Azure 내에서 해당 워크로드를 나타내는 신원을 생성하고, 해당 신원이 Teleport 클러스터에서 발급한 JWT SVID를 페더레이션 자격 증명으로 수락하도록 구성하고, Azure 역할 할당을 사용하여 해당 신원에 필요한 권한을 부여해야 합니다.

사용자 관리 신원 생성#

먼저 Azure 내에서 워크로드를 나타내는 사용자 관리 신원을 생성합니다.

Azure Portal의 "Managed Identities" 섹션으로 이동합니다.
"Create"를 선택하여 "Create User Assigned Managed Identity" 양식을 엽니다.
리소스 그룹과 구독을 선택합니다.
나타낼 워크로드를 설명하는 고유한 이름을 입력합니다. 이 예제에서는 "example-service"를 사용합니다.
"Review + create"를 선택합니다.

이제 이후 단계에서 사용할 생성된 사용자 관리 신원에 대한 주요 정보를 기록해야 합니다.

생성된 사용자 관리 신원의 "Properties" 섹션으로 이동하여 "Client Id"와 "Tenant Id"를 메모합니다. 이 값들은 모두 UUID입니다.

페더레이션 자격 증명 생성#

다음으로 사용자 관리 신원에 대한 페더레이션 자격 증명을 구성해야 합니다. 이를 통해 Azure가 Teleport 클러스터에서 발급한 JWT SVID를 이 사용자 관리 신원에 대한 인증 형태로 수락하도록 구성됩니다.

Azure Portal에서 사용자 관리 신원으로 이동하여 "Settings" 섹션의 "Federated credentials" 페이지를 선택합니다.
"Add Credential"을 선택하여 "Add Federated Credential" 양식을 엽니다.
"Federated credential scenario"로 "Other"를 선택합니다.
Teleport Proxy 서비스 주소 뒤에 /workload-identity를 추가하여 "Issuer URL"로 입력합니다. 예를 들어 https://example.teleport.sh/workload-identity.
"Subject identifier" 필드에 워크로드에 선택한 SPIFFE ID를 입력합니다. 예를 들어 spiffe://example.teleport.sh/svc/example-service. 이를 통해 어떤 Teleport 워크로드 아이덴티티가 발급한 JWT SVID가 이 사용자 관리 신원에 수락될지 제어됩니다.
페더레이션 자격 증명에 대한 고유하고 식별 가능한 이름을 입력합니다. 예를 들어 example-teleport-sh-svc-example-service.
"Add"를 클릭합니다.

스토리지 계정 및 컨테이너 생성#

이 가이드의 목적을 위해 워크로드가 인증할 스토리지 계정과 컨테이너를 생성합니다. 워크로드에 접근 권한을 부여할 리소스가 이미 있는 경우 이 단계를 건너뛸 수 있습니다.

먼저 스토리지 계정을 생성합니다:

Azure Portal의 "Storage accounts" 섹션으로 이동하여 "Create" 버튼을 선택하여 "Create a storage account" 양식을 엽니다.
리소스 그룹과 구독을 선택합니다.
스토리지 계정에 대한 고유하고 식별 가능한 이름을 입력합니다. 나중에 필요하므로 기록해 둡니다. 이 예제에서는 examplestorageaccount를 사용합니다.
지역을 선택하고 "Primary Service" 필드로 "Azure Blob Storage"를 선택합니다.
"Create"를 클릭합니다.

이제 스토리지 컨테이너를 생성할 수 있습니다:

Azure Portal의 "Storage accounts" 섹션으로 이동하여 생성한 스토리지 계정을 선택합니다.
"Data storage" 섹션 아래의 "Containers" 섹션으로 이동합니다.
"Add container"를 선택하여 "New container" 양식을 엽니다.
컨테이너에 대한 고유하고 식별 가능한 이름을 입력합니다. 나중에 필요하므로 기록해 둡니다. 이 예제에서는 examplecontainer를 사용합니다.

역할 할당 생성#

마지막으로 사용자 관리 신원에 워크로드가 Azure 내에서 수행해야 하는 작업을 수행하는 데 필요한 권한을 부여해야 합니다.

Azure에서 역할 할당을 생성할 때 다양한 수준으로 범위를 지정할 수 있습니다:

구독 (구독 내의 모든 리소스에 대한 접근 권한 부여)
리소스 그룹 (리소스 그룹 내의 모든 리소스에 대한 접근 권한 부여)
리소스 (특정 리소스에 대한 접근 권한 부여)

이 가이드의 목적을 위해 생성한 스토리지 계정의 범위로 사용자 관리 신원에 Storage Blob Data Owner 역할을 부여합니다.

Azure Portal의 "Storage accounts" 섹션으로 이동하여 생성한 스토리지 계정을 선택합니다.
사이드바에서 "Access control (IAM)"으로 이동한 다음 "Add"와 "Add role assignment"를 선택합니다.
"Role"에서 "Storage Blob Data Owner"를 선택합니다.
"Members"에서 "Assign access to"로 "Managed identity"를 선택한 다음 "Select members"를 누릅니다.
"Managed identity"에서 "User-assigned managed identity"를 선택한 다음 이전에 생성한 사용자 관리 신원을 검색하여 선택합니다.
"Review + assign"을 클릭하고 변경 사항을 저장합니다.

2/4단계. Teleport RBAC 구성#

이제 선택한 SPIFFE ID를 포함하는 JWT가 발급될 수 있도록 Teleport를 구성해야 합니다.

먼저 신원과 그 특성을 정의하는 워크로드 아이덴티티 리소스를 생성합니다. workload-identity.yaml이라는 새 파일을 생성합니다:

kind: workload_identity
version: v1
metadata:
  name: example-workload-identity
  labels:
    example: getting-started
spec:
  spiffe:
    id: /svc/example-service

교체할 내용:

example-workload-identity를 워크로드 아이덴티티에 대한 설명적인 이름으로 교체합니다.
/svc/example-service를 선택한 SPIFFE ID의 경로 부분으로 교체합니다.

tctl을 사용하여 클러스터에 적용합니다:

$ tctl create -f workload-identity.yaml

다음으로 이 워크로드 아이덴티티에 대한 접근 권한을 부여하는 역할을 생성합니다. 다음 내용으로 role.yaml을 생성합니다:

kind: role
version: v6
metadata:
  name: example-workload-identity-issuer
spec:
  allow:
    workload_identity_labels:
      example: ["getting-started"]
    rules:
    - resources:
      - workload_identity
      verbs:
      - list
      - read

교체할 내용:

example-workload-identity-issuer를 역할에 대한 설명적인 이름으로 교체합니다.
워크로드 아이덴티티의 레이블을 수정한 경우 레이블 선택기를 교체합니다.

tctl을 사용하여 Teleport 클러스터에 이 역할을 적용합니다:

$ tctl create -f role.yaml

이제 봇에 이 역할을 할당해야 합니다:

$ tctl bots update my-bot --add-roles example-workload-identity-issuer

3/4단계. 워크로드 아이덴티티 JWT 발급#

이제 워크로드를 위한 단기 유효 JWT SVID를 발급하고 갱신하도록 tbot을 구성합니다. JWT를 디스크의 파일로 쓰면 Azure 클라이언트와 SDK가 이를 읽도록 구성할 수 있습니다.

이미 배포된 tbot 서비스를 가져와서 tbot 구성 파일에 다음을 추가하여 SPIFFE SVID를 발급하도록 구성합니다:

services:
  - type: workload-identity-jwt
    destination:
      type: directory
      path: /opt/workload-identity
    selector:
      name: example-workload-identity
    audiences: ["api://AzureADTokenExchange"]

교체할 내용:

/opt/workload-identity를 JWT를 쓰려는 디렉터리로 교체합니다.
example-workload-identity를 생성한 워크로드 아이덴티티의 이름으로 교체합니다.

새 구성을 적용하려면 tbot 서비스를 재시작합니다. JWT를 포함하는 /opt/workload-identity/jwt_svid 파일이 생성되어야 합니다.

4/4단계. Azure CLI 및 SDK 구성#

이제 발급된 JWT SVID를 사용하여 Azure에 인증할 수 있습니다. 구성 방법은 Azure CLI와 Azure SDK에 따라 다릅니다.

Azure CLI 구성#

JWT SVID를 사용하여 Azure CLI로 인증하려면 JWT와 생성한 사용자 관리 신원의 클라이언트 및 테넌트 ID를 지정하여 로그인을 수행합니다. 이를 통해 JWT SVID를 Azure 액세스 토큰으로 초기 교환이 이루어지며, 이 토큰은 액세스 토큰이 만료될 때까지 CLI에 캐시됩니다.

첫 번째 단계에서 기록한 클라이언트와 테넌트 ID를 삽입하여 다음을 실행합니다:

$ az login \
  --federated-token $(cat /opt/workload-identity/jwt_svid) \
  --service-principal \
  -u <user-managed-identity-client-id> \
  -t <user-managed-identity-tenant-id>

성공했음을 나타내는 메시지가 표시됩니다.

이제 Azure Blob Storage 컨테이너에 파일을 업로드하여 성공 여부를 테스트할 수 있습니다:

$ echo "testing 1,2,3..." > test.txt
# 테스트 파일 업로드. 계정과 컨테이너 이름을 이전에 선택한 것으로 교체합니다.
$ az storage blob upload \
  --auth login \
  --account-name examplestorageaccount \
  --container-name examplecontainer \
  --name test.txt \
  --file ./test.txt
# 파일이 업로드되었는지 확인합니다. 계정과 컨테이너 이름을
# 이전에 선택한 것으로 교체합니다.
$ az storage blob list \
  --auth login \
  --output table \
  --account-name examplestorageaccount \
  --container-name examplecontainer

Azure SDK 구성#

Azure SDK는 발급된 JWT SVID를 사용하여 페더레이션 자격 증명으로 인증하도록 구성하는 환경 변수 세트를 지원합니다:

AZURE_CLIENT_ID: 사용자 관리 신원의 클라이언트 ID.
AZURE_TENANT_ID: 사용자 관리 신원의 테넌트 ID.
AZURE_FEDERATED_TOKEN_FILE: JWT SVID 파일 경로, 예를 들어 /opt/workload-identity/jwt_svid.

SDK를 페더레이션 자격 증명을 사용하도록 명시적으로 구성할 수도 있으며, 이는 언어마다 다릅니다.

다음 단계#

Azure 워크로드 아이덴티티 Federation: 워크로드 아이덴티티 Federation에 대한 공식 Azure 문서.
워크로드 아이덴티티 개요: Teleport 워크로드 아이덴티티 개요.
JWT SVID 개요: Teleport 워크로드 아이덴티티가 발급하는 JWT SVID 개요.
모범 사례: 프로덕션에서 Workload Identity 사용을 위한 모범 사례.
구성 참조를 읽어 사용 가능한 모든 구성 옵션을 살펴보세요.

워크로드 아이덴티티와 Azure Federated Credentials 구성

원문 보기

번역일: 2026-05-14

요약

작동 방식#

이 구현은 Teleport Application Service를 사용하여 Azure API를 보호하는 것과 몇 가지 차이점이 있습니다:

Azure에 대한 요청이 Teleport Proxy Service를 통해 프록시되지 않아 지연 시간이 줄어들지만, 이러한 요청이 Teleport의 감사 로그에 기록되지 않아 가시성도 낮아집니다.
워크로드 아이덴티티는 명령줄 도구뿐만 아니라 SDK를 포함한 모든 Azure 클라이언트와 함께 작동합니다.
Teleport Application Service를 사용하여 Azure에 접근하는 것은 머신 및 워크로드 아이덴티티와 함께 작동하지 않으므로 머신이 Azure에 인증해야 할 때는 사용할 수 없습니다.

사전 요구 사항#

A running Teleport cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.
The tctl and tsh clients.
Installing `tctl` and `tsh` clients
1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:
```
$ TELEPORT_DOMAIN=
$ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
```
2. Follow the instructions for your platform to install tctl and tsh clients:

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

Teleport 워크로드 아이덴티티에 접근해야 하는 워크로드가 실행될 호스트에 tbot이 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.
워크로드에 접근 권한을 부여할 Azure 리소스 그룹 및 구독.

SPIFFE ID 구조 결정#

이 가이드의 목적을 위해 spiffe://example.teleport.sh/svc/example-service SPIFFE ID에 Azure 접근 권한을 부여합니다.

Teleport 워크로드 아이덴티티를 이미 배포했다면 SPIFFE ID 구조가 이미 갖춰져 있을 것입니다. 그렇지 않다면 SPIFFE ID 구조를 결정해야 합니다.

1/4단계. Azure 구성#

사용자 관리 신원 생성#

먼저 Azure 내에서 워크로드를 나타내는 사용자 관리 신원을 생성합니다.

Azure Portal의 "Managed Identities" 섹션으로 이동합니다.
"Create"를 선택하여 "Create User Assigned Managed Identity" 양식을 엽니다.
리소스 그룹과 구독을 선택합니다.
나타낼 워크로드를 설명하는 고유한 이름을 입력합니다. 이 예제에서는 "example-service"를 사용합니다.
"Review + create"를 선택합니다.

이제 이후 단계에서 사용할 생성된 사용자 관리 신원에 대한 주요 정보를 기록해야 합니다.

생성된 사용자 관리 신원의 "Properties" 섹션으로 이동하여 "Client Id"와 "Tenant Id"를 메모합니다. 이 값들은 모두 UUID입니다.

페더레이션 자격 증명 생성#

Azure Portal에서 사용자 관리 신원으로 이동하여 "Settings" 섹션의 "Federated credentials" 페이지를 선택합니다.
"Add Credential"을 선택하여 "Add Federated Credential" 양식을 엽니다.
"Federated credential scenario"로 "Other"를 선택합니다.
Teleport Proxy 서비스 주소 뒤에 /workload-identity를 추가하여 "Issuer URL"로 입력합니다. 예를 들어 https://example.teleport.sh/workload-identity.
"Subject identifier" 필드에 워크로드에 선택한 SPIFFE ID를 입력합니다. 예를 들어 spiffe://example.teleport.sh/svc/example-service. 이를 통해 어떤 Teleport 워크로드 아이덴티티가 발급한 JWT SVID가 이 사용자 관리 신원에 수락될지 제어됩니다.
페더레이션 자격 증명에 대한 고유하고 식별 가능한 이름을 입력합니다. 예를 들어 example-teleport-sh-svc-example-service.
"Add"를 클릭합니다.

스토리지 계정 및 컨테이너 생성#

먼저 스토리지 계정을 생성합니다:

Azure Portal의 "Storage accounts" 섹션으로 이동하여 "Create" 버튼을 선택하여 "Create a storage account" 양식을 엽니다.
리소스 그룹과 구독을 선택합니다.
스토리지 계정에 대한 고유하고 식별 가능한 이름을 입력합니다. 나중에 필요하므로 기록해 둡니다. 이 예제에서는 examplestorageaccount를 사용합니다.
지역을 선택하고 "Primary Service" 필드로 "Azure Blob Storage"를 선택합니다.
"Create"를 클릭합니다.

이제 스토리지 컨테이너를 생성할 수 있습니다:

Azure Portal의 "Storage accounts" 섹션으로 이동하여 생성한 스토리지 계정을 선택합니다.
"Data storage" 섹션 아래의 "Containers" 섹션으로 이동합니다.
"Add container"를 선택하여 "New container" 양식을 엽니다.
컨테이너에 대한 고유하고 식별 가능한 이름을 입력합니다. 나중에 필요하므로 기록해 둡니다. 이 예제에서는 examplecontainer를 사용합니다.

역할 할당 생성#

마지막으로 사용자 관리 신원에 워크로드가 Azure 내에서 수행해야 하는 작업을 수행하는 데 필요한 권한을 부여해야 합니다.

Azure에서 역할 할당을 생성할 때 다양한 수준으로 범위를 지정할 수 있습니다:

구독 (구독 내의 모든 리소스에 대한 접근 권한 부여)
리소스 그룹 (리소스 그룹 내의 모든 리소스에 대한 접근 권한 부여)
리소스 (특정 리소스에 대한 접근 권한 부여)

이 가이드의 목적을 위해 생성한 스토리지 계정의 범위로 사용자 관리 신원에 Storage Blob Data Owner 역할을 부여합니다.

Azure Portal의 "Storage accounts" 섹션으로 이동하여 생성한 스토리지 계정을 선택합니다.
사이드바에서 "Access control (IAM)"으로 이동한 다음 "Add"와 "Add role assignment"를 선택합니다.
"Role"에서 "Storage Blob Data Owner"를 선택합니다.
"Members"에서 "Assign access to"로 "Managed identity"를 선택한 다음 "Select members"를 누릅니다.
"Managed identity"에서 "User-assigned managed identity"를 선택한 다음 이전에 생성한 사용자 관리 신원을 검색하여 선택합니다.
"Review + assign"을 클릭하고 변경 사항을 저장합니다.

2/4단계. Teleport RBAC 구성#

이제 선택한 SPIFFE ID를 포함하는 JWT가 발급될 수 있도록 Teleport를 구성해야 합니다.

먼저 신원과 그 특성을 정의하는 워크로드 아이덴티티 리소스를 생성합니다. workload-identity.yaml이라는 새 파일을 생성합니다:

kind: workload_identity
version: v1
metadata:
  name: example-workload-identity
  labels:
    example: getting-started
spec:
  spiffe:
    id: /svc/example-service

교체할 내용:

example-workload-identity를 워크로드 아이덴티티에 대한 설명적인 이름으로 교체합니다.
/svc/example-service를 선택한 SPIFFE ID의 경로 부분으로 교체합니다.

tctl을 사용하여 클러스터에 적용합니다:

$ tctl create -f workload-identity.yaml

다음으로 이 워크로드 아이덴티티에 대한 접근 권한을 부여하는 역할을 생성합니다. 다음 내용으로 role.yaml을 생성합니다:

kind: role
version: v6
metadata:
  name: example-workload-identity-issuer
spec:
  allow:
    workload_identity_labels:
      example: ["getting-started"]
    rules:
    - resources:
      - workload_identity
      verbs:
      - list
      - read

교체할 내용:

example-workload-identity-issuer를 역할에 대한 설명적인 이름으로 교체합니다.
워크로드 아이덴티티의 레이블을 수정한 경우 레이블 선택기를 교체합니다.

tctl을 사용하여 Teleport 클러스터에 이 역할을 적용합니다:

$ tctl create -f role.yaml

이제 봇에 이 역할을 할당해야 합니다:

$ tctl bots update my-bot --add-roles example-workload-identity-issuer

3/4단계. 워크로드 아이덴티티 JWT 발급#

이미 배포된 tbot 서비스를 가져와서 tbot 구성 파일에 다음을 추가하여 SPIFFE SVID를 발급하도록 구성합니다:

services:
  - type: workload-identity-jwt
    destination:
      type: directory
      path: /opt/workload-identity
    selector:
      name: example-workload-identity
    audiences: ["api://AzureADTokenExchange"]

교체할 내용:

/opt/workload-identity를 JWT를 쓰려는 디렉터리로 교체합니다.
example-workload-identity를 생성한 워크로드 아이덴티티의 이름으로 교체합니다.

새 구성을 적용하려면 tbot 서비스를 재시작합니다. JWT를 포함하는 /opt/workload-identity/jwt_svid 파일이 생성되어야 합니다.

4/4단계. Azure CLI 및 SDK 구성#

이제 발급된 JWT SVID를 사용하여 Azure에 인증할 수 있습니다. 구성 방법은 Azure CLI와 Azure SDK에 따라 다릅니다.

Azure CLI 구성#

첫 번째 단계에서 기록한 클라이언트와 테넌트 ID를 삽입하여 다음을 실행합니다:

$ az login \
  --federated-token $(cat /opt/workload-identity/jwt_svid) \
  --service-principal \
  -u <user-managed-identity-client-id> \
  -t <user-managed-identity-tenant-id>

성공했음을 나타내는 메시지가 표시됩니다.

이제 Azure Blob Storage 컨테이너에 파일을 업로드하여 성공 여부를 테스트할 수 있습니다:

$ echo "testing 1,2,3..." > test.txt
# 테스트 파일 업로드. 계정과 컨테이너 이름을 이전에 선택한 것으로 교체합니다.
$ az storage blob upload \
  --auth login \
  --account-name examplestorageaccount \
  --container-name examplecontainer \
  --name test.txt \
  --file ./test.txt
# 파일이 업로드되었는지 확인합니다. 계정과 컨테이너 이름을
# 이전에 선택한 것으로 교체합니다.
$ az storage blob list \
  --auth login \
  --output table \
  --account-name examplestorageaccount \
  --container-name examplecontainer

Azure SDK 구성#

Azure SDK는 발급된 JWT SVID를 사용하여 페더레이션 자격 증명으로 인증하도록 구성하는 환경 변수 세트를 지원합니다:

AZURE_CLIENT_ID: 사용자 관리 신원의 클라이언트 ID.
AZURE_TENANT_ID: 사용자 관리 신원의 테넌트 ID.
AZURE_FEDERATED_TOKEN_FILE: JWT SVID 파일 경로, 예를 들어 /opt/workload-identity/jwt_svid.

SDK를 페더레이션 자격 증명을 사용하도록 명시적으로 구성할 수도 있으며, 이는 언어마다 다릅니다.

다음 단계#

Azure 워크로드 아이덴티티 Federation: 워크로드 아이덴티티 Federation에 대한 공식 Azure 문서.
워크로드 아이덴티티 개요: Teleport 워크로드 아이덴티티 개요.
JWT SVID 개요: Teleport 워크로드 아이덴티티가 발급하는 JWT SVID 개요.
모범 사례: 프로덕션에서 Workload Identity 사용을 위한 모범 사례.
구성 참조를 읽어 사용 가능한 모든 구성 옵션을 살펴보세요.