Amazon Redshift를 이용한 데이터베이스 접근
Teleport can provide secure access to Amazon Redshift via the Teleport Database Service. In this guide, you will: The Teleport Database Service uses IAM authentication to communicate with Amazon Redshift.
Teleport can provide secure access to Amazon Redshift via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.
In this guide, you will:
- Configure your Amazon Redshift database with IAM authentication.
- Add the database to your Teleport cluster.
- Connect to the database via Teleport.
작동 방식#
The Teleport Database Service uses IAM authentication to communicate with Amazon Redshift. When a user connects to the database via Teleport, the Teleport Database Service obtains AWS credentials and authenticates to AWS as an IAM principal with permissions to access the database.


This guide shows how to register a single Amazon Redshift cluster with your Teleport cluster. For a more scalable approach, learn how to set up Database Auto-Discovery to automatically enroll all AWS databases in your infrastructure.
전제 조건#
-
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
tctlandtshclients.Installing `tctl` and `tsh` clients
-
Determine the version of your Teleport cluster. The
tctlandtshclients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at/v1/webapi/findand 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')" -
Follow the instructions for your platform to install
tctlandtshclients:
-
- IAM 정책을 생성하고 연결할 권한이 있는 Redshift 클러스터가 있는 AWS 계정.
- 명령줄 클라이언트
psql이 설치되어 있고 시스템의PATH환경 변수에 추가되어 있어야 합니다. - Teleport 데이터베이스 서비스를 실행할 호스트(예: EC2 인스턴스).
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.
1/5단계. Teleport 사용자 생성#
| Flag | Description |
|---|---|
--roles |
List of roles to assign to the user. The builtin access role allows them to connect to any database server registered with Teleport. |
--db-users |
List of database usernames the user will be allowed to use when connecting to the databases. A wildcard allows any user. |
--db-names |
List of logical databases (aka schemas) the user will be allowed to connect to within a database server. A wildcard allows any database. |
For more detailed information about database access controls and how to restrict access see RBAC documentation.
2/5단계. 데이터베이스 서비스 구성 생성#
The Database Service requires a valid join token to join your Teleport cluster.
Run the following tctl command and save the token output in /tmp/token
on the server that will run the Database Service:
$ tctl tokens add --type=db --format=text
(=presets.tokens.first=)
Alternative methods
For users with a lot of infrastructure in AWS, or who might create or recreate many instances, consider alternative methods for joining new EC2 instances running Teleport:
To install a Teleport Agent on your Linux server:
The recommended installation method is the cluster install script. It will select the correct version, edition, and installation mode for your cluster.
-
Assign to your Teleport cluster hostname and port, but not the scheme (https://).
-
Run your cluster's install script:
$ curl "https:///scripts/install.sh" | sudo bash
데이터베이스 서비스를 실행하는 노드에서 구성 파일을 생성합니다.
CLUSTER_URI를 클러스터의 도메인 이름과 포트로 할당합니다:
$ sudo teleport db configure create \
-o file \
--name="redshift-postgres" \
--proxy=teleport.example.com:443 \
--protocol=postgres \
--token=/tmp/token \
--uri=${CLUSTER_URI?}
$ sudo teleport db configure create \
-o file \
--name="redshift-postgres" \
--proxy=mytenant.teleport.sh:443 \
--protocol=postgres \
--token=/tmp/token \
--uri=${CLUSTER_URI?}
명령은 AWS Redshift 클러스터를 프록시하는 데이터베이스 서비스 구성을 생성하고 /etc/teleport.yaml 위치에 저장합니다.
3/5단계. 데이터베이스 서비스를 위한 IAM 권한 구성#
The Teleport Database Service needs AWS IAM permissions to provide access to Redshift databases.
Teleport를 위한 IAM 역할 생성#
Grant the Database Service access to credentials that it can use to authenticate to AWS.
- If you are running the Database Service on an EC2 instance, you may use the EC2 Instance Metadata Service method
- If you are running the Database Service in Kubernetes, you can use IAM Roles for Service Accounts (IRSA)
- Otherwise, you must use environment variables
Have multiple sources of AWS credentials?
Teleport's AWS client loads credentials from different sources in the following order:
- Environment Variables
- Shared credentials file
- Shared configuration file (Teleport always enables shared configuration)
- EC2 Instance Metadata (credentials only)
While you can provide AWS credentials via a shared credentials file or shared
configuration file, you will need to run the Database Service with the AWS_PROFILE
environment variable assigned to the name of your profile of choice.
If you have a specific use case that the instructions above do not account for, consult the documentation for the AWS SDK for Go for a detailed description of credential loading behavior.
권한 부여#
데이터베이스 서비스 IAM 역할에 다음 AWS IAM 권한을 연결합니다:
Assign to your AWS account ID:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RedshiftConnectAsDBUser",
"Effect": "Allow",
"Action": "redshift:GetClusterCredentials",
"Resource": "*"
},
{
"Sid": "RedshiftConnectAsIAMRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": [
"arn:aws:iam::
You can check the status of the Database Service with systemctl status teleport
and view its logs with journalctl -fu teleport.
데이터베이스 서비스는 이전에 지정한 ID로 Amazon Redshift 클러스터를 프록시합니다. AWS IAM 변경 사항은 즉시 적용되지 않을 수 있으며 적용되는 데 몇 분이 걸릴 수 있습니다.
5/5단계. 연결#
데이터베이스 서비스가 시작되고 클러스터에 참가하면, 등록된 데이터베이스를 확인하기 위해 로그인합니다. --proxy를 Teleport 프록시 서비스의 주소로 교체합니다.
$ tsh login --proxy=teleport.example.com --user=alice
$ tsh db ls
# Name Description Labels
# ----------- ------------------------------ --------
# my-redshift ...
데이터베이스 서비스가 시작되고 클러스터에 참가하면, 등록된 데이터베이스를 확인하기 위해 로그인합니다. --proxy를 Teleport Cloud 테넌트의 주소로 교체합니다.
$ tsh login --proxy=mytenant.teleport.sh --user=alice
$ tsh db ls
# Name Description Labels
# ----------- ------------------------------ --------
# my-redshift ...
데이터베이스의 자격 증명을 검색하고 연결하려면:
$ tsh db connect --db-user=alice --db-name=dev my-redshift
데이터베이스 사용자가 존재해야 함
Teleport는 현재 Redshift 데이터베이스의 토큰을 생성할 때 자동 생성 옵션을 사용하지 않습니다. 사용자는 데이터베이스에 존재해야 합니다.
데이터베이스에서 로그아웃하고 자격 증명을 제거하려면:
$ tsh db logout my-redshift
Note이 섹션의 내용은 원문 문서를 참조하세요. (proxy-db-tunnel.mdx)
IAM 역할로 Redshift 인증#
Amazon Redshift는 두 가지 IAM 기반 인증 방법을 지원하며 Teleport는 둘 다와 호환됩니다.
첫 번째 방법: 데이터베이스 사용자로 인증(기본값)
이 방법에서 Teleport 데이터베이스 서비스는 Redshift의 기존 데이터베이스 사용자를 위한 임시 IAM 인증 토큰을 생성합니다. 이 사용자는 Redshift 데이터베이스에 이미 존재해야 합니다. Teleport는 기본적으로 이 방법을 사용합니다.
두 번째 방법: IAM 역할로 인증
이 대안적인 방법에서 Teleport 데이터베이스 서비스는 Redshift에 인증하기 위해 AWS IAM 역할을 가정합니다. Redshift는 IAM 역할을 데이터베이스 사용자에 매핑하고 해당 사용자가 존재하지 않으면 자동으로 생성합니다. 이 방법을 사용하는 경우 먼저 Redshift 데이터베이스에 대한 접근을 부여하는 AWS IAM 역할을 생성해야 합니다.
The following permissions policy should be attached to an IAM role that Teleport
users can specify as a database user.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RedshiftConnectWithIAM",
"Effect": "Allow",
"Action": "redshift:GetClusterCredentialsWithIAM",
"Resource": "*"
}
]
}
Statement
Purpose
RedshiftConnectWithIAM
Connect to a Redshift database as a database user mapped 1:1 from this IAM identity.
An IAM role can connect as an automatically created database user with
permissions mapped 1:1 from the identity's IAM permissions.
Permissions in the database are granted with redshift-data:* statements
attached to the IAM identity, for example redshift-data:GetStatementResult.
Teleport users can connect as that role by specifying "role/{RoleName}" as a
database user, e.g.
$ tsh db connect my-redshift --db-user=role/redshift-user-role
See
Using identity-based policies for Amazon Redshift
for more information about available Redshift IAM permissions that are mapped
to the database user.
문제 해결#
Certificate error#
If your tsh db connect error includes the following text, you likely have an RDS or DocumentDB database created before July 28, 2020, which presents an X.509 certificate that is incompatible with Teleport:
x509: certificate relies on legacy Common Name field, use SANs instead
AWS provides instructions to rotate your SSL/TLS certificate.
(!docs/pages/includes/aws-no-credential-provider.mdx service="Database"!)
Timeout errors#
(!docs/pages/includes/database-access/connection-timeout-troubleshooting.mdx!)
Not authorized to perform sts:AssumeRole#
The Database Service assumes an IAM role in one of following situations:
- A Teleport user specifies an IAM role as the database user they wish to use
when accessing AWS services that require IAM roles as database users.
Databases that support using an IAM role as a database user include: DynamoDB,
Keyspaces, Opensearch, Redshift, and Redshift Serverless.
- The
assume_role_arn field is specified for the database resources or
dynamic resource matchers.
What if both situations apply? (role chaining)
When both of the above conditions are true for a database connection, the
Database Service performs a role chaining by assuming the IAM role specified
in `assume_role_arn` first, then using that IAM role to assume the IAM role for
the database user.
You may encounter the following error if the trust relationship is not
configured properly between the IAM roles:
AccessDenied: User: arn:aws:sts::111111111111:assumed-role/teleport-db-service-role/i-* is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::111111111111:role/db-user-role
how to properly configure the trust relationship?
(!docs/pages/includes/database-access/iam_role_trust_relationship.mdx role1="teleport-db-service-role" role2="db-user-role" !)
You can test the trust relationship by running this AWS CLI command as teleport-db-service-role:
$ aws sts assume-role --role-arn arn:aws:iam::111111111111:role/db-user-role --role-session-name test-trust-relationship
Learn more on how to use trust policies with IAM
roles.
Maximum policy size exceeded errors#
Due to IAM and STS character
limits,
you may encounter one of the following errors in the Database Service logs when
large numbers of databases are registered:
LimitExceeded: Maximum policy size of 2048 bytes exceeded for user <iam-user>
LimitExceeded: Maximum policy size of 10240 bytes exceeded for role <iam-role>
For reference, a user policy can maintain permissions for approximately 6
Redshift databases, or 20 RDS databases due to the IAM policy character limits.
A role policy can maintain permissions for approximately 30 Redshift databases,
or 100 RDS databases.
To get around this limit, try using one or a combination of the following
methods:
Method 1: Organize IAM roles with "assume_role_arn"
You can reduce the policy size by separating them into multiple IAM roles. Use
`assume_role_arn` to specify different IAM roles for accessing the databases:
Create or print the required IAM policies with the following commands and
attach them to the respective IAM roles:
$ teleport db configure aws create-iam --types redshift,redshift-serverless --name teleport-redshift-access
$ teleport db configure aws print-iam --types redshift,redshift-serverless
Refer to the command usage for a complete list of database types supported by
the --types option.
The IAM roles specified in assume_role_arn must
trust
the IAM identity of the host running the Database Service.
The assume_role_arn is not limited to the same AWS account so you can also
use this feature for AWS Cross-Account
Access.
Method 2: Manually manage your IAM policies
You can manually manage IAM policies for database connections instead of
relying on the Database Service to update them.
For example, you can limit the character size by attaching a policy with a
wildcard "*" for "Resource":
You can safely remove the inline policy created by the Database Service and the
IAM permissions for the Database Service to Get/Put/Delete the user or role
policy.
Method 3: Separate Database Services
You can deploy the Database Service in a highly available (HA)
configuration where
databases can be sharded to separate Database Services with different IAM roles.
Method 4: Use IAM roles instead of IAM users
IAM users have a lower character limit compared to IAM roles. If the limit is
exceeded for a user policy, it is recommended to use IAM roles for the Database
Service instead.
Unable to cancel a query#
If you use a PostgreSQL cli client like psql, and you try to cancel a query
with Ctrl+C, but it doesn't cancel the query, then you need to connect using a
tsh local proxy instead.
When psql cancels a query, it establishes a new connection without TLS
certificates, however Teleport requires TLS certificates not only for
authentication, but also to route database connections.
If you
enable TLS Routing in Teleport
then tsh db connect will automatically start a local proxy for every
connection.
Alternatively, you can connect via
Teleport Connect
which also uses a local proxy.
Otherwise, you need to start a tsh local proxy manually using tsh proxy db
and connect via the local proxy.
If you have already started a long-running query in a psql session that you
cannot cancel with Ctrl+C, you can start a new client session to cancel that
query manually:
First, find the query's process identifier (PID):
SELECT pid,starttime,duration,trim(user_name) AS user,trim(query) AS query FROM stv_recents WHERE status = 'Running';
Next, gracefully cancel the query using its PID.
This will send a SIGINT signal to the postgres backend process for that query:
SELECT pg_cancel_backend(<PID>);
You should always try to gracefully terminate a query first, but if graceful
cancellation is taking too long, then you can forcefully terminate the query
instead.
This will send a SIGTERM signal to the postgres backend process for that query:
SELECT pg_terminate_backend(<PID>);
See the PostgreSQL documentation on
admin functions
for more information about the pg_cancel_backend and pg_terminate_backend
functions.
SSL SYSCALL error#
You may encounter the following error when your local psql is not compatible
with newer versions of OpenSSL:
$ tsh db connect --db-user postgres --db-name postgres postgres
psql: error: connection to server at "localhost" (::1), port 12345 failed: Connection refused
Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (127.0.0.1), port 12345 failed: SSL SYSCALL error: Undefined error: 0
Please upgrade your local psql to the latest version.
다음 단계#
- Amazon Redshift에 대한 IAM 인증을 사용하여 데이터베이스 사용자 자격 증명 생성에 대해 자세히 알아봅니다.
- 특정 사용자 및 데이터베이스에 대한 접근 제한 방법을 알아봅니다.
- 고가용성(HA) 가이드를 확인합니다.
- YAML 구성 참조를 살펴봅니다.
