워크로드 아이덴티티와 AWS Roles Anywhere 구성

요약

Teleport 워크로드 아이덴티티는 X.509 인증서 형식으로 유연한 단기 유효 신원을 발급합니다. 이는 머신이 장기 자격 증명 없이 AWS 서비스에 안전하게 인증해야 하는 경우에 유용합니다. 이 구현은 Teleport Application Service를 사용하여 AWS API를 보호하는 것과 몇 가지 차이점이 있습니다:

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

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

작동 방식#

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

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

이 가이드는 주로 머신이 AWS에 접근할 수 있도록 하는 것을 목표로 하지만, tbot 대신 tsh svid issue 명령을 사용하여 사람이 AWS Roles Anywhere를 사용하여 인증하도록 허용할 수도 있습니다.

OIDC Federation vs Roles Anywhere#

AWS 플랫폼은 워크로드 신원 페더레이션을 위한 두 가지 방법을 제공합니다: OIDC Federation과 Roles Anywhere. Teleport 워크로드 아이덴티티는 두 가지 방법을 모두 지원합니다.

두 방법 간에는 몇 가지 차이점이 있습니다:

Roles Anywhere는 X509 SVID를 AWS 자격 증명으로 교환하는 반면, OIDC Federation은 JWT SVID를 AWS 자격 증명으로 교환합니다. X509 SVID 사용이 일반적으로 더 안전한 것으로 간주됩니다.
Roles Anywhere는 워크로드와 함께 AWS 자격 증명 헬퍼 설치가 필요한 반면, OIDC Federation은 그렇지 않습니다.
Roles Anywhere는 AWS에서 Teleport Proxy Service에 접근할 필요가 없는 반면, OIDC Federation은 필요합니다.

이 가이드는 Roles Anywhere 구성을 다룹니다. OIDC federation에 대해서는 워크로드 아이덴티티와 AWS OIDC Federation 구성을 참조하세요.

사전 요구 사항#

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이 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

SPIFFE ID 구조 결정#

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

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

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

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

1/4단계. AWS Roles Anywhere 구성#

처음으로 AWS Roles Anywhere를 구성하려면 몇 가지 단계가 필요합니다. Teleport 클러스터에 대해 이전에 AWS Roles Anywhere를 구성한 경우 일부 단계는 필요하지 않을 수 있습니다.

Roles Anywhere 신뢰 앵커 구성#

이전에 Teleport 클러스터에 대한 AWS Roles Anywhere를 구성한 경우 이 단계를 건너뛸 수 있습니다.

먼저 Teleport 클러스터와 AWS Roles Anywhere 간의 신뢰를 수립해야 합니다. 이를 통해 AWS가 Teleport 클러스터가 발급한 X.509 인증서를 검증할 수 있게 됩니다. 이는 Teleport 클러스터의 SPIFFE 인증 기관을 AWS Roles Anywhere의 신뢰 앵커로 구성함으로써 이루어집니다.

먼저 Teleport 클러스터의 SPIFFE CA를 가져와야 합니다:

$ tctl auth export --type tls-spiffe

이제 AWS 콘솔의 "Roles Anywhere"로 이동하여 "Create a trust anchor"를 클릭합니다. 설명적인 이름을 지정해야 합니다. Teleport 클러스터의 이름에 "spiffe"를 추가하는 것을 권장합니다.

"External certificate bundle"을 선택한 다음 tctl 명령에서 받은 출력을 텍스트 상자에 붙여넣습니다.

이제 "Create trust anchor" 버튼을 클릭할 수 있습니다.

역할 생성#

다음으로 워크로드가 맡을 AWS 역할을 생성해야 합니다. 기존 역할의 신뢰 정책을 수정하는 것도 가능합니다.

AWS IAM 콘솔의 "Roles" 섹션으로 이동하여 "Create role"을 클릭합니다.

"Trusted entity type"으로 "Custom trust policy"를 선택합니다.

이제 다음을 입력합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession",
                "sts:SetSourceIdentity"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/x509SAN/URI": "spiffe://example.teleport.sh/svc/example-service"
                },
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:12345789:trust-anchor/0000000-0000-0000-0000-000000000000"
                }
            }
        }
    ]
}

