Redis 및 Valkey용 Amazon ElastiCache 서버리스를 이용한 데이터베이스 접근
Teleport can provide secure access to Amazon ElastiCache Serverless via the Teleport Database Service. In this guide, you will:
Teleport can provide secure access to Amazon ElastiCache Serverless via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.
In this guide, you will:
- Configure your Amazon ElastiCache Serverless database with IAM authentication.
- Add the database to your Teleport cluster.
- Connect to the database via Teleport.
작동 방식#
Teleport 데이터베이스 서비스는 IAM 인증을 사용하여 사용자를 대신하여 연결하고 사용자에서 Amazon ElastiCache 서버리스로의 트래픽을 프록시합니다.


This guide shows how to register a single Amazon Elasticache Serverless cache 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:
-
- Redis 또는 Valkey 캐시용 ElastiCache 서버리스가 있는 AWS 계정.
- IAM 정책을 생성하고 연결할 권한.
redis-cli버전6.2이상이 설치되어 있고 시스템의PATH환경 변수에 추가되어 있어야 합니다.- Teleport 데이터베이스 서비스를 실행할 호스트(예: EC2 인스턴스).
A running Teleport Discovery Service if you plan to use Database Auto-Discovery.
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/6단계. 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/6단계. 데이터베이스 서비스 구성 생성#
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
데이터베이스 서비스 구성을 생성합니다:
$ ELASTICACHE_SERVERLESS_URI=""
$ sudo teleport db configure create \
-o file \
--name="elasticache-serverless" \
--proxy=example.teleport.sh:443 \
--protocol="redis" \
--uri=${ELASTICACHE_SERVERLESS_URI?} \
--token=/tmp/token
example.teleport.sh:443을 Teleport 프록시 서비스의 호스트와 포트로 교체합니다. ELASTICACHE_SERVERLESS_URI를 ElastiCache 데이터베이스의 도메인 이름과 포트로 설정합니다.
명령은 데이터베이스 서비스 구성을 생성하고 /etc/teleport.yaml 위치에 저장합니다.
3/6단계. Teleport를 위한 IAM 역할 생성#
The Teleport Database Service needs AWS IAM permissions to provide access to ElastiCache Serverless caches.
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.
권한 부여#
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ElastiCacheServerlessFetchMetadata",
"Effect": "Allow",
"Action": "elasticache:DescribeServerlessCaches",
"Resource": "*"
},
{
"Sid": "ElastiCacheServerlessDescribeUsers",
"Effect": "Allow",
"Action": "elasticache:DescribeUsers",
"Resource": "*"
},
{
"Sid": "ElastiCacheServerlessConnect",
"Effect": "Allow",
"Action": "elasticache:Connect",
"Resource": "*"
}
]
}
| Statement | Purpose |
|---|---|
ElastiCacheServerlessFetchMetadata |
Automatically import AWS metadata about the database. |
ElastiCacheServerlessDescribeUsers |
Determine whether a user is compatible with IAM authentication. |
ElastiCacheServerlessConnect |
Connect using IAM authentication. |
4/6단계. 데이터베이스 서비스 시작#
Configure the Database Service to start automatically when the host boots up by creating a systemd service for it. The instructions depend on how you installed the Database Service.
You can check the status of the Database Service with systemctl status teleport
and view its logs with journalctl -fu teleport.
5/6단계. ElastiCache 사용자 인증 구성#
ElastiCache 서버리스 데이터베이스의 인증을 구성합니다.
ACL을 활성화하려면 ElastiCache에 대한 역할 기반 접근 제어를 사용한 사용자 인증을 참조하세요.
ElastiCache 서버리스 Redis OSS는 암호 없이 기본 사용자를 자동으로 생성합니다. 기본 사용자를 비활성화하는 조치를 취하는 것을 강력히 권장합니다. 자동으로 생성된 기본 사용자는 수정하거나 삭제할 수 없으며 ElastiCache Redis OSS 사용자 그룹에서 기본 사용자 이름을 제거할 수 없습니다. 기본 사용자를 비활성화하려면:
- 사용자 이름이 "default"이고 고유한(즉, "default"가 아닌) 사용자 ID를 가진 새 사용자를 만듭니다.
- ElastiCache 사용자 그룹에서 기본 사용자를 새 기본 사용자로 교체합니다.
사용자 지정 기본 사용자에 강력한 암호를 설정하고(기본 사용자에는 IAM 인증이 불가능) 허용적이지 않은 접근 문자열을 사용하는 것을 권장합니다.
예를 들어, 접근 문자열 off -@all은 기본 사용자의 로그인을 비활성화하고 모든 Redis 권한을 거부합니다.
자세한 내용은 RBAC 적용을 참조하세요.
IAM 인증을 사용할 때는 몇 가지 추가 제한이 적용됩니다 - 자세한 내용은 ElastiCache Auth IAM 제한을 참조하세요.
ElastiCache IAM 지원 사용자를 구성하기 위한 몇 가지 요구 사항이 있습니다:
- 사용자는 동일한 사용자 이름과 사용자 ID 속성을 가져야 합니다.
- 사용자의 인증 모드가 "IAM"으로 설정되어 있어야 합니다.
- 사용자가 ElastiCache 사용자 그룹에 연결되어 있어야 합니다.
ElastiCache IAM 지원 사용자를 생성합니다.
다음 예시는 사용 가능한 모든 키와 명령에 접근할 수 있는 활성 사용자를 나타내는 접근 문자열 on ~* +@all을 사용하여 ElastiCache 사용자를 생성합니다:
$ aws elasticache create-user \
--user-name iam-user-01 \
--user-id iam-user-01 \
--authentication-mode Type=iam \
--engine redis \
--access-string "on ~* +@all"
ElastiCache 사용자에게 덜 허용적인 접근 문자열을 선호할 수 있습니다. ElastiCache 접근 문자열에 대한 자세한 내용은 ElastiCache 클러스터 RBAC 접근 문자열을 참조하세요.
ElastiCache 사용자 그룹을 생성하고 ElastiCache 서버리스 캐시에 연결합니다:
$ aws elasticache create-user-group \
--user-group-id iam-user-group-01 \
--engine redis \
--user-ids default iam-user-01
$ aws elasticache modify-serverless-cache \
--serverless-cache-name serverless-cache-1 \
--user-group-id "iam-user-group-01"
ElastiCache 사용자가 생성되면 IAM 인증 요구 사항을 충족하도록 구성되어 있는지 확인합니다:

If you choose not to use the above options, Teleport will not automatically authenticate with the database.
You can either set up a "no password" configuration for your ElastiCache Serverless user,
or manually enter an AUTH command with the password you have configured after
a successful client connection. However, it is strongly advised to use one of
the first two options or a strong password for better security.
6/6단계. 연결#
데이터베이스 서비스가 시작되고 클러스터에 참가하면, 등록된 데이터베이스를 확인하기 위해 로그인합니다:
$ tsh login --proxy=teleport.example.com --user=alice
$ tsh db ls
Name Description Allowed Users Labels
------------------- ----------- ------------- -----------------------
my-serverless-cache [*] account_id=123456789012
$ tsh login --proxy=mytenant.teleport.sh --user=alice
$ tsh db ls
Name Description Allowed Users Labels
------------------- ----------- ------------- -----------------------
my-serverless-cache [*] account_id=123456789012
데이터베이스의 자격 증명을 검색하고 연결하려면:
$ tsh db connect --db-user=my-database-user my-serverless-cache
If flag --db-user is not provided, Teleport logs in as the default user.
Now, depending on the authentication configurations, you may need to send an
AUTH command to authenticate with the Redis server:
이 섹션의 내용은 원문 문서를 참조하세요. (proxy-db-tunnel.mdx)
데이터베이스에서 로그아웃하고 자격 증명을 제거하려면:
# 특정 데이터베이스 인스턴스의 자격 증명을 제거합니다.
$ tsh db logout my-serverless-cache
# 모든 데이터베이스 인스턴스의 자격 증명을 제거합니다.
$ tsh db logout
문제 해결#
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_arnfield 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.
다음 단계#
-
Learn how to restrict access to certain users and databases.
-
View the High Availability (HA) guide.
-
Take a look at the YAML configuration reference.
-
See the full CLI reference.
