Infograb logo
Amazon Athena 액세스

Teleport의 지원을 사용하여 Amazon Athena에 대한 안전한 액세스를 설정할 수 있습니다. AWS CLI 및 콘솔을 사용해 보세요.

이 가이드는 다음을 도와줍니다:

  • Teleport 애플리케이션 서비스를 설치하세요.
  • AWS CLI 및 콘솔 액세스를 설정하세요.
  • Athena 데이터베이스에 연결하세요.

필수 조건

  • AWS 계정이 Athena 데이터베이스로 구성되어 있습니다.
  • IAM 역할을 생성할 수 있는 IAM 권한이 필요합니다.
  • aws 명령줄 인터페이스(CLI) 도구가 PATH에 설치되어 있어야 합니다.
  • Teleport 애플리케이션 서비스를 실행할 호스트(예: EC2 인스턴스)가 필요합니다.
  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctltsh 다운로드에 대한 지침은 설치를 방문하세요.

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오. 예를 들어:
    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status

    클러스터 teleport.example.com

    버전 16.2.0

    CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다. 자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.
아직 Teleport 사용자이신가요?

Auth 서비스와 프록시 서비스를 아직 배포하지 않으셨다면, 다음 중 하나의 시작 가이드를 따르거나 우리의 Teleport 애플리케이션 접근 상호작용 학습 트랙을 시도해보세요.

당신의 Teleport 클러스터가 teleport.example.com*.teleport.example.com에서 접근 가능하다고 가정합니다. 당신은 Teleport 프록시 서비스의 주소를 대체할 수 있습니다. (Teleport Cloud 고객의 경우, 이는 mytenant.teleport.sh와 유사합니다.)

애플리케이션 접근 및 DNS

Teleport은 애플리케이션 접근을 위해 구성한 각 애플리케이션에 서브도메인을 할당합니다. 예를 들어, Grafana를 리소스로 등록하면 Teleport은 리소스를 grafana.teleport.example.com 서브도메인에 할당합니다.

Teleport 클러스터를 자체 네트워크에서 호스팅하는 경우, 애플리케이션 서브도메인을 반영하도록 DNS 구성을 업데이트해야 합니다.
DNS를 업데이트하는 방법은 두 가지가 있습니다:

  • 서브도메인 이름에 대한 와일드카드 치환을 사용하여 단일 DNS 주소(A) 또는 정식 이름(CNAME) 레코드를 생성합니다. 예를 들어, *.teleport.example.com이라는 이름으로 DNS 레코드를 생성합니다.
  • 각 애플리케이션 서브도메인에 대해 별도의 DNS 주소(A) 또는 정식 이름(CNAME) 레코드를 생성합니다.

DNS 수정은 인증 기관(예: Let's Encrypt)이 각 서브도메인에 대해 인증서를 발급할 수 있도록 하며, 클라이언트가 접근하는 애플리케이션에 관계없이 Teleport 호스트를 확인할 수 있도록 합니다.

Teleport 클라우드 플랫폼을 사용하는 경우, DNS 업데이트가 필요하지 않습니다. 왜냐하면 Teleport 클러스터가 자동으로 서브도메인과 서명된 TLS 인증서를 제공하기 때문입니다.

1단계/5단계. Athena 액세스를 위한 IAM 역할 생성

IAM 역할을 생성하여 Athena 리소스에 대한 액세스를 제공합니다. Teleport Application Service는 이러한 Athena 리소스에 액세스하는 Teleport 사용자를 대신하여 이 IAM 역할을 맡습니다.

IAM 역할을 생성하는 방법에는 여러 가지가 있습니다:

Roles 페이지로 이동하여
"Create Role"을 누릅니다.

"AWS account" 옵션을 선택하여
이 계정의 다른 엔터티가 이 역할을 맡을 수 있도록 기본 신뢰 정책을 생성합니다:

"Next"를 누릅니다. AWS 관리형 정책 AmazonAthenaFullAccess를 찾아서 선택합니다:

"Next"를 누릅니다. 역할 이름 ExampleTeleportAthenaRole을 입력하고 "Create role"을 누릅니다:

다음 신뢰 정책으로 파일을 생성합니다. aws-account-id를 AWS 계정 ID로 바꿉니다:

cat > trust-relationship.json <<EOF{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::aws-account-id:root" }, "Action": "sts:AssumeRole" } ] } EOF undefined

이름이 ExampleTeleportAthenaRole인 IAM 역할을 생성합니다:

aws iam create-role --role-name ExampleTeleportAthenaRole --assume-role-policy-document file://trust-relationship.json

역할에 관리형 정책 AmazonAthenaFullAccess를 연결합니다:

aws iam attach-role-policy --role-name ExampleTeleportAthenaRole --policy-arn arn:aws:iam::aws:policy/AmazonAthenaFullAccess

Terraform 배포에 다음 리소스를 추가합니다. aws-account-id를 AWS 계정 ID로 바꿉니다:

cat > teleport_iam_role_ExampleTeleportAthenaRole.tf <<EOFresource "aws_iam_role" "teleport-ExampleTeleportAthenaRole" { name = "ExampleTeleportAthenaRole" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Effect = "Allow" Principal = { AWS = "arn:aws:iam::aws-account-id:root" } Action = "sts:AssumeRole" }, ] }) } resource "aws_iam_role_policy_attachment" "teleport-ExampleTeleportAthenaRole-AmazonAthenaFullAccess" { role = aws_iam_role.teleport-ExampleTeleportAthenaRole.name policy_arn = "arn:aws:iam::aws:policy/AmazonAthenaFullAccess" } EOF undefined

