Teleport Workload Identity는 JWT 형식으로 유연한 단기 아이덴티티를 발급합니다.
AWS OIDC 연합을 사용하면 이러한 JWT를 사용하여 AWS 서비스에 인증할 수 있습니다.

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

이 가이드에서는 Teleport Workload Identity와 AWS를 구성하여
우리의 워크로드가 AWS S3 API에 인증하고 버킷에 콘텐츠를 업로드할 수 있도록 합니다.

작동 방식

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

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

OIDC 연합 vs Roles Anywhere

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

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

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

이 가이드에서는 OIDC 연합 구성을 다룹니다. Roles Anywhere에 대한 내용은
워크로드 아이덴티티 및 AWS Roles Anywhere 구성를 참조하세요.

전제 조건

• 실행 중인 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 OIDC 연합과 함께 Teleport Workload Identity만 사용하는 경우,
당신의 SPIFFE ID를 그들이 맡을 수 있는 AWS 역할을 명시적으로 지정하도록 구조화할 수 있습니다.
그러나 보통은 SPIFFE ID를 사용할 사람이나 워크로드의 이름을 지정하는 것이 더 의미가 있습니다.
모범 사례 가이드에서 추가 조언을 참조하세요.

1/4단계. AWS 구성

AWS OIDC 연합을 처음 구성하는 데는 몇 가지 단계가 포함됩니다. 이전에 Teleport 클러스터에 대해 AWS OIDC 연합을 구성한 경우 일부 단계는 필요하지 않을 수 있습니다.

OpenID Connect ID 공급자 만들기

먼저, AWS에서 OIDC ID 공급자를 만들어야 합니다. 이는 AWS와 Teleport 클러스터의 Workload Identity 발급자 간의 신뢰 관계를 정의합니다. 이 OIDC ID 공급자를 재사용하여 Teleport Workload Identity를 사용하는 다양한 워크로드가 AWS 서비스에 접근할 수 있도록 할 수 있습니다.

공급자를 구성할 때 발급자 URI를 지정해야 합니다. 이는 /workload-identity 경로가 추가된 Teleport Proxy Service의 공개 주소가 됩니다. OIDC 연합이 작동하려면 Teleport Proxy Service에 AWS가 접근할 수 있어야 합니다.

curl https://example.teleport.sh/webapi/thumbprint
"example589ee4bf31a11b78c72b8d13f0example"%

resource "aws_iam_openid_connect_provider" "example_teleport_sh_workload_identity" {
  // "example.teleport.sh"를 Teleport Proxy Service에 접근하는 데 사용되는 호스트 이름으로 바꿉니다.
  url = "https://example.teleport.sh/workload-identity"

  client_id_list = [
    "sts.amazonaws.com",
  ]

  thumbprint_list = [
    // curl을 사용하여 확인한 지문으로 바꿉니다.
    "example589ee4bf31a11b78c72b8d13f0example"
  ]
}

S3 버킷 만들기

이 가이드를 위해 워크로드에 AWS S3 버킷에 대한 접근 권한을 부여합니다. RBAC 구성을 진행하기 전, 먼저 버킷을 생성해야 합니다.

AWS 내에서 다른 서비스에 접근을 부여하려는 경우 이 단계를 생략할 수 있습니다.

// S3 버킷 생성
resource "aws_s3_bucket" "example" {
  // "example"을 의미 있고 고유한 이름으로 바꿉니다.
  bucket = "workload-id-demo"
}

RBAC 구성

IAM 정책 만들기

먼저, S3 버킷에 대한 접근을 부여하는 IAM 정책을 만들어야 합니다. 이후에 이 정책을 워크로드가 맡을 역할에 연결할 것입니다.

이 가이드의 예제에서는 예제 버킷에 대한 완전한 접근을 부여하는 IAM 정책을 생성합니다. 운영 환경에서는 최소한의 권한을 부여하도록 수정해야 합니다.

resource "aws_iam_policy" "example" {
  // 정책이 부여하는 접근 권한을 설명하는 고유하고 의미 있는 이름을 선택합니다.
  name        = "workload-id-s3-full-access"
  path        = "/"

  // 이 예제 정책은 AWS S3에 대한 완전한 접근을 부여합니다. 운영 환경에서는
  // 덜 허용적인 정책을 부여할 수 있습니다.
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "s3:*"
      Effect = "Allow"
      Resource = [
        aws_s3_bucket.workload_id_demo.arn,
        "${aws_s3_bucket.workload_id_demo.arn}/*"
      ]
    }]
  })
}

IAM 역할 생성

이제 IAM 역할을 생성합니다. 이 역할은 Teleport Workload Identity에서 발급한 JWT SVID를 사용하여 AWS에 인증한 후 워크로드에 의해 사용됩니다.

