이 가이드의 후반부에서 Teleport 데이터베이스 서비스를 구성할 때 이 조인 토큰을 사용합니다.

Configure Helm to fetch Teleport charts from the Teleport Helm repository:

$ helm repo add teleport (=teleport.helm_repo_url=)

Refresh the local Helm cache by fetching the latest charts:

$ helm repo update

다음 명령을 실행하고 Db 유형의 토큰을 복사하여 이 가이드에서 이전에 생성한 조인 토큰을 검색합니다:

$ tctl tokens ls
Token                            Type Labels Expiry Time (UTC)
-------------------------------- ---- ------ ----------------------------
(=presets.tokens.first=) Db          14 Jun 23 21:21 UTC (20m15s)

Helm 값 파일 values.yaml을 만듭니다. 을 위에서 검색한 조인 토큰 값으로, 을 Teleport 프록시 서비스의 호스트 및 포트로, 을 RDS 데이터베이스의 호스트 및 포트(예: myrds.us-east-1.rds.amazonaws.com:5432)로 지정합니다. 을 AWS 계정 ID로 지정합니다. Teleport 커뮤니티 에디션을 사용하는 경우 enterprise를 false로 설정합니다:

authToken: 
(!docs/pages/includes/database-access/db-access-webui-ad.mdx dbType="MySQL or MariaDB"!)


(!docs/pages/includes/database-access/db-access-webui-ad.mdx dbType="PostgreSQL"!)



데이터베이스에서 로그아웃하고 자격 증명을 제거합니다:
$ tsh db logout rds-example

문제 해결#

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,usename,backend_start,query FROM pg_stat_activity WHERE state = 'active';

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.

다음 단계#



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.




자동 데이터베이스 사용자 프로비저닝을 설정합니다.