그런 다음 terraform apply를 실행합니다.

최소 권한 부여 적용

AmazonAthenaFullAccess는 귀하의 의도에 비해 너무 많은 액세스를 제공할 수 있습니다. 권한을 줄이기 위해 다른 IAM 정책을 사용하려면 Athena에서의 신원 및 액세스 관리를 참조해 주세요.

2단계/5단계. Teleport IAM 역할 매핑 구성

Teleport 사용자에게 Teleport 클러스터에서 IAM 역할을 가정할 수 있는 권한을 부여하세요. 이를 위해 이전 단계에서 생성한 IAM 역할 ARN을 나열하는 aws_role_arns 필드를 가진 Teleport 역할을 생성할 수 있습니다. 다음 내용을 포함하는 aws-athena-access.yaml이라는 파일을 만드세요:

cat > aws-athena-access.yaml <<EOFkind: roleversion: v5metadata: name: aws-athena-accessspec: allow: app_labels: '*': '*' aws_role_arns: - arn:aws:iam::aws-account-id:role/ExampleTeleportAthenaRoleEOF

aws-account-id를 AWS 계정 ID로 교체하는 것을 잊지 마세요.

aws_role_arns 필드는 템플릿 변수를 지원하므로 사용자의 신원 공급자 속성을 기반으로 동적으로 채워질 수 있습니다. 다음은 몇 가지 예제입니다:

역할 정의에 {{internal.aws_role_arns}}를 사용하세요:

kind: role
version: v5
metadata:
  name: aws-athena-access
spec:
  allow:
    app_labels:
      '*': '*'
    aws_role_arns: ['{{internal.aws_role_arns}}']

그런 다음 사용자 특성을 통해 IAM 역할을 지정하세요:

kind: user
version: v2
metadata:
  name: alice
spec:
  roles: ['aws-athena-access']
  traits:
    aws_role_arns: ['arn:aws:iam:123456789000:role/role_for_alice']
---
kind: user
version: v2
metadata:
  name: bob
spec:
  roles: ['aws-athena-access']
  traits:
    aws_role_arns: ['arn:aws:iam:123456789000:role/role_for_bob']

각 Teleport 사용자에 대해 IAM 역할이 생성되었다고 가정하고, IAM 역할의 이름은 이메일 주소에서 이메일 도메인 접미사를 제외한 이름과 일치합니다.

그러면 aws_role_arnsexternal.email으로 템플릿화할 수 있습니다:

kind: role
version: v5
metadata:
  name: aws-athena-access
spec:
  allow:
    app_labels:
      '*': '*'
    aws_role_arns: ['arn:aws:iam:123456789000:role/{{email.local(external.email)}}']