교체할 내용:

spiffe://example.teleport.sh/my-workload를 워크로드에 선택한 SPIFFE ID로 교체합니다.
arn:aws:rolesanywhere:us-east-1:12345789:trust-anchor/0000000-0000-0000-0000-000000000000을 이전 단계에서 생성한 신뢰 앵커의 ARN으로 교체합니다.

"Next"를 클릭하여 "Add permissions" 페이지로 진행합니다. 이제 AWS에서 워크로드에 부여할 권한을 선택합니다.

"Next"를 클릭하여 "Name, review, and create" 페이지로 진행합니다. 역할에 설명적인 이름을 지정합니다. 예: "my-workload-roles-anywhere".

"Create role"을 클릭합니다.

Roles Anywhere 프로필 생성#

마지막으로 Roles Anywhere 프로필을 생성해야 합니다.

AWS IAM 콘솔의 "Roles Anywhere" 섹션으로 돌아가서 "Create a profile"을 클릭합니다.

프로필에 설명적인 이름을 지정합니다. 예: "my-workload".

이전 단계에서 생성한 역할을 선택합니다.

"Create profile"을 클릭합니다.

2/4단계. Teleport RBAC 구성#

이제 선택한 SPIFFE ID를 포함하는 X.509 인증서가 발급될 수 있도록 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

이 SPIFFE ID를 사람에게 발급하려는 경우 해당 사용자에게 이 역할을 할당해야 합니다:

$ tctl edit user/my-user
# 그리고 사용자의 역할 목록에 역할을 추가합니다

이 SPIFFE ID를 머신에 발급하려는 경우 봇에 이 역할을 할당해야 합니다:

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

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

`tbot`을 사용하는 머신의 경우#

머신의 경우 tbot 서비스를 사용하여 백그라운드 프로세스로 SPIFFE SVID를 발급하고 갱신할 수 있습니다.

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

services:
  - type: workload-identity-x509
    destination:
      type: directory
      path: /opt/roles-anywhere-svid
    selector:
      name: example-workload-identity

교체할 내용:

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

새 구성을 적용하려면 tbot 서비스를 재시작합니다.

`tsh`를 사용하는 사람의 경우#

사람의 경우 tsh CLI를 사용하여 기존 인증 세션을 통해 SPIFFE SVID를 발급할 수 있습니다.

SVID가 만료되면 tsh 명령을 다시 실행해야 합니다. 기본적으로 SVID는 1시간 TTL로 발급되지만 최대 24시간까지 구성할 수 있습니다. 엔지니어가 하루 업무 시작 시 한 번만 명령을 실행할 수 있도록 약 8시간으로 구성하는 것이 편리할 수 있습니다.

예를 들어 8시간 TTL로 /svc/example-service에 대한 SPIFFE SVID를 발급하려면:

$ tsh workload-identity issue-x509 --name-selector example-workload-identity --credential-ttl 8h --output /opt/roles-anywhere-svid

4/4단계. Roles Anywhere를 사용한 인증을 위한 AWS CLI 및 SDK 구성#

AWS가 인증에 SVID를 사용하려면 AWS Roles Anywhere 자격 증명 헬퍼도 설치해야 합니다. 이는 AWS CLI와 SDK가 SVID를 임시 AWS 자격 증명으로 교환하는 데 사용하는 작은 유틸리티입니다.

AWS Identity and Access Management Roles Anywhere에서 임시 보안 자격 증명 획득 가이드에서 자격 증명 헬퍼의 최신 릴리즈를 받습니다.

이제 이 자격 증명 헬퍼를 활용하는 프로필을 구성해야 합니다.

~/.aws/config 파일에 다음을 추가합니다:

[profile use-roles-anywhere]
credential_process = ./aws_signing_helper credential-process --certificate /opt/roles-anywhere-svid/svid.pem --private-key /opt/roles-anywhere-svid/svid_key.pem --profile-arn $PROFILE_ARN --trust-anchor-arn $TRUST_ANCHOR_ARN --role-arn $ROLE_ARN

$PROFILE_ARN, $TRUST_ANCHOR_ARN, $ROLE_ARN을 이전 단계에서 생성한 프로필, 신뢰 앵커, 역할의 ARN으로 교체합니다.

