InfoGrab Docs

Amazon Redshift Serverless를 통한 데이터베이스 액세스

요약

Teleport can provide secure access to Amazon Redshift Serverless via the Teleport Database Service. In this guide, you will:

Teleport can provide secure access to Amazon Redshift Serverless via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.

In this guide, you will:

  1. Configure your Amazon Redshift Serverless database with IAM authentication.
  2. Add the database to your Teleport cluster.
  3. Connect to the database via Teleport.

작동 방식#

The Teleport Database Service uses IAM authentication to communicate with Redshift Serverless. 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.

자체 호스팅 Teleport 클러스터로 Redshift 등록

클라우드 호스팅 Teleport 클러스터로 Redshift 등록

This guide shows how to register a single Amazon Redshift Serverless database 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 tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and 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')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • Redshift Serverless 구성이 있는 AWS 계정과 IAM 정책을 생성하고 연결할 수 있는 권한.
  • 명령줄 클라이언트 psql이 설치되어 있고 시스템 PATH 환경 변수에 추가되어 있어야 합니다.
  • Teleport Database Service를 실행할 호스트. 이 가이드에서는 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단계. 사용자 액세스를 위한 IAM 역할 생성#

Redshift Serverless에 대한 사용자 액세스를 제공하기 위해 AWS IAM 역할을 생성합니다. 이 역할은 Teleport 역할을 통해 Teleport 사용자에게 부여됩니다. 이 가이드에서는 이 역할에 teleport-redshift-serverless-access라는 이름을 사용합니다.

AWS 계정을 신뢰하도록 역할의 신뢰 정책을 구성합니다. 이렇게 하면 다음 단계에서 설정할 Teleport Database Service가 역할을 가정할 수 있습니다. 에 AWS 계정 ID를 할당합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::



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.

권한 부여#

Database Service IAM 역할에 다음 AWS IAM 권한을 연결합니다:

Assign to your AWS account ID:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnectAsIAMRole",
            "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.

4/5단계. Teleport 역할 생성#

tsh로 Teleport 클러스터에 로그인된 워크스테이션에서 Redshift Serverless에 대한 액세스를 제공하는 새 역할을 정의합니다. 예시 파일은 redshift-role.yaml입니다:

version: v5
kind: role
metadata:
  name: redshift-serverless-access
spec:
  allow:
    db_labels:
      '*': '*'
    db_names:
    - dev
    db_users:
    - 'teleport-redshift-serverless-access'
  • db_users의 값은 이전 단계에서 생성한 IAM 역할에 해당합니다. 역할 이름 또는 IAM 역할의 전체 AWS ARN을 제공할 수 있습니다.
  • db_names의 값은 Redshift Serverless 구성에 따라 다르지만, dev는 AWS에서 적용하는 기본 이름입니다. 모든 인스턴스에 대한 액세스를 부여하려면 *을 제공할 수도 있습니다.

이 파일을 저장하고 Teleport 클러스터에 적용합니다:

$ tctl create -f redshift-role.yaml
role 'redshift-serverless-access' has been created

Assign the redshift-serverless-access role to your Teleport user by running the appropriate commands for your authentication provider:

5/5단계. 연결#

Database Service가 시작되어 클러스터에 연결된 후, 등록된 데이터베이스를 보려면 로그인합니다. --proxy를 Teleport Proxy Service 또는 클라우드 테넌트 주소로 교체하세요:

$ tsh login --proxy=mytenant.teleport.sh --user=alice
$ tsh db ls
Name        Description Labels
----------- ----------- ------
my-redshift             ...

Redshift Serverless 인스턴스에 연결하려면:

$ tsh db connect my-redshift --db-user=teleport-redshift-serverless-access --db-name=dev
psql (15.1, server 8.0.2)
WARNING: psql major version 15, server major version 8.0.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_CHACHA20_POLY1305_SHA256, compression: off)
Type "help" for help.

dev=>

데이터베이스에서 로그아웃하고 자격 증명을 제거하려면:

$ tsh db logout my-redshift
Note

이 섹션의 내용은 원문 문서를 참조하세요. (proxy-db-tunnel.mdx)

문제 해결#

사용자 권한 오류#

IAM 역할 teleport-redshift-serverless-access는 Redshift Serverless 데이터베이스 내에서 자동으로 IAMR:teleport-redshift-serverless-access로 매핑됩니다.

사용자(데이터베이스 관리자)는 이 새 IAM 역할로 로그인하기 전에 데이터베이스 사용자의 권한을 선택적으로 설정하여 사용자 권한 문제를 예방하거나 해결할 수 있습니다:

  1. Redshift Serverless 워크그룹에 관리자 사용자로 연결하고 다음을 실행합니다:

    CREATE USER "IAMR:teleport-redshift-serverless-access" WITH PASSWORD DISABLE;
    
  2. 이 사용자에게 적절한 데이터베이스 내 권한을 부여합니다. 예:

    GRANT SELECT ON TABLE users TO "IAMR:teleport-redshift-serverless-access";
    

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.

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 session_id AS pid, database_name,start_time,trim(query_text) AS query FROM SYS_QUERY_HISTORY 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.

다음 단계#

Amazon Redshift Serverless를 통한 데이터베이스 액세스

원문 보기
요약

Teleport can provide secure access to Amazon Redshift Serverless via the Teleport Database Service. In this guide, you will:

Teleport can provide secure access to Amazon Redshift Serverless via the Teleport Database Service. This allows for fine-grained access control through Teleport's RBAC.

In this guide, you will:

  1. Configure your Amazon Redshift Serverless database with IAM authentication.
  2. Add the database to your Teleport cluster.
  3. Connect to the database via Teleport.

작동 방식#

The Teleport Database Service uses IAM authentication to communicate with Redshift Serverless. 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.

자체 호스팅 Teleport 클러스터로 Redshift 등록

클라우드 호스팅 Teleport 클러스터로 Redshift 등록

This guide shows how to register a single Amazon Redshift Serverless database 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 tctl and tsh clients.

    Installing `tctl` and `tsh` clients
    1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and 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')"
      
    2. Follow the instructions for your platform to install tctl and tsh clients:

  • Redshift Serverless 구성이 있는 AWS 계정과 IAM 정책을 생성하고 연결할 수 있는 권한.
  • 명령줄 클라이언트 psql이 설치되어 있고 시스템 PATH 환경 변수에 추가되어 있어야 합니다.
  • Teleport Database Service를 실행할 호스트. 이 가이드에서는 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단계. 사용자 액세스를 위한 IAM 역할 생성#

Redshift Serverless에 대한 사용자 액세스를 제공하기 위해 AWS IAM 역할을 생성합니다. 이 역할은 Teleport 역할을 통해 Teleport 사용자에게 부여됩니다. 이 가이드에서는 이 역할에 teleport-redshift-serverless-access라는 이름을 사용합니다.

AWS 계정을 신뢰하도록 역할의 신뢰 정책을 구성합니다. 이렇게 하면 다음 단계에서 설정할 Teleport Database Service가 역할을 가정할 수 있습니다. 에 AWS 계정 ID를 할당합니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::



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.

권한 부여#

Database Service IAM 역할에 다음 AWS IAM 권한을 연결합니다:

Assign to your AWS account ID:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnectAsIAMRole",
            "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.

4/5단계. Teleport 역할 생성#

tsh로 Teleport 클러스터에 로그인된 워크스테이션에서 Redshift Serverless에 대한 액세스를 제공하는 새 역할을 정의합니다. 예시 파일은 redshift-role.yaml입니다:

version: v5
kind: role
metadata:
  name: redshift-serverless-access
spec:
  allow:
    db_labels:
      '*': '*'
    db_names:
    - dev
    db_users:
    - 'teleport-redshift-serverless-access'
  • db_users의 값은 이전 단계에서 생성한 IAM 역할에 해당합니다. 역할 이름 또는 IAM 역할의 전체 AWS ARN을 제공할 수 있습니다.
  • db_names의 값은 Redshift Serverless 구성에 따라 다르지만, dev는 AWS에서 적용하는 기본 이름입니다. 모든 인스턴스에 대한 액세스를 부여하려면 *을 제공할 수도 있습니다.

이 파일을 저장하고 Teleport 클러스터에 적용합니다:

$ tctl create -f redshift-role.yaml
role 'redshift-serverless-access' has been created

Assign the redshift-serverless-access role to your Teleport user by running the appropriate commands for your authentication provider:

5/5단계. 연결#

Database Service가 시작되어 클러스터에 연결된 후, 등록된 데이터베이스를 보려면 로그인합니다. --proxy를 Teleport Proxy Service 또는 클라우드 테넌트 주소로 교체하세요:

$ tsh login --proxy=mytenant.teleport.sh --user=alice
$ tsh db ls
Name        Description Labels
----------- ----------- ------
my-redshift             ...

Redshift Serverless 인스턴스에 연결하려면:

$ tsh db connect my-redshift --db-user=teleport-redshift-serverless-access --db-name=dev
psql (15.1, server 8.0.2)
WARNING: psql major version 15, server major version 8.0.
         Some psql features might not work.
SSL connection (protocol: TLSv1.3, cipher: TLS_CHACHA20_POLY1305_SHA256, compression: off)
Type "help" for help.

dev=>

데이터베이스에서 로그아웃하고 자격 증명을 제거하려면:

$ tsh db logout my-redshift
Note

이 섹션의 내용은 원문 문서를 참조하세요. (proxy-db-tunnel.mdx)

문제 해결#

사용자 권한 오류#

IAM 역할 teleport-redshift-serverless-access는 Redshift Serverless 데이터베이스 내에서 자동으로 IAMR:teleport-redshift-serverless-access로 매핑됩니다.

사용자(데이터베이스 관리자)는 이 새 IAM 역할로 로그인하기 전에 데이터베이스 사용자의 권한을 선택적으로 설정하여 사용자 권한 문제를 예방하거나 해결할 수 있습니다:

  1. Redshift Serverless 워크그룹에 관리자 사용자로 연결하고 다음을 실행합니다:

    CREATE USER "IAMR:teleport-redshift-serverless-access" WITH PASSWORD DISABLE;
    
  2. 이 사용자에게 적절한 데이터베이스 내 권한을 부여합니다. 예:

    GRANT SELECT ON TABLE users TO "IAMR:teleport-redshift-serverless-access";
    

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.

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 session_id AS pid, database_name,start_time,trim(query_text) AS query FROM SYS_QUERY_HISTORY 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.

다음 단계#