자세한 내용은 역할 템플릿을 참조하세요.

새 역할을 생성하세요:

tctl create -f aws-athena-access.yaml

aws-athena-access 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

  1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:

    ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
  2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:

    tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},aws-athena-access"
  3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. github 인증 커넥터를 가져옵니다:

    tctl get github/github --with-secrets > github.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.

  2. github.yaml을 편집하고 teams_to_roles 섹션에 aws-athena-access을 추가합니다.

    이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

    여기에 예시가 있습니다:

      teams_to_roles:
        - organization: octocats
          team: admins
          roles:
            - access
    +       - aws-athena-access
    
  3. 변경 사항을 적용합니다:

    tctl create -f github.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

  1. saml 구성 리소스를 가져옵니다:

    tctl get --with-secrets saml/mysaml > saml.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.

  2. saml.yaml을 편집하고 attributes_to_roles 섹션에 aws-athena-access을 추가합니다.

    이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      attributes_to_roles:
        - name: "groups"
          value: "my-group"
          roles:
            - access
    +       - aws-athena-access
    
  3. 변경 사항을 적용합니다:

    tctl create -f saml.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. oidc 구성 리소스를 가져옵니다:

    tctl get oidc/myoidc --with-secrets > oidc.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.

  2. oidc.yaml을 편집하고 claims_to_roles 섹션에 aws-athena-access을 추가합니다.

    이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      claims_to_roles:
        - name: "groups"
          value: "my-group"
          roles:
            - access
    +       - aws-athena-access
    
  3. 변경 사항을 적용합니다:

    tctl create -f oidc.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

3단계/5단계. Teleport 애플리케이션 서비스 설치

토큰 생성

Teleport 애플리케이션 서비스 인스턴스가 클러스터에 참여할 수 있도록 승인하기 위해서는 조인 토큰이 필요합니다. 단기간 사용할 수 있는 조인 토큰을 생성하고 명령의 출력을 저장합니다:

tctl tokens add \ --type=app \ --app-name=aws \ --app-uri=https://console.aws.amazon.com/console/home

Teleport 애플리케이션 서비스를 실행할 호스트에서 토큰을 /tmp/token이라는 파일에 복사합니다.

비표준 AWS 지역

AWS GovCloud(US) 지역용으로는 https://console.aws.amazon.comhttps://console.amazonaws-us-gov.com로 교체하거나 AWS 중국 지역용으로는 https://console.amazonaws.cn로 교체하세요.

Teleport 설치 및 시작

Teleport 애플리케이션 서비스를 실행할 호스트에 Teleport를 설치하세요. Linux 서버 외에 다른 옵션은 설치 페이지를 참조하세요.

Linux 서버에 Teleport 설치하기:

  1. Teleport 에디션에 따라 edition을(를) 다음 중 하나로 지정합니다:

    에디션
    Teleport Enterprise Cloudcloud
    Teleport Enterprise (자체 호스팅)enterprise
    Teleport Community Editionoss
  2. 설치할 Teleport의 버전을 확인합니다. 클러스터에서 자동 에이전트 업데이트가 활성화되어 있는 경우, 업데이터와 호환되는 최신 Teleport 버전을 쿼리합니다:

    TELEPORT_DOMAIN=example.teleport.com
    TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/automaticupgrades/channel/default/version | sed 's/v//')"

    그렇지 않으면, Teleport 클러스터의 버전을 확인합니다:

    TELEPORT_DOMAIN=example.teleport.com
    TELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/ping | jq -r '.server_version')"
  3. Linux 서버에 Teleport를 설치합니다:

    curl https://cdn.teleport.dev/install-v16.2.0.sh | bash -s ${TELEPORT_VERSION} edition

    설치 스크립트는 Linux 서버에서 패키지 관리자를 감지하고 이를 사용하여 Teleport 바이너리를 설치합니다. 설치를 사용자 지정하려면 설치 가이드에서 Teleport 패키지 리포지토리에 대해 알아보세요.

Teleport 구성 파일(/etc/teleport.yaml)을 편집하여 다음 정보를 포함시키고, proxy_server의 값을 조정하여 Teleport 프록시 서비스의 호스트와 포트를 지정합니다:

version: v3
teleport:
  join_params:
    token_name: "/tmp/token"
    method: token
  proxy_server: "teleport.example.com:443"
auth_service:
  enabled: off
proxy_service:
  enabled: off
ssh_service:
  enabled: off
app_service:
  enabled: true
  apps:
  - name: aws
    uri: https://console.aws.amazon.com/home/home

the Teleport Application Service에 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여합니다.

the Teleport Application Service를 EC2 인스턴스에서 실행하는 경우 EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다. 그렇지 않은 경우 환경 변수를 사용해야 합니다:

Teleport는 EC2 인스턴스에서 실행될 때 이를 감지하고 인스턴스 메타데이터 서비스를 사용하여 자격 증명을 가져옵니다.

EC2 인스턴스는 EC2 인스턴스 프로파일을 사용하도록 구성되어 있어야 합니다. 자세한 내용은 인스턴스 프로파일 사용하기를 참조하세요.

Teleport의 내장 AWS 클라이언트는 다음 환경 변수에서 자격 증명을 읽습니다:

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_DEFAULT_REGION

the Teleport Application Service를 시작하면 서비스는 /etc/default/teleport 경로의 파일에서 환경 변수를 읽습니다. 이 자격 증명은 귀하의 조직에서 가져오십시오. /etc/default/teleport에 다음 내용을 포함하고 각 변수의 값을 대체해야 합니다:

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Teleport의 AWS 클라이언트는 자격 증명을 다음 순서로 다양한 출처에서 로드합니다:

  • 환경 변수
  • 공유 자격 증명 파일
  • 공유 구성 파일 (Teleport는 항상 공유 구성을 활성화합니다)
  • EC2 인스턴스 메타데이터 (자격 증명 전용)

공유 자격 증명 파일 또는 공유 구성 파일을 통해 AWS 자격 증명을 제공할 수 있지만, the Teleport Application Service를 실행할 때 AWS_PROFILE 환경 변수를 선택한 프로파일의 이름으로 지정해야 합니다.

위의 지침이 고려하지 않은 특정 사용 사례가 있는 경우, 자격 증명 로딩 동작에 대한 자세한 설명을 보려면 AWS SDK for Go의 문서를 참조하십시오.

호스트가 부팅될 때 the Teleport Application Service가 자동으로 시작되도록 시스템 데몬 서비스를 생성하여 구성합니다. 지침은 the Teleport Application Service를 설치한 방법에 따라 다릅니다.

the Teleport Application Service를 실행할 호스트에서 Teleport를 활성화하고 시작하십시오:

sudo systemctl enable teleport
sudo systemctl start teleport

the Teleport Application Service를 실행할 호스트에서 Teleport에 대한 시스템 데몬 서비스 구성을 생성하고, Teleport 서비스를 활성화한 후 Teleport를 시작하십시오:

sudo teleport install systemd -o /etc/systemd/system/teleport.service
sudo systemctl enable teleport
sudo systemctl start teleport

the Teleport Application Service의 상태는 systemctl status teleport로 확인할 수 있으며, 로그는 journalctl -fu teleport로 볼 수 있습니다.

비표준 AWS 지역

AWS GovCloud(US) 지역 및 AWS 중국 지역과 같은 비표준 AWS 지역의 경우, 애플리케이션 서비스가 올바른 STS 엔드포인트를 사용할 수 있도록 AWS_REGION 환경 변수나 AWS 자격 증명 파일에 해당 지역을 설정하세요.

4단계/5단계. 역할을 가정할 수 있는 Teleport 권한 부여

다음으로, Teleport 애플리케이션 서비스 인스턴스가 사용하는 IAM 역할이나 IAM 사용자에게 다음 정책을 첨부하여 애플리케이션 서비스가 IAM 역할을 가정할 수 있도록 허용하십시오:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*"
    }
  ]
}
Tip

와일드카드를 사용하는 대신 "Resource" 필드에 특정 IAM 역할 리소스 ARN을 제공하여 정책을 더 엄격하게 만들 수 있습니다.

5단계/5단계. 연결

애플리케이션 서비스가 시작되어 클러스터에 참여하면 Athena 데이터베이스에 연결할 수 있습니다.