이제 AWS CLI에서 use-roles-anywhere 프로필을 사용할 수 있습니다. 예를 들면:

$ aws --profile use-roles-anywhere s3 ls

AWS_PROFILE 환경 변수를 설정하여 AWS SDK에서도 이 프로필을 사용할 수 있습니다:

$ export AWS_PROFILE=use-roles-anywhere
$ ./my-app

다음 단계#

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

워크로드 아이덴티티와 AWS Roles Anywhere 구성

원문 보기

번역일: 2026-05-14

요약

작동 방식#

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

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

OIDC Federation vs Roles Anywhere#

두 방법 간에는 몇 가지 차이점이 있습니다:

Roles Anywhere는 X509 SVID를 AWS 자격 증명으로 교환하는 반면, OIDC Federation은 JWT SVID를 AWS 자격 증명으로 교환합니다. X509 SVID 사용이 일반적으로 더 안전한 것으로 간주됩니다.
Roles Anywhere는 워크로드와 함께 AWS 자격 증명 헬퍼 설치가 필요한 반면, OIDC Federation은 그렇지 않습니다.
Roles Anywhere는 AWS에서 Teleport Proxy Service에 접근할 필요가 없는 반면, OIDC Federation은 필요합니다.

이 가이드는 Roles Anywhere 구성을 다룹니다. OIDC federation에 대해서는 워크로드 아이덴티티와 AWS OIDC Federation 구성을 참조하세요.

사전 요구 사항#

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이 이미 설치되고 구성되어 있어야 합니다. 자세한 내용은 배포 가이드를 참조하세요.

SPIFFE ID 구조 결정#

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

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

1/4단계. AWS Roles Anywhere 구성#

Roles Anywhere 신뢰 앵커 구성#

이전에 Teleport 클러스터에 대한 AWS Roles Anywhere를 구성한 경우 이 단계를 건너뛸 수 있습니다.

먼저 Teleport 클러스터의 SPIFFE CA를 가져와야 합니다:

$ tctl auth export --type tls-spiffe

"External certificate bundle"을 선택한 다음 tctl 명령에서 받은 출력을 텍스트 상자에 붙여넣습니다.

이제 "Create trust anchor" 버튼을 클릭할 수 있습니다.

역할 생성#

다음으로 워크로드가 맡을 AWS 역할을 생성해야 합니다. 기존 역할의 신뢰 정책을 수정하는 것도 가능합니다.

AWS IAM 콘솔의 "Roles" 섹션으로 이동하여 "Create role"을 클릭합니다.

"Trusted entity type"으로 "Custom trust policy"를 선택합니다.

이제 다음을 입력합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "rolesanywhere.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession",
                "sts:SetSourceIdentity"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/x509SAN/URI": "spiffe://example.teleport.sh/svc/example-service"
                },
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:rolesanywhere:us-east-1:12345789:trust-anchor/0000000-0000-0000-0000-000000000000"
                }
            }
        }
    ]
}

교체할 내용:

spiffe://example.teleport.sh/my-workload를 워크로드에 선택한 SPIFFE ID로 교체합니다.
arn:aws:rolesanywhere:us-east-1:12345789:trust-anchor/0000000-0000-0000-0000-000000000000을 이전 단계에서 생성한 신뢰 앵커의 ARN으로 교체합니다.

"Next"를 클릭하여 "Add permissions" 페이지로 진행합니다. 이제 AWS에서 워크로드에 부여할 권한을 선택합니다.

"Next"를 클릭하여 "Name, review, and create" 페이지로 진행합니다. 역할에 설명적인 이름을 지정합니다. 예: "my-workload-roles-anywhere".

"Create role"을 클릭합니다.

Roles Anywhere 프로필 생성#

마지막으로 Roles Anywhere 프로필을 생성해야 합니다.

AWS IAM 콘솔의 "Roles Anywhere" 섹션으로 돌아가서 "Create a profile"을 클릭합니다.

프로필에 설명적인 이름을 지정합니다. 예: "my-workload".

이전 단계에서 생성한 역할을 선택합니다.

"Create profile"을 클릭합니다.

2/4단계. Teleport RBAC 구성#

