인포레터에서 최신 DevOps 트렌드를 격주로 만나보세요!
Amazon Athena 접근
Teleport의 AWS CLI 및 콘솔 지원을 통해 Amazon Athena에 대한 안전한 접근을 설정할 수 있습니다.
이 가이드는 다음을 도와줍니다:
- Teleport 애플리케이션 서비스 설치.
- AWS CLI 및 콘솔 접근 설정.
- Athena 데이터베이스에 연결.
전제 조건
- Athena 데이터베이스가 있는 AWS 계정.
- IAM 역할을 생성할 수 있는 IAM 권한.
- PATH에 설치된
aws
명령줄 인터페이스 (CLI) 도구. - Teleport 응용 프로그램 서비스를 실행할 호스트, 예를 들어 EC2 인스턴스.
-
실행 중인 Teleport 클러스터 버전 17.0.0-dev 이상. Teleport를 시작하려면 가입하여 무료 평가판을 이용하거나 데모 환경 설정 방법을 확인하십시오.
-
tctl
관리자 도구와tsh
클라이언트 도구.tctl
및tsh
다운로드 방법에 대한 지침은 설치를 방문하십시오.
- 연결이 가능한지 확인하기 위해
tsh login
으로 로그인한 다음, 현재 자격 증명을 사용하여tctl
명령어를 실행할 수 있는지 확인하십시오. 예를 들어:클러스터에 연결할 수 있고tsh login --proxy=teleport.example.com --user=email@example.comtctl status클러스터 teleport.example.com
버전 17.0.0-dev
CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678
tctl status
명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속tctl
명령어를 실행할 수 있습니다.
자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로tctl
명령어를 실행할 수도 있습니다.
아직 Teleport 사용자가 아니신가요?
Auth 서비스와 프록시 서비스를 아직 배포하지 않았다면, 시작하기 가이드 중 하나를 따르거나 우리의 Teleport 응용 프로그램 접근 인터랙티브 학습 트랙을 시도해 보십시오.
당신의 Teleport 클러스터가 teleport.example.com
및 *.teleport.example.com
에서 접근 가능하다고 가정합니다. Teleport 프록시 서비스의 주소로 대체할 수 있습니다. (Teleport Cloud 고객의 경우, 이는 mytenant.teleport.sh
와 유사할 것입니다.)
응용 프로그램 접근 및 DNS
Teleport는 Application Access에 대해 구성하는 각 애플리케이션에 서브도메인을 할당합니다. 예를 들어, 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 클라우드 플랫폼을 사용하는 경우, 서브도메인과 애플리케이션에 대한 서명된 TLS 인증서를 자동으로 제공하므로 DNS 업데이트가 필요하지 않습니다.
1/5단계. Athena 접근을 위한 IAM 역할 생성
IAM 역할을 생성하여 Athena 리소스에 대한 액세스를 제공합니다.
Teleport 애플리케이션 서비스는 이러한 Athena 리소스에 접근하는 Teleport 사용자를 대신하여 이 IAM 역할을 가정합니다.
IAM 역할을 생성하는 방법은 여러 가지가 있습니다:
AWS 콘솔의 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
이름이 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
그런 다음 terraform apply
를 실행합니다.
최소 권한 허용 적용
AmazonAthenaFullAccess
는 의도한 것보다 너무 많은 접근을 제공할 수 있습니다.
권한을 줄이기 위해 다른 IAM 정책을 사용하려면 Athena의 신원 및 접근
관리를
참조하여 자세한 내용을 확인하세요.
2/5단계. Teleport IAM 역할 매핑 구성
Give your Teleport users permissions to assume IAM roles in your Teleport
클러스터.
You can do this by creating a Teleport role with the aws_role_arns
field
이전 단계에서 생성된 IAM 역할 ARN을 나열하는 역할을 생성합니다. 파일을 생성하세요
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
필드는 템플릿 변수를 지원하므로 사용자 ID 제공자 속성에 따라
동적으로 채워질 수 있습니다. 다음은 몇 가지 예입니다:
역할 정의에서 {{internal.aws_role_arns}}
를 사용하십시오:
kind: role
version: v5
metadata:
name: { { role } }
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_arns
를 external.email
로 템플릿화할 수 있습니다:
kind: role
version: v5
metadata:
name: { { role } }
spec:
allow:
app_labels:
"*": "*"
aws_role_arns:
["arn:aws:iam:123456789000:role/{{email.local(external.email)}}"]
See Role Templates for
자세한 내용.
Create the new role:
tctl create -f aws-athena-access.yaml
aws-athena-access
역할을 Teleport 사용자에게 할당하려면, 인증 제공자에 맞는 적절한 명령어를 실행하십시오:
-
로컬 사용자의 역할을 쉼표로 구분된 목록으로 가져옵니다:
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")') -
새로운 역할을 추가하기 위해 로컬 사용자를 수정합니다:
tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},aws-athena-access" -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
텍스트 편집기에서
github
인증 커넥터를 엽니다:tctl edit github/github -
github
커넥터를 수정하여teams_to_roles
섹션에aws-athena-access
을 추가합니다.이 역할에 매핑해야 하는 팀은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 팀은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 팀이어야 합니다.
예시는 다음과 같습니다:
teams_to_roles: - organization: octocats team: admins roles: - access + - aws-athena-access
-
파일을 편집하고 저장하여 변경 사항을 적용합니다.
-
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
saml
구성 리소스를 가져옵니다:tctl get --with-secrets saml/mysaml > saml.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을saml.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시saml.yaml
파일을 삭제해야 합니다. -
saml.yaml
을 수정하여attributes_to_roles
섹션에aws-athena-access
을 추가합니다.이 역할에 매핑해야 하는 속성은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.
예시는 다음과 같습니다:
attributes_to_roles: - name: "groups" value: "my-group" roles: - access + - aws-athena-access
-
변경 사항을 적용합니다:
tctl create -f saml.yaml -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
-
oidc
구성 리소스를 가져옵니다:tctl get oidc/myoidc --with-secrets > oidc.yaml--with-secrets
플래그는spec.signing_key_pair.private_key
의 값을oidc.yaml
파일에 추가합니다. 이 키는 민감한 값을 포함하므로, 리소스를 업데이트한 후 즉시oidc.yaml
파일을 삭제해야 합니다. -
oidc.yaml
을 수정하여claims_to_roles
섹션에aws-athena-access
을 추가합니다.이 역할에 매핑해야 하는 클레임은 조직의 역할 기반 액세스 제어(RBAC) 설계에 따라 다릅니다. 그러나 그룹은 귀하의 사용자 계정을 포함해야 하며, 조직 내에서 가장 작은 그룹이어야 합니다.
예시는 다음과 같습니다:
claims_to_roles: - name: "groups" value: "my-group" roles: - access + - aws-athena-access
-
변경 사항을 적용합니다:
tctl create -f oidc.yaml -
Teleport 클러스터에서 로그아웃한 후 다시 로그인하여 새로운 역할을 가집니다.
3/5단계. Teleport 애플리케이션 서비스 설치
토큰 생성
클러스터에 조인하기 위해 Teleport Application Service 인스턴스를 권한 부여하는 데 필요한 조인 토큰입니다. 단기 조인 토큰을 생성하고 명령의 출력을 저장하십시오:
tctl tokens add \ --type=app \ --app-name=aws \ --app-uri=https://console.aws.amazon.com/console/home
Teleport Application Service를 실행할 호스트에서 /tmp/token
이라는 파일에 토큰을 복사합니다.
비표준 AWS 지역
AWS GovCloud (US) 지역의 경우 https://console.aws.amazon.com
을
https://console.amazonaws-us-gov.com
으로, AWS China 지역의 경우
https://console.amazonaws.cn
으로 대체하십시오.
Teleport 설치 및 시작
Teleport Application Service를 실행할 호스트에 Teleport를 설치합니다. Linux 서버 외의 옵션은 설치 페이지를 참조하세요.
Linux 서버에 Teleport 설치하기:
-
Teleport 에디션에 따라 edition를 다음 중 하나로 할당합니다:
에디션 값 Teleport Enterprise Cloud cloud
Teleport Enterprise (자가 호스팅) enterprise
Teleport Community Edition oss
-
설치할 Teleport 버전을 가져옵니다. 클러스터에서 자동 에이전트 업데이트가 활성화된 경우, 최신 Teleport 버전을 쿼리하여 업데이트된 내용과의 호환성을 확인합니다:
TELEPORT_DOMAIN=example.teleport.comTELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/automaticupgrades/channel/default/version | sed 's/v//')"그렇지 않으면, Teleport 클러스터의 버전을 가져옵니다:
TELEPORT_DOMAIN=example.teleport.comTELEPORT_VERSION="$(curl https://$TELEPORT_DOMAIN/v1/webapi/ping | jq -r '.server_version')" -
Linux 서버에 Teleport를 설치합니다:
curl https://cdn.teleport.dev/install-v15.4.11.sh | bash -s ${TELEPORT_VERSION} edition설치 스크립트는 Linux 서버에서 패키지 관리자를 감지하고 이를 사용하여 Teleport 바이너리를 설치합니다. 설치를 사용자 정의하려면 설치 가이드에서 Teleport 패키지 리포지토리에 대해 알아보세요.
Teleport 구성 파일(/etc/teleport.yaml
)을 편집하여 다음 정보를 포함하고, proxy_server
의 값을 조정하여 Teleport Proxy Service의 호스트와 포트를 지정하십시오:
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 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다.
- the Teleport Application Service 를 Kubernetes에서 실행 중인 경우, IAM Roles for Service Accounts (IRSA)를 사용할 수 있습니다.
- 그렇지 않은 경우, 환경 변수를 사용해야 합니다.
Teleport는 EC2 인스턴스에서 실행 중일 때 이를 감지하고 인스턴스 메타데이터 서비스를 사용하여 자격 증명을 가져옵니다.
EC2 인스턴스는 EC2 인스턴스 프로필을 사용하도록 구성되어야 합니다. 자세한 내용은 인스턴스 프로필 사용을 참조하십시오.
AWS의 IAM Roles for Service Accounts (IRSA)를 참조하여 AWS에서 OIDC 공급자를 설정하고 포드의 서비스 계정이 해당 역할을 맡을 수 있도록 하는 AWS IAM 역할을 구성하십시오.
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가 자동으로 시작되도록 systemd 서비스를 생성하여 구성합니다. 지침은 the Teleport Application Service를 설치한 방법에 따라 다릅니다.
the Teleport Application Service를 실행할 호스트에서 Teleport를 활성화하고 시작합니다:
sudo systemctl enable teleportsudo systemctl start teleport
the Teleport Application Service를 실행할 호스트에서 Teleport의 systemd 서비스 구성을 만들고, Teleport 서비스를 활성화한 후 Teleport를 시작합니다:
sudo teleport install systemd -o /etc/systemd/system/teleport.servicesudo systemctl enable teleportsudo systemctl start teleport
systemctl status teleport
로 the Teleport Application Service의 상태를 확인하고, journalctl -fu teleport
로 로그를 볼 수 있습니다.
비표준 AWS 지역
비표준 AWS 지역(예: AWS GovCloud (US) 지역 및 AWS China 지역)의 경우,
Application Service가 올바른 STS 엔드포인트를 사용할 수 있도록 AWS_REGION
환경 변수 또는 AWS 자격 증명 파일에 해당 지역을 설정하십시오.
4/5단계. Teleport에 역할 수임 권한 부여
다음으로, Teleport Application Service 인스턴스가 사용하는 IAM 역할 또는 IAM 사용자에 다음 정책을 첨부하십시오. 이 정책은 Application Service가 IAM 역할을 가정할 수 있도록 허용합니다:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*"
}
]
}
Tip
"Resource" 필드에 와일드카드를 사용하는 대신 특정 IAM 역할 리소스 ARN을 제공하여 정책을 더 엄격하게 만들 수 있습니다.
5/5단계. 연결하기
애플리케이션 서비스가 시작되고 클러스터에 조인하면 Athena 데이터베이스에 연결할 수 있습니다.
AWS 관리 콘솔 사용
Teleport 웹 UI에 https://teleport.example.com
(프록시 서비스의 공개 주소로 교체)에서 로그인합니다.
Teleport 클러스터의 제어판에서 Applications 탭으로 이동하고 AWS 애플리케이션의 Launch 버튼을 클릭합니다. 그러면 IAM 역할 선택기가 나타납니다:
역할 ExampleTeleportAthenaRole
을 클릭하면 선택된 역할로 로그인된 상태로 AWS 관리 콘솔로 리디렉션됩니다.
콘솔의 오른쪽 상단에 보면 연합 로그인으로 로그인했으며 자신의 가정된 IAM 역할 이름이 ExampleTeleportAthenaRole/<teleport-username>
으로, 세션 이름은 자신의 Teleport 사용자 이름임을 알 수 있습니다.
AWS CLI 사용
AWS 앱에 로그인하세요:
tsh apps login --aws-role ExampleTeleportAthenaRole awsAWS 앱 aws에 로그인했습니다. 예시 AWS CLI 명령어:tsh aws s3 ls
--aws-role
플래그를 사용하면 AWS API에 접근할 때 가정할 AWS IAM 역할을 지정할 수 있습니다. --aws-role ExampleTeleportDynamoDBRole
과 같은 역할 이름이나 arn:aws:iam::123456789000:role/ExampleTeleportAthenaRole
와 같은 전체 역할 ARN을 제공할 수 있습니다.
이제 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-odbcAWS 프록시가 http://127.0.0.1:8443 에서 시작되었습니다.
Athena ODBC 데이터 소스를 위해 다음 속성을 설정하세요:[Teleport AWS Athena Access]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>
제공된 연결 문자열을 Athena 애플리케이션의 ODBC 드라이버에 사용하세요.
로컬 HTTPS 프록시 시작:
tsh proxy aws --port 8443 --format athena-jdbcAWS 프록시가 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을 Athena 애플리케이션의 JDBC 드라이버에 사용하세요.
로컬 HTTPS 프록시 시작:
tsh proxy aws --port 8443 --format athena-jdbcAWS 프록시가 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 비밀 키)를 입력하세요:

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

"완료"를 클릭하세요. 이제 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
다음 단계
- AWS Management and API with Teleport Application Access에 대한 자세한 정보.
- AWS 서비스 엔드포인트에 대해 더 알아보기.