AWS 관리 콘솔 사용

로그인하십시오. Teleport Web UI에 https://teleport.example.com에서 (귀하의 프록시 서비스의 공개 주소로 교체하십시오).

Teleport 클러스터의 제어판에서 Applications 탭으로 이동한 다음 AWS 애플리케이션의 Launch 버튼을 클릭하십시오. 그러면 IAM 역할 선택기가 나타납니다:

ExampleTeleportAthenaRole 역할을 클릭하면 선택한 역할로 로그인된 상태로 AWS Management Console로 리디렉션됩니다.

콘솔의 오른쪽 상단 모서리에서 연합 로그인으로 로그인 되어 있으며 귀하가 가정한 IAM 역할의 이름은 ExampleTeleportAthenaRole/<teleport-username>이며 세션 이름은 귀하의 Teleport 사용자 이름입니다.

AWS CLI 사용

데스크탑에서 이전에 구성된 AWS 앱에 로그인하세요:

tsh apps login --aws-role ExampleTeleportAthenaRole aws
AWS 앱 aws에 로그인했습니다. 예제 AWS CLI 명령:
tsh aws s3 ls

--aws-role 플래그를 사용하면 AWS API에 접근할 때 사용할 AWS IAM 역할을 지정할 수 있습니다. 역할 이름을 --aws-role ExampleTeleportDynamoDBRole처럼 제공하거나, 다음과 같은 전체 역할 ARN을 제공할 수 있습니다: arn:aws:iam::123456789000:role/ExampleTeleportAthenaRole.

이제 tsh aws 명령을 기본 aws 명령줄 도구처럼 사용할 수 있습니다:

tsh aws athena list-work-groups

aws 애플리케이션에서 로그아웃하고 자격 증명을 제거하려면:

tsh apps logout aws

다른 Athena 애플리케이션 사용

아직 구성된 AWS 앱에 로그인하지 않았다면 먼저 로그인하세요:

tsh apps login --aws-role ExampleTeleportAthenaRole aws

ODBC 또는 JDBC 드라이버로 Athena에 연결합니다:

로컬 HTTPS 프록시 시작:

tsh proxy aws --port 8443 --format athena-odbc
AWS 프록시가 http://127.0.0.1:8443에서 시작되었습니다.
Athena ODBC 데이터 소스를 위한 다음 속성을 설정하세요:[Teleport AWS Athena 액세스]AuthenticationType = IAM CredentialsUID = abcd1234-this-is-an-examplePWD = zyxw9876-this-is-an-exampleUseProxy = 1;ProxyScheme = http;ProxyHost = 127.0.0.1;ProxyPort = 8443;TrustedCerts = <local-ca-bundle-path>
위의 자격 증명과 프록시 설정을 사용한 샘플 연결 문자열은 다음과 같습니다:DRIVER=Simba Amazon Athena ODBC Connector;AuthenticationType=IAM Credentials;UID=abcd1234-this-is-an-example;PWD=zyxw9876-this-is-an-example;UseProxy=1;ProxyScheme=http;ProxyHost=127.0.0.1;ProxyPort=8443;TrustedCerts=<local-ca-bundle-path>;AWSRegion=<region>;Workgroup=<workgroup>

제공된 연결 문자열을 ODBC 드라이버와 함께 Athena 애플리케이션에 사용합니다.

로컬 HTTPS 프록시 시작:

tsh proxy aws --port 8443 --format athena-jdbc
AWS 프록시가 http://127.0.0.1:8443에서 시작되었습니다.
먼저, 다음 인증서를 키 저장소에 추가하세요:<local-ca-bundle-path>
예를 들어, "keytool"을 사용하여 인증서를 가져오려면:keytool -noprompt -importcert -alias teleport-aws -file <local-ca-bundle-path> -keystore <keystore>
그런 다음 JDBC 연결 URL에 다음 속성을 설정하세요:User = abcd1234-this-is-an-examplePassword = zyxw9876-this-is-an-exampleProxyHost = 127.0.0.1;ProxyPort = 8443;
위의 자격 증명과 프록시 설정을 사용한 샘플 JDBC 연결 URL은 다음과 같습니다:jdbc:awsathena://User=abcd1234-this-is-an-example;Password=zyxw9876-this-is-an-example;ProxyHost=127.0.0.1;ProxyPort=8443;AwsRegion=<region>;Workgroup=<workgroup>