이제 선택한 SPIFFE ID를 포함하는 X.509 인증서가 발급될 수 있도록 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

이 SPIFFE ID를 사람에게 발급하려는 경우 해당 사용자에게 이 역할을 할당해야 합니다:

$ tctl edit user/my-user
# 그리고 사용자의 역할 목록에 역할을 추가합니다

이 SPIFFE ID를 머신에 발급하려는 경우 봇에 이 역할을 할당해야 합니다:

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

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

`tbot`을 사용하는 머신의 경우#

머신의 경우 tbot 서비스를 사용하여 백그라운드 프로세스로 SPIFFE SVID를 발급하고 갱신할 수 있습니다.

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

services:
  - type: workload-identity-x509
    destination:
      type: directory
      path: /opt/roles-anywhere-svid
    selector:
      name: example-workload-identity

교체할 내용:

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

새 구성을 적용하려면 tbot 서비스를 재시작합니다.

`tsh`를 사용하는 사람의 경우#

사람의 경우 tsh CLI를 사용하여 기존 인증 세션을 통해 SPIFFE SVID를 발급할 수 있습니다.

예를 들어 8시간 TTL로 /svc/example-service에 대한 SPIFFE SVID를 발급하려면:

$ tsh workload-identity issue-x509 --name-selector example-workload-identity --credential-ttl 8h --output /opt/roles-anywhere-svid

4/4단계. Roles Anywhere를 사용한 인증을 위한 AWS CLI 및 SDK 구성#

AWS Identity and Access Management Roles Anywhere에서 임시 보안 자격 증명 획득 가이드에서 자격 증명 헬퍼의 최신 릴리즈를 받습니다.

이제 이 자격 증명 헬퍼를 활용하는 프로필을 구성해야 합니다.

~/.aws/config 파일에 다음을 추가합니다:

[profile use-roles-anywhere]
credential_process = ./aws_signing_helper credential-process --certificate /opt/roles-anywhere-svid/svid.pem --private-key /opt/roles-anywhere-svid/svid_key.pem --profile-arn $PROFILE_ARN --trust-anchor-arn $TRUST_ANCHOR_ARN --role-arn $ROLE_ARN

$PROFILE_ARN, $TRUST_ANCHOR_ARN, $ROLE_ARN을 이전 단계에서 생성한 프로필, 신뢰 앵커, 역할의 ARN으로 교체합니다.

이제 AWS CLI에서 use-roles-anywhere 프로필을 사용할 수 있습니다. 예를 들면:

$ aws --profile use-roles-anywhere s3 ls

AWS_PROFILE 환경 변수를 설정하여 AWS SDK에서도 이 프로필을 사용할 수 있습니다:

$ export AWS_PROFILE=use-roles-anywhere
$ ./my-app

다음 단계#

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

워크로드 아이덴티티와 AWS Roles Anywhere 구성

작동 방식#

OIDC Federation vs Roles Anywhere#

사전 요구 사항#

SPIFFE ID 구조 결정#

1/4단계. AWS Roles Anywhere 구성#

Roles Anywhere 신뢰 앵커 구성#

역할 생성#

Roles Anywhere 프로필 생성#

2/4단계. Teleport RBAC 구성#

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

tbot을 사용하는 머신의 경우#

tsh를 사용하는 사람의 경우#

4/4단계. Roles Anywhere를 사용한 인증을 위한 AWS CLI 및 SDK 구성#

다음 단계#

작동 방식#

OIDC Federation vs Roles Anywhere#

사전 요구 사항#

SPIFFE ID 구조 결정#

1/4단계. AWS Roles Anywhere 구성#

Roles Anywhere 신뢰 앵커 구성#

역할 생성#

Roles Anywhere 프로필 생성#

2/4단계. Teleport RBAC 구성#

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

tbot을 사용하는 머신의 경우#

tsh를 사용하는 사람의 경우#

4/4단계. Roles Anywhere를 사용한 인증을 위한 AWS CLI 및 SDK 구성#

다음 단계#

`tbot`을 사용하는 머신의 경우#

`tsh`를 사용하는 사람의 경우#

`tbot`을 사용하는 머신의 경우#

`tsh`를 사용하는 사람의 경우#