IAM 역할을 생성할 때는 어떤 워크로드 ID가 역할을 맡을 수 있는지를 제어하는 신뢰 정책을 정의합니다. 이 정책은 Teleport Workload Identity에서 발급한 JWT SVID 내의 클레임에 대해 평가될 조건을 포함합니다. 우리의 경우, 평가하고자 하는 유일한 클레임은 우리의 워크로드 SPIFFE ID가 포함된 sub 클레임입니다.

마지막으로, 이전에 생성한 IAM 정책을 이 역할에 첨부하여 정책 내에서 지정된 권한을 부여합니다.

// 워크로드 ID가 맡을 역할을 생성합니다.
resource "aws_iam_role" "example" {
  // 역할과 이 역할을 맡을 워크로드를 설명하는 고유하고 의미 있는 이름을 선택합니다.
  name = "workload-id-demo"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.example.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "${aws_iam_openid_connect_provider.example.url}:aud" = "sts.amazonaws.com"
          "${aws_iam_openid_connect_provider.example.url}:sub" = "spiffe://example.teleport.sh/svc/example-service"
        }
      }
    }]
  })
}

// 이전에 생성한 정책을 우리 역할에 첨부합니다.
resource "aws_iam_role_policy_attachment" "example" {
    role       = aws_iam_role.example.name
    policy_arn = aws_iam_policy.example.arn
}

2/4단계. Teleport RBAC 구성

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

다음 내용을 가진 role.yaml 을 만듭니다:

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

다음을 대체하세요:

• my-workload-aws 를 역할에 대한 설명적인 이름으로 변경합니다.
• /svc/example-service 를 선택한 SPIFFE ID의 경로 부분으로 변경합니다.

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

tctl create -f role.yaml

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

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

3/4단계. 작업 부하 ID JWT 발급

이제 tbot 을 구성하여 작업 부하의 단기 JWT SVID를 발급하고 갱신합니다. JWT는 디스크에 파일로 작성되며, 이후 AWS 클라이언트 및 SDK가 이를 읽을 수 있습니다.

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

outputs:
  - type: spiffe-svid
    destination:
      type: directory
      path: /opt/workload-identity
    svid:
      path: /svc/example-service
    jwts:
      - audience: sts.amazonaws.com
        file_name: aws-jwt

다음을 교체합니다:

• /opt/workload-identity을 JWT가 기록될 디렉토리로 바꿉니다.
• /svc/example-service를 선택한 SPIFFE ID로 바꿉니다.

새 구성을 적용하려면 tbot 서비스를 재시작해야 합니다. /opt/workload-identity/aws-jwt 위치에 JWT가 포함된 파일이 생성됩니다.

4/4단계. AWS CLI 및 SDK 구성

마지막으로, AWS CLI 및 SDK가 인증을 위해 JWT SVID를 사용하도록 구성해야 합니다.

이는 ~/.aws/config 에 있는 구성 파일을 사용하거나 환경 변수를 사용하여 수행할 수 있습니다.

계속 진행하려면 이전에 생성한 역할의 ARN을 알아야 합니다.

# "workload-id-demo"를 사용 사례를 식별할 수 있는 인지 가능한 이름으로
# 교체할 수 있습니다.
[profile workload-id-demo]
# 이전에 생성한 역할의 ARN으로 교체합니다.
role_arn=arn:aws:iam:123456789012:role/workload-id-demo
# `tbot` 가 JWT를 기록하도록 구성한 디렉토리 및 파일 이름으로 교체합니다.
web_identity_token_file=/opt/workload-identity/aws-jwt

이제 AWS S3 API에 인증 테스트를 할 수 있습니다. 버킷에 업로드할 파일을 만듭니다:

echo "Hello, World!" > hello.txt

이제 AWS CLI를 사용하여 이 파일을 버킷에 업로드합니다:

aws s3 cp hello.txt s3://workload-id-demo

모두 올바르게 구성되었다면, 이 파일이 버킷에 업로드된 것을 확인할 수 있습니다:

aws s3 ls s3://workload-id-demo

CloudTrail의 감사 로그를 검사하면 요청이 Workload Identity를 사용하여 인증된 것을 나타내고 요청한 작업 부하의 SPIFFE ID를 명시합니다.

다음 단계

• AWS OIDC Federation: OIDC 연합에 대한 공식 AWS 문서.
• AWS CLI 문서: 역할을 가정하도록 구성하는 공식 AWS CLI 문서.
• 워크로드 ID 개요: Teleport Workload Identity의 개요.
• JWT SVID 개요: Teleport Workload Identity에서 발급한 JWT SVID의 개요.
• 모범 사례: 운영 환경에서 Workload Identity를 사용할 때의 모범 사례.
• 모든 사용 가능한 구성 옵션을 탐색하기 위한 구성 참조 읽기.