인쇄된 지침에 따라 로컬 인증서를 Java 키 저장소에 추가하세요. 기본 Java 키 저장소는 보통 다음 위치에 있습니다:

$ ls $(java -XshowSettings:properties -version 2>&1 | grep 'java.home' | awk '{print $3}')/lib/security/cacerts

그런 다음 제공된 JDBC 연결 URL을 JDBC 드라이버와 함께 Athena 애플리케이션에 사용하세요.

로컬 HTTPS 프록시 시작:

tsh proxy aws --port 8443 --format athena-jdbc
AWS 프록시가 http://127.0.0.1:8443에서 시작되었습니다.
먼저, 다음 인증서를 키 저장소에 추가하세요:<local-ca-bundle-path>
예를 들어, "keytool"을 사용하여 인증서를 가져오려면:keytool -noprompt -importcert -alias teleport-aws -file <local-ca-bundle-path> -keystore <keystore>
그런 다음 JDBC 연결 URL에 다음 속성을 설정하세요:User = abcd1234-this-is-an-examplePassword = zyxw9876-this-is-an-exampleProxyHost = 127.0.0.1;ProxyPort = 8443;
위의 자격 증명과 프록시 설정을 사용한 샘플 JDBC 연결 URL은 다음과 같습니다:jdbc:awsathena://User=abcd1234-this-is-an-example;Password=zyxw9876-this-is-an-example;ProxyHost=127.0.0.1;ProxyPort=8443;AwsRegion=<region>;Workgroup=<workgroup>

DBeaver는 기본 Java 키 저장소 대신 자체 Java 키 저장소를 사용합니다. 예를 들어, macOS에서는 키 저장소 위치가 /Applications/DBeaver.app/Contents/Eclipse/jre/Contents/Home/lib/security/cacerts입니다.

DBeaver의 CA 인증서 가져오기를 참조하여 DBeaver의 키 저장소를 설정하세요. 그런 다음 이전 tsh proxy aws 명령에서 인쇄된 지침에 따라 로컬 인증서를 키 저장소에 추가하세요.

DBeaver를 시작하고 "Athena" 연결을 추가하세요. tsh proxy aws 출력에서 사용자 이름(AWS 액세스 키)과 비밀번호(AWS 비밀 키)를 입력하세요:

DBeaver main

그런 다음 "드라이버 속성"에 ProxyHostProxyPort 설정을 입력하세요:

DBeaver main

"마침"을 클릭하세요. 이제 Athena 데이터베이스에 연결할 수 있습니다.

유용한 환경 변수

기본적으로 tsh proxy aws는 최고의 보안을 위해 로컬 통신을 위한 무작위 AWS 자격 증명을 생성하고 생성된 지침에 여러 자리 표시자를 사용합니다. 다음 환경 변수를 설정하여 이러한 값을 덮어쓸 수 있습니다:

  • TELEPORT_AWS_ACCESS_KEY_ID: 로컬 AWS 액세스 키를 설정합니다.
  • TELEPORT_AWS_SECRET_ACCESS_KEY: 로컬 AWS 비밀 키를 설정합니다.
  • TELEPORT_AWS_REGION: AWS 지역을 설정합니다.
  • TELEPORT_AWS_KEYSTORE: Java 키 저장소 경로를 설정합니다.
  • TELEPORT_AWS_WORKGROUP: Athena 워크그룹 이름을 설정합니다.
만료된 로컬 인증서

tsh proxy aws는 로컬 통신을 위한 로컬 인증 기관(CA)을 생성합니다. 로컬 CA는 새 tsh login 세션 후 만료될 수 있으며 새로운 CA가 생성됩니다. Java 키 저장소가 최신 상태인지 확인하려면 키 저장소에서 별칭을 삭제한 후 다시 추가하세요.

aws 애플리케이션에서 로그아웃하고 자격 증명을 제거하려면:

tsh apps logout aws

다음 단계

Teleport 원문 보기