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

디자인 파트너십

우리는 Teleport Workload Identity의 미래를 함께 만들어 나갈 디자인 파트너를 적극적으로 찾고 있으며, 귀하의 피드백을 듣고 싶습니다.

Teleport Workload Identity는 X.509 인증서에서 유연한 짧은 수명의 아이덴티티를 발급합니다. AWS Roles Anywhere를 사용하면 이러한 인증서를 사용하여 AWS 서비스에 인증할 수 있습니다.

이것은 기계가 장기 자격 증명의 사용 없이 AWS 서비스에 안전하게 인증해야 하는 경우에 유용할 수 있습니다. 이는 기계가 공유 비밀 없이 당사의 위임된 조인 방법 중 하나를 사용하여 Teleport와 인증할 수 있기 때문입니다.

작동 방식

이 구현은 Teleport 애플리케이션 서비스를 사용하여 AWS API를 보호하는 것과 몇 가지 면에서 다릅니다:

AWS에 대한 요청은 Teleport Proxy Service를 통해 프록시되지 않으므로 지연 시간이 단축되지만 이러한 요청은 Teleport의 감사 로그에 기록되지 않아 가시성이 줄어듭니다.
Workload Identity는 명령줄 도구를 포함한 모든 AWS 클라이언트와 함께 작동하지만, 그들의 SDK를 포함합니다.
AWS에 접근하기 위한 Teleport 애플리케이션 서비스 사용은 머신 ID와 작동하지 않으므로 기계가 AWS에 인증해야 할 때 사용할 수 없습니다.

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

OIDC 연합 vs Roles Anywhere

AWS 플랫폼은 워크로드 아이덴티티 연합을 위한 두 가지 경로를 제공합니다: OIDC 연합과 Roles Anywhere. Teleport Workload Identity는 이 두 가지 방법을 모두 지원합니다.

두 방법 간에는 여러 가지 차이가 있습니다:

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

이 가이드는 Roles Anywhere 구성을 다루고 있으며, OIDC 연합에 대해서는 워크로드 아이덴티티 및 AWS OIDC 연합 구성을 참조하십시오.

필수 조건

실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
tctl 관리자 도구와 tsh 클라이언트 도구.

tctl 및 tsh 다운로드 방법에 대한 지침은 설치를 방문하십시오.

연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
```
tsh login --proxy=teleport.example.com --user=email@example.com
tctl status
클러스터  teleport.example.com
버전  17.0.0-dev
CA 핀   sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
```
클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
tbot 은 워크로드가 Teleport Workload Identity에 접근해야 하는 호스트에 이미 설치되고 구성되어 있어야 합니다. 자세한 정보는 배포 가이드를 참조하십시오.

SPIFFE ID 구조 결정

Teleport Workload Identity 내에서 모든 아이덴티티는 SPIFFE ID를 사용하여 표현됩니다. 이는 아이덴티티가 나타내는 엔터티를 고유하게 식별하는 URI입니다. 스키마는 항상 spiffe://이며, 호스트는 Teleport 클러스터의 이름이 됩니다. 이 URI의 경로 구조는 귀하에게 달려 있습니다.

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

이미 Teleport Workload Identity를 배포했다면 이미 SPIFFE ID 구조가 설정되어 있을 것입니다. 배포하지 않은 경우, SPIFFE ID에 대한 구조를 결정해야 합니다.

AWS Roles Anywhere와 함께 Teleport Workload Identity만 사용하는 경우, 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"로 이동하여 "신뢰 앵커 생성"을 클릭합니다. 설명적인 이름을 지정해야 하며, Teleport 클러스터의 이름 뒤에 "spiffe"를 붙이는 것을 추천합니다.

"외부 인증서 번들"을 선택한 후, tctl 명령에서 받은 출력을 텍스트 상자에 붙여넣습니다.

이제 "신뢰 앵커 생성" 버튼을 클릭할 수 있습니다.

역할 생성

다음으로, 워크로드가 맡을 수 있는 역할을 AWS에서 생성해야 합니다. 원하는 경우 기존 역할의 신뢰 정책을 수정할 수도 있습니다.

AWS IAM 콘솔의 "역할" 섹션으로 이동하여 "역할 생성"을 클릭합니다.

"신뢰하는 엔터티 유형"에서 "사용자 지정 신뢰 정책"을 선택합니다.

이제 다음 내용을 입력합니다:

{
  "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으로 교체합니다.

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

"다음"을 클릭하여 "이름, 검토 및 생성" 페이지로 진행합니다. 역할에 설명적인 이름을 지정합니다. 예: "my-workload-roles-anywhere".

"역할 생성"을 클릭합니다.

Roles Anywhere 프로필 생성

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

AWS IAM 콘솔의 "Roles Anywhere" 섹션으로 다시 이동하여 "프로필 생성"을 클릭합니다.

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

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

"프로필 생성"을 클릭합니다.

2/4단계. Teleport RBAC 구성

이제 우리는 Teleport를 구성하여 선택한 SPIFFE ID를 포함하는 X.509 인증서를 발급할 수 있게 해야 합니다.

다음 내용을 사용하여 role.yaml 을 만드세요:

kind: role
version: v6
metadata:
  name: my-workload-roles-anywhere
spec:
  allow:
    spiffe:
      - path: /svc/example-service

다음을 교체하세요:

my-workload-roles-anywhere 를 역할에 대한 설명 이름으로 변경하세요.
/my-workload 를 선택한 SPIFFE ID의 경로 부분으로 변경하세요.

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

tctl create -f role.yaml

이 SPIFFE ID가 사람에 의해 발급되기를 원한다면, 이제 이 역할을 그들의 사용자에게 할당해야 합니다:

tctl edit user/my-user
그리고 사용자의 역할 목록에 역할을 추가하세요

이 SPIFFE ID가 기계에 의해 발급되기를 원한다면, 이제 이 역할을 봇에게 할당해야 합니다:

tctl bots update my-bot --add-roles my-workload-roles-anywhere

3/4단계. Workload Identity 인증서 발급

기계를 위한 `tbot` 사용

기계의 경우, tbot 서비스를 사용하여 SPIFFE SVID를 발급하고 갱신할 수 있습니다.

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

outputs:
  - type: spiffe-svid
    destination:
      type: directory
      path: /opt/roles-anywhere-svid
    svid:
      path: /svc/example-service

새 구성을 적용하기 위해 tbot 서비스를 재시작하세요.

사람을 위한 `tsh` 사용

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

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

예를 들어, /svc/example-service 에 대해 8시간 TTL을 가진 SPIFFE SVID를 발급하려면:

tsh svid issue --output /opt/roles-anywhere-svid --svid-ttl 8h /svc/example-service

4/4단계. AWS CLI와 SDK를 Roles Anywhere로 인증 사용하도록 구성

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으로 교체하세요.

이제 use-roles-anywhere 프로필을 AWS CLI와 함께 사용할 수 있습니다. 예를 들어:

aws --profile use-roles-anywhere s3 ls

이 프로필을 AWS SDK와 함께 사용하려면 AWS_PROFILE 환경 변수를 설정하세요:

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

다음 단계

AWS Roles Anywhere documentation: Roles Anywhere에 대한 공식 AWS 문서입니다.
Workload Identity Overview: Teleport Workload Identity 개요.
Best Practices: 프로덕션에서 Workload Identity를 사용할 때의 모범 사례.
모든 사용 가능한 구성 옵션을 탐색하려면 configuration reference를 읽어보세요.

Teleport 원문 보기