Teleport 클러스터는 서로 다른 유형의 데이터를 서로 다른 위치에 저장합니다. 기본적으로 모든 것은 Auth Service 호스트의 로컬 디렉터리에 저장됩니다.

셀프 호스팅 Teleport 배포의 경우, 저장된 데이터의 특성 (크기, 읽기/쓰기 비율, 가변성 등)에 따라 다른 스토리지 유형과 통합하도록 Teleport를 구성할 수 있습니다.

클러스터 상태#

클러스터 상태는 Auth Service에서 구성한 중앙 스토리지 위치에 저장됩니다. 클러스터 상태에는 다음이 포함됩니다:

• 오프라인/온라인 상태를 포함한 에이전트 및 Proxy Service 멤버십 정보.
• 활성 세션 목록.
• 로컬에 저장된 사용자 목록.
• RBAC 구성 (역할 및 권한).
• 동적 구성.

고가용성을 달성하는 두 가지 방법이 있습니다. 이 기능을 인프라에 "위탁"할 수 있습니다. 예를 들어, 고가용성 네트워크 기반 디스크 볼륨 (AWS EBS와 유사)을 사용하고 실패한 VM을 새 호스트로 마이그레이션하는 방법입니다. 이 시나리오에서는 Teleport 특정 작업이 필요하지 않습니다.

인프라에서 고가용성을 제공할 수 없는 경우 (베어 메탈 클러스터에서 Teleport를 실행하는 경우), Teleport를 고가용성 방식으로 실행하도록 구성할 수 있습니다.

Auth Service 상태#

여러 Teleport Auth Service 인스턴스를 실행하려면 먼저 아래에 나열된 고가용성 스토리지 백엔드 중 하나로 전환해야 합니다.

고가용성 스토리지 백엔드와 여러 Auth Service 인스턴스가 실행되면, 모든 Auth Service 인스턴스에 트래픽을 균등하게 분산하고 Auth Service와 통신해야 하는 모든 구성 요소의 단일 진입점을 갖기 위한 로드 밸런서를 생성해야 합니다. Teleport의 다른 구성 요소를 구성할 때 auth_server 필드에 로드 밸런서 주소를 사용하십시오.

로드 밸런서를 Layer 4 (TCP) 부하 분산, 라운드 로빈 부하 분산, 300초 유휴 타임아웃으로 구성하십시오.

Proxy Service 상태#

Teleport Proxy는 상태 비저장이므로 여러 인스턴스를 실행하는 것이 간단합니다.

기본 구성을 사용하는 경우, 로드 밸런서가 Teleport Proxy Service를 실행하는 서버로 포트 3080을 전달하도록 구성하십시오. TLS 라우팅을 사용하지 않거나 비기본 포트를 사용하는 경우, teleport.yaml의 listen_addr, tunnel_listen_addr, web_listen_addr에 지정한 포트를 전달하도록 로드 밸런서를 구성해야 합니다.

로드 밸런서를 Layer 4 (TCP) 부하 분산, 라운드 로빈 부하 분산, 300초 유휴 타임아웃으로 구성하십시오.

로드 밸런서가 HTTP 상태 확인을 지원하는 경우, Teleport를 실행하는 머신의 /readyz 진단 엔드포인트를 확인하도록 구성하십시오. 이 엔드포인트는 teleport start에 --diag-addr 플래그를 사용하여 활성화해야 합니다:

$ teleport start --diag-addr=0.0.0.0:3000

Teleport 서비스가 문제 없이 실행 중이면 /readyz 엔드포인트는 {"status":"ok"}로 응답합니다. 로드 밸런서 상태 확인이 성공하려면 엔드포인트가 proxy 인터페이스에 노출되어야 합니다. proxy 인스턴스에서만 이 작업을 수행하고 포트 3000이 공용 인터넷이 아닌 로드 밸런서에만 노출되도록 하십시오. 다른 서비스는 계속 127.0.0.1 로컬 루프백 인터페이스를 사용하십시오.

아래에서 Teleport를 고가용성으로 만들기 위해 etcd, PostgreSQL, DynamoDB, Firestore 스토리지 백엔드를 사용하는 방법을 설명합니다.

Etcd#

Teleport는 고가용성 배포를 달성하기 위해 etcd를 스토리지 백엔드로 사용할 수 있습니다. Teleport 키 및 사용자 레코드와 같은 비밀이 저장되는 곳이므로 이 구성에서 etcd에 대한 접근을 보호하기 위한 조치를 취해야 합니다.

etcd를 스토리지 백엔드로 사용하도록 Teleport를 구성하려면:

• etcd 버전 3.3 이상을 사용하고 있는지 확인하십시오.
• etcd의 클러스터 하드웨어 권장사항을 따르십시오. 특히 최적의 성능을 위해 SSD 또는 고성능 가상화 블록 디바이스 스토리지를 활용하십시오.
• etcd 보안 가이드를 사용하여 etcd를 설치하고 피어 및 클라이언트 TLS 인증을 구성하십시오. 자세한 내용은 아래의 mTLS 구성을 참조하십시오.
• 아래와 같이 구성 파일의 "storage" 섹션에서 etcd를 사용하도록 모든 Teleport Auth Service 인스턴스를 구성하십시오.
• etcd 백엔드에 연결된 여러 Auth Service 인스턴스를 배포하십시오.
• Auth Service에 연결하기 위해 auth_server가 Auth Service를 가리키는 여러 Proxy Service 인스턴스를 배포하십시오.

etcd와의 mTLS 인증 구성#

Teleport와 etcd 간에 mTLS를 구성하기 위해 cfssl과 etcd의 tls-setup 스크립트를 사용하는 것을 권장합니다. 전체 etcd 클러스터에 대한 인증서 및 키를 생성하는 데 도움이 됩니다. cfssl을 설치한 후, tls-setup 리포를 복제하고 Readme.md 파일을 따라 스크립트 구성을 사용자 지정하십시오. etcd 노드 수를 변경하는 경우 (따라서 infra 변수 수도 변경) makefile을 조정해야 합니다.

make를 실행하면 다음 파일이 생성됩니다:

• tls-setup/certs/ca.pem은 인증 기관이며 Teleport의 tls_ca_file 옵션에서 참조되어야 합니다 (아래의 Auth Service 인스턴스에서 etcd를 사용하도록 구성 참조).
• tls-setup/certs/peer-* 파일은 노드 간 통신을 위해 etcd에서 내부적으로 사용됩니다.
• tls-setup/certs/<host>.pem 및 tls-setup/certs/<host>-key.pem은 호스트 인증서와 해당 개인 키입니다. 각 etcd 호스트는 이를 알아야 하며, etcd 측에서 전송 보안을 제공하는 데 필요합니다.

이것으로 etcd 측에서 mTLS를 구성하기에 충분합니다.

Teleport 측에서는 클라이언트 인증서를 구성해야 합니다. 한 가지 방법은 다음과 같습니다:

1. 기본 CSR 생성:

   $ cfssl print-defaults csr > client.json
   

2. 이 CSR은 호스트가 아니라 클라이언트를 나타내므로 client.json 파일의 hosts 요소에서 모든 호스트 이름을 제거합니다. 필요한 경우 다른 옵션도 사용자 지정하십시오.

3. 각 Auth Service 인스턴스에 대해 클라이언트 인증서를 생성합니다:

   $ cfssl gencert -ca=certs/ca.pem \
     -ca-key=certs/ca-key.pem \
     -config=config/ca-config.json -profile=client client.json \
     | cfssljson -bare certs/client
   

   이는 tls-setup 도구가 이전에 실행되어 certs/ca.pem 및 certs/ca-key.pem 파일이 생성된 것으로 가정합니다.

   다음 파일이 생성됩니다:

   • certs/client.pem - Teleport 구성 파일의 tls_cert_file 옵션에서 참조됩니다.
   • certs/client-key.pem - Teleport 구성 파일의 tls_key_file 옵션에서 참조됩니다.

   certs/ca.pem과 함께 해당 Auth Service 인스턴스에 이 파일들을 업로드하십시오.

모든 키와 인증서를 생성한 후, 를 etcd 호스트 이름으로 교체하여 다음 명령의 변형을 사용하여 etcd를 실행하십시오:

$ etcd --cert-file=certs/host.pem \
  --key-file=certs/host-key.pem \
  --client-cert-auth \
  --trusted-ca-file=certs/ca.pem \
  --peer-cert-file=certs/peer-host.pem \
  --peer-key-file=certs/peer-host-key.pem \
  --advertise-client-urls=https://:2379 --listen-client-urls=https://:2379
  # ... 기타 해당 옵션

Auth Service 인스턴스에서 etcd를 사용하도록 구성#

모든 Auth Service 인스턴스의 구성 파일에 이 설정을 추가하십시오:

teleport:
  storage:
     type: etcd

     # 연결할 etcd 피어 목록:
     peers: ["https://172.17.0.1:4001", "https://172.17.0.2:4001"]

     # etcd에 연결하기 위한 TLS 클라이언트 인증서 및 키 파일의 필수 경로.
     #
     # 위에 설명된 대로 cfssl을 사용한 경우, 이전 단계의
     # certs/client.pem 및 certs/client-key.pem 파일이어야 합니다.
     tls_cert_file: /var/lib/teleport/etcd-cert.pem
     tls_key_file: /var/lib/teleport/etcd-key.pem

     # etcd 노드를 인증하기 위한 신뢰할 수 있는 CA 기관 파일 (선택 사항)
     #
     # tls-setup 스크립트를 사용한 경우, 이 CA 인증서는
     # certs/ca.pem 파일이어야 합니다.
     tls_ca_file: /var/lib/teleport/etcd-ca.pem

     # TLS 클라이언트 인증서를 사용하지 않는 경우 대체 비밀번호 기반 인증.
     #
     # 새 사용자 설정에 대한 내용은
     # https://etcd.io/docs/v3.4.0/op-guide/authentication/을 참조하십시오.
     username: username
     password_file: /mnt/secrets/etcd-pass

     # Teleport가 상태를 저장할 etcd 키 (위치).
     # '/'로 끝나야 합니다!
     prefix: /teleport/

     # 권장하지 않음: 자체 서명 인증서가 허용되는 etcd 비보안 모드를 활성화합니다
     insecure: false

     # 선택적으로 클라이언트 메시지 크기 제한을 설정합니다.
     # 일반적으로 기본값인 2MiB보다 크게 늘리는 데 사용됩니다
     # (서버 기본값 1.5MiB + gRPC 오버헤드 바이트).
     # 이 값이 `--max-request-bytes` (기본값 1.5MiB)로 지정된
     # etcd 서버의 값을 초과하지 않도록 하십시오.
     # 두 값을 동기화하십시오.
     #
     # 자세한 내용은 https://etcd.io/docs/v3.4.0/dev-guide/limit/을 참조하십시오
     #
     # 예시로 크기를 15MiB로 늘립니다:
     etcd_max_client_msg_size_bytes: 15728640

디스크 크기 조정, 컴팩션 및 조각 모음#

대규모 배포의 경우 높은 쓰기 처리량을 계획하고 기록 보존 요구 사항을 충족하기에 충분한 스토리지를 할당하십시오.

최소 스토리지 크기 (메타데이터 제외)에 대한 경험적 규칙은 다음과 같습니다:

minimum_storage ≈ backend_resource_count * average_record_size * auto_compaction_retention

• backend_resource_count: 복제본을 포함한 전체 리소스 수.
• average_record_size: 리소스의 평균 크기 (바이트).
• auto_compaction_retention: 항목당 최대 개정 수.

개정 수를 기반으로 한 자동 컴팩션을 강력히 권장합니다. 컴팩션 중에는 물리적 디스크 공간이 회수되지 않습니다. 공간을 회수하려면 사용 가능한 디스크 공간과 쓰기 처리량에 따라 정기적인 조각 모음을 예약하십시오.

필요에 따라 조정하려면 etcd_mvcc_db_total_size_in_bytes 및 etcd_mvcc_db_total_size_in_use_in_bytes 메트릭을 사용하십시오.

자동 컴팩션 및 조각 모음에 대한 내용은 etcd 유지 관리 가이드를 참조하십시오.

디스크 크기 조정 예시#

50k 리소스가 있고 평균 크기가 2 KiB이며 보존 기록이 5회인 클러스터의 경우 데이터셋은 최소 다음 크기가 예상됩니다:

50000 * 2 KiB * 5 ≈ 488 MiB

메타데이터 및 단편화 오버헤드를 위해 20-40%의 추가 안전 마진이 권장됩니다.

기존 리소스가 있는 경우 다음 명령을 사용하여 크기를 추정할 수 있습니다. 를 리소스 이름 (예: role/editor)으로 지정하십시오:

tctl get  --format=json | awk '{ total += length($0) } END { print total * 2 }'

PostgreSQL#

Teleport는 고가용성을 달성하기 위해 PostgreSQL을 스토리지 백엔드로 사용할 수 있습니다. Teleport 키 및 사용자 레코드와 같은 비밀이 저장되는 곳이므로 이 구성에서 PostgreSQL에 대한 접근을 보호하기 위한 조치를 취해야 합니다. PostgreSQL 백엔드는 두 가지 유형의 Teleport 데이터를 지원합니다:

• 클러스터 상태
• 감사 로그 이벤트

PostgreSQL 백엔드는 PostgreSQL 13 이상이 필요하며, 클러스터 상태만을 위해 wal2json 논리 디코딩 플러그인이 필요합니다. 이 플러그인은 Debian 및 RPM 기반 Linux 배포판의 PostgreSQL Apt 및 Yum 저장소의 모든 안정 버전 패키지에서 사용 가능하거나, 저장소에 제공된 지침을 따라 컴파일할 수 있습니다. 이 플러그인은 Azure Database for PostgreSQL에서 추가 단계 없이 미리 설치되어 있습니다.

Teleport는 클러스터 상태와 감사 로그를 위한 별도의 데이터베이스가 필요하며, 권한이 주어지면 생성을 시도합니다. 또한 필요에 따라 데이터베이스 스키마를 설정하므로 데이터베이스에 대한 사용자 소유권을 부여하는 것을 권장합니다.

클러스터 상태를 위한 PostgreSQL 백엔드는 데이터베이스의 변경 스트림을 얻기 위해 논리 디코딩을 사용하는 기능에 의존합니다. 이 때문에 wal_level 매개변수는 logical로 설정해야 하며 max_replication_slots는 실행할 Teleport Auth Service 인스턴스 수만큼 설정해야 합니다 (네트워크 조건을 고려하여 더 높은 수를 권장합니다).

Teleport Auth Service는 시작할 때 및 PostgreSQL 클러스터에 새 연결을 재설정할 때 복제 슬롯을 생성할 수 있어야 하며, 장기 실행 트랜잭션은 이를 방지합니다. 따라서 다른 워크로드가 단기 트랜잭션으로만 구성된 경우에만 공유 PostgreSQL 클러스터에 Teleport 클러스터 상태를 저장하는 것이 좋습니다.

wal_level은 서버 시작 시에만 설정할 수 있으므로 postgresql.conf에 설정해야 합니다:

# wal_level의 기본값은 replica입니다
wal_level = logical

# max_replication_slots의 기본값은 10입니다
max_replication_slots = 10

또한 데이터베이스 사용자는 initiating replication 역할 속성을 가져야 합니다. psql 셸에서:

postgres=# CREATE USER new_user WITH REPLICATION;
CREATE ROLE

postgres=# ALTER ROLE existing_user WITH LOGIN REPLICATION;
ALTER ROLE

복제 권한은 전체 클러스터에 대한 사실상 전체 읽기 접근 (물리적 복제 연결) 또는 사용자가 연결할 수 있는 모든 데이터베이스에 대한 접근을 허용하므로, PostgreSQL 클러스터가 Teleport와 다른 애플리케이션 간에 공유되는 경우 사용자가 복제 연결을 열거나 Teleport에 사용되는 데이터베이스 이외의 데이터베이스에 연결하는 것을 방지하는 것이 권장됩니다.

편의를 위해 Teleport는 initiating replication 역할 속성을 자체적으로 부여하려고 시도합니다. 이는 API를 통해 수퍼유저 계정을 생성할 수 있는 일부 관리형 서비스 (예: Azure Database for PostgreSQL)의 기능을 수용하기 위한 것입니다. 전체 PostgreSQL 클러스터가 Teleport 전용인 경우에만 이를 활용해야 합니다.

PostgreSQL을 사용하도록 Teleport를 구성하려면:

• 아래와 같이 teleport.yaml의 storage 섹션에서 PostgreSQL 백엔드를 사용하도록 모든 Teleport Auth Service 인스턴스를 구성하십시오.
• PostgreSQL 스토리지 백엔드에 연결된 여러 Auth Service 인스턴스를 배포하십시오.
• 여러 Proxy Service 노드를 배포하십시오.
• Proxy Service 인스턴스와 직접 Auth Service에 연결하는 모든 Teleport 에이전트 서비스가 Auth Service 인스턴스의 로드 밸런서 주소로 auth_server 구성 설정이 채워져 있는지 확인하십시오.

teleport:
  storage:
    type: postgresql

    # conn_string은 libpq 호환 연결 문자열입니다 (
    # https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNSTRING 참조);
    # pool_max_conns는 클러스터 상태 데이터베이스에 사용되는 연결 풀의
    # 최대 연결 수를 결정하는 추가 매개변수입니다 (변경 피드는
    # 추가 연결을 사용함). 기본값은 사용 가능한 CPU 수에 따라 다릅니다.
    #
    # 인증서가 기본 ~/.postgresql 위치에 저장되어 있지 않은 경우,
    # sslcert, sslkey, sslrootcert 매개변수로 지정해야 합니다.
    conn_string: postgresql://user_name@database-address/teleport_backend?sslmode=verify-full&pool_max_conns=20

    # 특정 관리 환경에서는 논리 디코딩의 설정 및 사용에
    # 사용되는 연결에 다른 사용자 또는 다른 설정을 사용하는 것이
    # 필요하거나 편리할 수 있습니다. 지정된 경우 Teleport는
    # conn_string 대신 change_feed_conn_string의 연결 문자열을 사용합니다.
    change_feed_conn_string: postgresql://replication_user_name@database-address/teleport_backend?sslmode=verify-full

    # postgresql:// 스키마를 가진 audit_events_uri는 감사 로그 저장에
    # PostgreSQL 백엔드를 사용합니다. URI는 클러스터 상태 conn_string과 같이
    # libpq 호환 연결 문자열이지만 key=value 쌍으로 지정할 수 없습니다.
    # 클러스터 상태와 감사 로그에 완전히 다른 PostgreSQL 클러스터를 지정할 수 있습니다.
    #
    # 인증서가 기본 ~/.postgresql 위치에 저장되어 있지 않은 경우,
    # sslcert, sslkey, sslrootcert 매개변수로 지정해야 합니다.
    audit_events_uri:
      - postgresql://user_name@database-address/teleport_audit?sslmode=verify-full

감사 로그 이벤트는 기본 보존 기간인 8766시간 (1년) 후에 주기적으로 삭제됩니다. URI 단편의 retention_period 또는 disable_cleanup 매개변수를 지정하여 다른 보존 기간을 선택하거나 정리를 완전히 비활성화할 수 있습니다:

teleport:
  storage:
    audit_events_uri:
      - postgresql://user_name@database-address/teleport_audit?sslmode=verify-full#disable_cleanup=false&retention_period=2160h

인증#

Teleport를 PostgreSQL에 인증하기 위해 클라이언트 인증서를 사용하고, 클라이언트 측에서 TLS 사용을 강제하고 서버 인증서를 검증하는 것을 강력히 권장합니다.

Teleport 연결이 클라이언트 인증서를 사용하도록 하려면 pg_hba.conf 파일을 다음 줄을 포함하도록 업데이트해야 합니다. 자세한 내용은 PostgreSQL 문서의 pg_hba.conf 파일을 참조하십시오.

# TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD
hostssl teleport        all             ::/0                    cert
hostssl teleport        all             0.0.0.0/0               cert

비밀번호 사용이 불가피한 경우, Teleport의 구성 파일에 저장하는 대신 ~/.pgpass 파일에 구성하는 것을 권장합니다.

Microsoft Entra ID 인증#

Azure에서 Teleport를 실행하는 경우, Teleport는 비밀을 관리하지 않고도 Azure Database for PostgreSQL 서버에 연결하기 위해 Microsoft Entra ID 인증을 활용할 수 있습니다:

teleport:
  storage:
    type: postgresql

    conn_string: postgresql://user_name@database-name.postgres.database.azure.com/teleport_backend?sslmode=verify-full&pool_max_conns=20
    auth_mode: azure

    audit_events_uri:
      - postgresql://user_name@database-name.postgres.database.azure.com/teleport_audit?sslmode=verify-full#auth_mode=azure

auth_mode가 azure로 설정되면, Teleport는 데이터베이스 비밀번호로 사용할 단기 토큰을 사용 가능한 자격 증명에서 자동으로 가져옵니다. 데이터베이스 사용자는 Microsoft Entra ID를 사용한 연결을 허용하도록 구성해야 합니다.

Teleport는 환경 변수, Microsoft Entra Workload ID 자격 증명, 또는 관리 ID 자격 증명으로 지정된 Microsoft Entra ID 자격 증명을 활용합니다.

Google Cloud IAM 인증#

Google Cloud에서 Teleport를 실행하는 경우, Teleport는 비밀을 관리하지 않고도 GCP Cloud SQL for PostgreSQL에 연결하기 위해 IAM 인증을 활용할 수 있습니다:

teleport:
  storage:
    type: postgresql
    auth_mode: gcp-cloudsql

    # GCP 연결 이름 형식은 <project>:<location>:<instance>입니다.
    gcp_connection_name: 




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 Teleport Auth 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.


S3 백엔드 구성#
다음은 Teleport Auth Service가 녹화된 세션을 S3 버킷에 저장하도록 구성하는 방법의 예시입니다.
teleport:
  storage:
      # 리전 설정은 Teleport가 사용할 수 있는 모든 AWS 서비스에 대한
      # 기본 AWS 리전을 설정합니다 (DynamoDB, S3)
      region: us-east-1

      # 녹화된 세션을 저장할 S3 버킷 경로.
      audit_sessions_uri: "s3://Example_TELEPORT_S3_BUCKET/records"

      # Teleport는 자격 증명을 가정합니다. 공급자 체인, IAM 역할 가정 또는
      # 홈 폴더의 표준 .aws/credentials를 사용합니다.

S3 URL에 선택적 쿼리 매개변수를 추가할 수 있습니다. Teleport Auth Service는 이 매개변수를 읽어 S3와의 상호 작용을 구성합니다:
s3://bucket/path?region=us-east-1&endpoint=mys3.example.com&insecure=false&disablesse=false&acl=private&use_fips_endpoint=true


region=us-east-1 - 사용할 Amazon 리전을 설정합니다.


endpoint=mys3.example.com - 사용자 지정 S3 엔드포인트에 연결합니다. 선택 사항입니다.


insecure=true - true 또는 false로 설정합니다. true이면 TLS가 비활성화됩니다.
기본값은 false입니다.


disablesse=true - true 또는 false로 설정합니다. Auth Service는 S3 버킷에 개체를 업로드하기 전에 이 값을 확인합니다.
false인 경우, Auth Service는 업로드의 서버 측 암호화 구성을 AWS Key Management Service를 사용하도록 설정하고, sse_kms_key가 설정된 경우 이 키를 사용하도록 업로드를 구성합니다.
true인 경우, Auth Service는 개체 업로드에 대한 명시적인 서버 측 암호화 구성을 설정하지 않으므로, 업로드는 버킷 수준의 서버 측 암호화 구성을 사용합니다.


sse_kms_key=kms_key_id - 유효한 AWS KMS CMK 키 ID로 설정된 경우, S3에 업로드되는 모든 개체는 이 키로 암호화됩니다 (disablesse가 false인 한). 세부 정보는 아래에서 확인할 수 있습니다.


acl=private - 사용할 canned ACL을 설정합니다. 사전 정의된 ACL 값 중 하나여야 합니다.


use_fips_endpoint=true - S3 FIPS 엔드포인트 구성


use_s3_virtual_style_addressing - 버킷에 경로 스타일 URL 대신 가상 호스트 스타일 URL을 사용할지 여부. 사용자 지정 엔드포인트가 설정된 경우에만 적용됩니다. 설정되지 않으면 기본값은 false입니다. 사용자 지정 엔드포인트 없이 사용하면 이 옵션은 효과가 없습니다.


complete_initiators - 지정된 경우, Teleport는 지정된 개시자 집합에 의해 시작된 업로드만 완료합니다. 이것은 Teleport 이외의 소프트웨어가 녹화 버킷에서 멀티파트 업로드를 시작하는 시나리오에서 유용합니다. 허용하려는 개시자의 표시 이름으로 설정해야 합니다.


S3 IAM 정책#

On startup, the Teleport Auth Service checks whether the S3 bucket you have
configured for session recording storage exists. If it does not, the Auth
Service attempts to create and configure the bucket.
The IAM permissions that the Auth Service requires to manage its session
recording bucket depends on whether you expect to create the bucket yourself or
enable the Auth Service to create and configure it for you:




S3 서버 측 암호화#
Teleport는 S3에 업로드된 개체를 암호화하기 위해 사용자 지정 AWS KMS 고객 관리 키를 사용하는 것을 지원합니다.
이를 통해 버킷에 대한 읽기 접근 권한이 있는 사람과 별도로 세션 녹화와 같은 개체를 읽을 수 있는 사람을 제한할 수 있습니다.
위의 sse_kms_key 매개변수는 대칭 표준 사양 KMS 키에 해당하는 유효한 KMS CMK ID로 설정할 수 있습니다.
일반적인 사용 사례에 대한 예시 템플릿 KMS 키 정책이 아래에 제공됩니다. IAM 사용자는 기본적으로 어떤 키에도 접근할 수 없습니다. 권한은 정책에서 명시적으로 부여해야 합니다.
암호화/복호화#
이 정책은 IAM 사용자가 개체를 암호화하고 복호화할 수 있도록 합니다.
이를 통해 클러스터 auth가 세션 녹화를 쓰고 재생할 수 있습니다.
[iam-key-admin-arn]을 관리 키 접근 권한이 있는 사용자의 IAM ARN으로, [auth-node-iam-arn]을 Teleport auth 노드가 사용하는 사용자의 IAM ARN으로 교체하십시오.
{
  "Id": "Teleport Encryption and Decryption",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Teleport CMK Admin",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[iam-key-admin-arn]"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Teleport CMK Auth",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[auth-node-iam-arn]"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

별도의 클러스터를 사용한 암호화/복호화#
이 정책은 암호화와 복호화를 위해 별도의 IAM 사용자를 지정할 수 있도록 합니다.
세션 녹화를 재생하지 않고 쓰기만 할 수 있는 주 클러스터가 있는 멀티 클러스터 구성을 설정하는 데 사용할 수 있습니다.
복호화 접근 권한이 있는 다른 IAM 사용자로 인증하는 별도의 클러스터를 세션 녹화 재생에 사용할 수 있습니다.
이를 위해 두 번째 클러스터는 주 클러스터와 동일한 감사 로그에 연결되어야 합니다.
세션 녹화를 감지하는 데 필요합니다.
[iam-key-admin-arn]을 관리 키 접근 권한이 있는 사용자의 IAM ARN으로, [iam-node-write-arn]을 주 쓰기 전용 클러스터 auth 노드가 사용하는 IAM ARN으로, [iam-node-read-arn]을 읽기 전용 클러스터가 사용하는 IAM ARN으로 교체하십시오.
{
  "Id": "Teleport Separate Encryption and Decryption",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Teleport CMK Admin",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[iam-key-admin-arn]"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Teleport CMK Auth Encrypt",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[auth-node-write-arn]"
      },
      "Action": [
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Teleport CMK Auth Decrypt",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[auth-node-read-arn]"
      },
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

ACL 예시: 개체 소유권 이전#
AWS 계정 A에서 AWS 계정 B가 소유한 버킷에 업로드하고 A가 개체 소유권을 유지하려는 경우, 두 가지 방법 중 하나를 취할 수 있습니다.
ACL 없이#
ACL이 비활성화된 경우, 개체 소유권이 Bucket owner enforced로 설정되며 아무 조치도 필요하지 않습니다.
ACL 사용#

개체 소유권을 Bucket owner preferred로 설정합니다 (관리 콘솔의 권한 아래).
audit_sessions_uri에 acl=bucket-owner-full-control을 추가합니다.

소유권 이전을 강제하려면 bucket-owner-full-control canned ACL을 포함하는 업로드만 허용하도록 B의 버킷 정책을 설정하십시오.
{
    "Version": "2012-10-17",
    "Id": "[id]",
    "Statement": [
        {
            "Sid": "[sid]",
            "Effect": "Allow",
            "Principal": {
                "AWS": "[ARN of account A]"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::BucketName/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}


자세한 내용은 AWS 문서를 참조하십시오.
DynamoDB#
AWS에서 Teleport를 실행하는 경우, 고가용성을 달성하기 위해 DynamoDB를 스토리지 백엔드로 사용할 수 있습니다. DynamoDB 백엔드는 두 가지 유형의 Teleport 데이터를 지원합니다:

클러스터 상태
감사 로그 이벤트

Teleport는 스토리지 백엔드 관리를 위해 DynamoDB 및 DynamoDB Streams 엔드포인트를 사용합니다.
DynamoDB는 녹화된 세션을 저장할 수 없습니다. 위에 표시된 것처럼 AWS S3를 사용하는 것을 권장합니다.
Warning
Teleport는 스토리지에 단일 리전 DynamoDB 테이블을 지원합니다. 감사 로그 이벤트에 글로벌 테이블을 사용하는 것은 테스트되지 않았으며 지원되지 않습니다. 여러 리전에서 동시에 클러스터 상태에 글로벌 테이블을 사용하면 다중 리전 강력 일관성(MRSC)을 사용하는 경우에도 동시성 문제 및 데이터 손실이 발생할 수 있습니다. 하나의 활성 리전에서 Teleport Auth 서비스의 복제본을 두 개 이상 실행할 때 스트림의 읽기 스로틀링이 발생할 수 있으므로, 다중 리전 최종 일관성(MREC) 모드에서 리전 간 복제 전용으로 글로벌 테이블을 사용하는 것도 권장하지 않습니다.

AWS 인증#
Teleport Auth Service는 DynamoDB에 인증하기 위해 AWS 자격 증명을 읽을 수 있어야 합니다.

Grant the Teleport Auth Service access to credentials that it can use to authenticate to
AWS.

If you are running the Teleport Auth Service on an EC2 instance, you may use the EC2
Instance Metadata Service method
If you are running the Teleport Auth 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 Teleport Auth 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.


Teleport Auth Service가 인증하는 IAM 역할에는 다음 섹션에 지정된 정책이 있어야 합니다.
IAM 정책#
Teleport에 할당된 IAM 역할이 DynamoDB에 대한 충분한 접근으로 구성되어 있는지 확인하십시오.

On startup, the Teleport Auth Service checks whether the DynamoDB table you have
specified in its configuration file exists. If the table does not exist, the
Auth Service attempts to create one.
The IAM permissions that the Auth Service requires to manage DynamoDB tables
depends on whether you expect to create a table yourself or enable the Auth
Service to create and configure one for you:




DynamoDB 백엔드 구성#
DynamoDB를 사용하도록 Teleport를 구성하려면:

아래와 같이 teleport.yaml의 "storage" 섹션에서 DynamoDB 백엔드를 사용하도록 모든 Teleport Auth 서버를 구성하십시오.
Auth 서버는 DynamoDB 및 DynamoDB Streams 엔드포인트에 도달할 수 있어야 합니다.
DynamoDB 스토리지 백엔드에 연결된 최대 두 개의 auth 서버를 배포하십시오.
여러 proxy 노드를 배포하십시오.
모든 Teleport 리소스 서비스가 클러스터의 Auth Service 인스턴스 주소로 auth_servers 구성 설정이 채워져 있는지 확인하십시오.

Warning
AWS는 두 개 이상의 프로세스가 동일한 스트림의 샤드에서 동시에 읽는 경우 DynamoDB를 스로틀링할 수 있으므로, DynamoDB 백엔드에서 읽는 Auth Service 인스턴스를 두 개 이상 배포해서는 안 됩니다. DynamoDB Streams에 대한 자세한 내용은 AWS 문서를 참조하십시오.

teleport:
  storage:
    type: dynamodb
    # DynamoDB 인스턴스의 리전 위치, https://docs.aws.amazon.com/en_pv/general/latest/gr/rande.html#ddb_region
    region: us-east-1

    # DynamoDB 테이블 이름. 존재하지 않으면 Teleport가 생성합니다.
    table_name: Example_TELEPORT_DYNAMO_TABLE_NAME

    # 이 설정은 Teleport가 감사 이벤트를 세 곳으로 보내도록 구성합니다:
    # DynamoDB에 복사본을 유지하고, 로컬 파일 시스템에 복사본을 유지하고, 이벤트를 stdout으로 출력합니다.
    # 참고: DynamoDB 이벤트 테이블은 일반 Teleport 데이터베이스 테이블과 다른 스키마를 가지고 있으므로,
    # 동일한 테이블을 양쪽에 사용하려고 하면 오류가 발생합니다.
    # DynamoDB와 같이 고가용성 스토리지를 사용할 때, 목록은 항상 고가용성 스토리지 방법을 먼저 지정해야 합니다.
    # 이것이 Teleport 웹 UI가 표시할 이벤트의 소스로 사용하는 것이기 때문입니다.
    audit_events_uri:  ['dynamodb://events_table_name', 'file:///var/lib/teleport/audit/events', 'stdout://']

    # 이 설정은 Teleport가 녹화된 세션을 S3 버킷에 저장하도록 구성합니다:
    audit_sessions_uri: s3://Example_TELEPORT_S3_BUCKET/records

    # 기본적으로 Teleport는 1년의 AWS TTL로 감사 이벤트를 저장합니다.
    # 이 값은 아래와 같이 구성할 수 있습니다. 0초로 설정하면 TTL이 비활성화됩니다.
    retention_period: 365d

    # DynamoDB 테이블에 대해 요청당 결제 또는 프로비저닝된 청구를 활성화합니다. Teleport가 테이블을 생성할 때 설정합니다.
    # 가능한 값: "pay_per_request" 및 "provisioned"
    # 기본값: "pay_per_request"
    billing_mode: "pay_per_request"

    # continuous_backups는 선택적으로 연속 백업을 활성화하는 데 사용됩니다.
    # 기본값: false
    continuous_backups: true


us-east-1 및 Example_TELEPORT_DYNAMO_TABLE_NAME을 자체 설정으로 교체하십시오. Teleport가 테이블을 자동으로 생성합니다.
Example_TELEPORT_DYNAMO_TABLE_NAME과 events_table_name은 반드시 다른 DynamoDB 테이블이어야 합니다. 각각의 스키마가 다릅니다. 동일한 테이블 이름을 양쪽에 사용하면 오류가 발생합니다.
위의 감사 로그 설정은 선택 사항입니다. 지정된 경우 Teleport는 DynamoDB에 감사 로그를 저장하며 세션 녹화는 반드시 S3 버킷에 저장해야 합니다. 즉, audit_xxx 설정이 모두 존재해야 합니다. 설정되지 않으면 Teleport는 감사 로그에 로컬 파일 시스템을 기본값으로 사용합니다. 즉, Auth Service 인스턴스에서 /var/lib/teleport/log입니다.

아래에 표시된 선택적 GET 매개변수는 Teleport가 DynamoDB 엔드포인트와 상호 작용하는 방식을 제어합니다.
dynamodb://events_table_name?region=us-east-1&endpoint=dynamo.example.com&use_fips_endpoint=true

region=us-east-1 - 사용할 Amazon 리전을 설정합니다.
endpoint=dynamo.example.com - 사용자 지정 S3 엔드포인트에 연결합니다.
use_fips_endpoint=true - DynamoDB FIPS 엔드포인트 구성.

DynamoDB 연속 백업
DynamoDB를 설정할 때 필요한 경우 과거 스냅샷에서 클러스터 상태를 복원할 수 있도록 백업을 활성화하는 것이 중요합니다.

AWS 블로그 게시물 - Amazon DynamoDB 연속 백업

DynamoDB 온디맨드
최상의 성능을 위해 프로비저닝된 모드로 용량을 수동으로 구성하는 대신 온디맨드 모드를 사용하는 것이 권장됩니다. 이렇게 하면 과소 추정된 사용량 또는 사용량 증가로 인한 DynamoDB 스로틀링이 Teleport에 영향을 주지 않도록 방지합니다.

AWS 문서 - Amazon DynamoDB 온디맨드 및 요청당 결제

AWS FIPS 엔드포인트 구성#
이 구성 옵션은 Amazon S3 및 Amazon DynamoDB에 적용됩니다.
use_fips_endpoint를 true 또는 false로 설정합니다. true이면 FIPS Dynamo 엔드포인트가 사용됩니다.
false이면 일반 Dynamo 엔드포인트가 사용됩니다. 설정되지 않으면 AWS 환경 변수 AWS_USE_FIPS_ENDPOINT가 사용할 엔드포인트를 결정합니다.
Teleport가 --fips 플래그로 실행되면 FIPS 엔드포인트도 사용됩니다.
구성 옵션 우선순위는 다음 순서로 적용됩니다:

위에 표시된 대로 use_fips_endpoint 쿼리 매개변수 설정
Teleport 실행 시 --fips 플래그 사용
AWS 환경 변수 사용

AWS_USE_FIPS_ENDPOINT에 대한 경고
이 환경 변수를 true로 설정하면 모든 AWS 리소스 유형에 대해 FIPS 엔드포인트가 활성화됩니다. 일부 FIPS 엔드포인트는 특정 리전이나 환경에서 지원되지 않거나 GovCloud에서만 지원됩니다.

Athena#
AWS에서 Teleport를 실행하는 경우, S3에 저장된 Parquet 파일을 관리하는 Athena 기반 감사 로그 시스템을 스토리지 백엔드로 사용하여 고가용성을 달성할 수 있습니다. Athena 백엔드는 한 가지 유형의 Teleport 데이터인 감사 이벤트만 지원합니다.
Athena 감사 백엔드는 규모와 검색 측면에서 DynamoDB보다 더 우수합니다.
Athena 감사 로그는 결과적으로 일관성이 있습니다. Teleport 웹 UI에서 이벤트를 볼 수 있을 때까지 최대 1분 (batchMaxInterval 설정 및 이벤트 부하에 따라 다름)이 걸릴 수 있습니다.
인프라 설정#
Auth Service는 이벤트 게시를 위해 SNS 주제를 구독하는 SQS 큐를 사용합니다. 단일 Auth Service 인스턴스가 SQS에서 배치로 이벤트를 읽고, 이를 Parquet 형식으로 변환하여 결과 데이터를 S3로 보냅니다. 쿼리 중에 Athena 엔진은 Glue 테이블에서 메타데이터를 읽으면서 S3에서 이벤트를 검색합니다.
다음 Terraform 스크립트를 사용하여 Athena 백엔드를 지원하는 데 필요한 인프라를 설정할 수 있습니다:

Terraform 스크립트"
```
Note
이 섹션의 내용은 원문 문서를 참조하세요. (variables.tf)
Note
이 섹션의 내용은 원문 문서를 참조하세요. (athena.tf)
</details>

### Athena 감사 로그 백엔드 구성

Athena를 사용하도록 Teleport를 구성하려면:

- 인프라 준비
- Teleport 구성 파일의 `audit_events_uri` 배열 내에 Athena URL을 지정하십시오:

```yaml
teleport:
  storage:
    # 이 설정은 Teleport가 Athena에 감사 로그 복사본을 유지하고
    # 로컬 파일 시스템에 복사본을 유지하며 이벤트를 stdout으로 출력하도록 구성합니다.
    audit_events_uri:
      # 전체 Athena URL에 대한 자세한 내용은 아래에 표시됩니다.
      - 'athena://database.table?params'
      - 'file:///var/lib/teleport/audit/events'
      - 'stdout://'

다음은 audit_events_uri 구성 필드 내의 Amazon Athena URL 예시입니다:
athena://db.table?topicArn=arn:aws:sns:region:account_id:topic_name&largeEventsS3=s3://transient/large_payloads&locationS3=s3://long-term/events&workgroup=workgroup&queueURL=https://sqs.region.amazonaws.com/account_id/queue_name&queryResultsS3=s3://transient/query_results

URL 호스트 이름은 Athena 감사 로거가 사용할 Glue 데이터베이스와 테이블을 가리키는 database.table로 구성됩니다.
다른 매개변수는 Athena URL 내에 쿼리 매개변수로 지정됩니다.
다음 매개변수는 필수입니다:



매개변수 이름
예시 값
설명




topicArn
arn:aws:sns:region:account_id:topic_name
이벤트가 게시되는 SNS 주제의 ARN


locationS3
s3://long-term/events
장기 스토리지에 사용되는 S3 버킷


largeEventsS3
s3://transient/large_payloads
대형 이벤트에 대한 임시 스토리지에 사용되는 S3 버킷


queueURL
https://sqs.region.amazonaws.com/account_id/queue_name
SNS 주제 구독에 사용되는 SQS URL


workgroup
workgroup_name
쿼리에 사용되는 Athena 워크그룹


queryResultsS3
s3://transient/results
쿼리 결과에 대한 임시 스토리지에 사용되는 S3 버킷



다음 매개변수는 선택 사항입니다:



매개변수 이름
예시 값
설명




region
us-east-1
AWS 리전. 비어 있으면 AuditConfig 또는 주변 AWS 자격 증명 중 하나로 기본 설정됩니다


batchMaxItems
20000
단일 Parquet 파일에 허용되는 최대 이벤트 수를 정의합니다 (기본값 20000)


batchMaxInterval
1m
Parquet 파일을 생성하기 전에 수신 데이터를 버퍼링하는 데 사용되는 최대 간격을 정의합니다 (기본값 1m)



AWS 인증#
Teleport Auth Service는 Athena에 인증하기 위해 AWS 자격 증명을 읽을 수 있어야 합니다.

Grant the Teleport Auth Service access to credentials that it can use to authenticate to
AWS.

If you are running the Teleport Auth Service on an EC2 instance, you may use the EC2
Instance Metadata Service method
If you are running the Teleport Auth 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 Teleport Auth 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.


Teleport Auth Service가 인증하는 IAM 역할에는 다음 섹션에 지정된 정책이 있어야 합니다.
IAM 정책#
Teleport에 할당된 IAM 역할이 Athena에 대한 충분한 접근으로 구성되어 있는지 확인하십시오. 아래에서 Auth Service가 Athena 감사 로그를 감사 이벤트 백엔드로 사용하기 위해 필요한 IAM 권한을 찾을 수 있습니다.
아래 정책 예시에서 다음 값을 교체해야 합니다:



자리 표시자 값
교체할 값




eu-central-1
AWS 리전


1234567890
AWS 계정 ID


audit-long-term
장기 스토리지에 사용되는 S3 버킷


audit-transient
임시 스토리지에 사용되는 S3 버킷


audit-sqs
SNS 주제 이름


audit-sns
SQS 이름


kms_id
SNS/SQS/S3의 서버 측 암호화에 사용되는 KMS 키 ID


audit_db
감사 로그에 사용되는 Glue 데이터베이스


audit_table
감사 로그에 사용되는 Glue 테이블


audit_workgroup
감사 로그에 사용되는 Athena 워크그룹



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:ListBucketMultipartUploads",
                "s3:GetBucketLocation",
                "s3:ListBucketVersions",
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::audit-transient",
                "arn:aws:s3:::audit-long-term"
            ],
            "Sid": "AllowListingMultipartUploads"
        },
        {
            "Action": [
                "s3:PutObject",
                "s3:ListMultipartUploadParts",
                "s3:GetObjectVersion",
                "s3:GetObject",
                "s3:DeleteObjectVersion",
                "s3:DeleteObject",
                "s3:AbortMultipartUpload"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::audit-transient/results/*",
                "arn:aws:s3:::audit-transient/large_payloads/*",
                "arn:aws:s3:::audit-long-term/events/*"
            ],
            "Sid": "AllowMultipartAndObjectAccess"
        },
        {
            "Action": "sns:Publish",
            "Effect": "Allow",
            "Resource": "arn:aws:sns:eu-central-1:1234567890:audit-sns",
            "Sid": "AllowPublishSNS"
        },
        {
            "Action": [
                "sqs:ReceiveMessage",
                "sqs:DeleteMessage"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:sqs:eu-central-1:1234567890:audit-sqs",
            "Sid": "AllowReceiveSQS"
        },
        {
            "Action": [
                "glue:GetTable",
                "athena:StartQueryExecution",
                "athena:GetQueryResults",
                "athena:GetQueryExecution"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:glue:eu-central-1:1234567890:table/audit_db/audit_table",
                "arn:aws:glue:eu-central-1:1234567890:database/audit_db",
                "arn:aws:glue:eu-central-1:1234567890:catalog",
                "arn:aws:athena:eu-central-1:1234567890:workgroup/audit_workgroup"
            ],
            "Sid": "AllowAthenaQuery"
        },
        {
            "Action": [
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:kms:eu-central-1:1234567890:key/kms_id",
            "Sid": "AllowAthenaKMSUsage"
        }
    ]
}

Dynamo에서 Athena 감사 로그 백엔드로 마이그레이션#
Tip
마이그레이션은 감사 로그에 Amazon DynamoDB를 사용했고 이전 데이터를 유지하려는 경우에만 필요합니다.

마이그레이션은 다음 단계로 구성됩니다:

Athena 인프라 설정
DynamoDB와 Athena 모두에 이중 쓰기하고, DynamoDB에서 쿼리
DynamoDB에서 Athena로 이전 데이터 마이그레이션
DynamoDB와 Athena 모두에 이중 쓰기하고, Athena에서 쿼리
DynamoDB 쓰기 비활성화

Teleport storage 구성에서 audit_events_uri는 여러 URL을 허용합니다. 이 URL들은 서로 다른 감사 로거에 대한 연결을 구성하는 데 사용됩니다. 2개 이상 사용하면 이벤트가 각 감사 시스템에 기록되고 첫 번째 시스템에서 쿼리가 실행됩니다.
Tip
마이그레이션 단계 1-4 중에 문제가 발생하면, Amazon DynamoDB URL이 audit_events_uri 필드의 첫 번째 값인지 확인하고 Athena URL을 제거하여 Amazon DynamoDB 솔루션으로 롤백하십시오.

이러한 각 단계는 아래에 자세히 설명되어 있습니다.
DynamoDB와 Athena 모두에 이중 쓰기하고, DynamoDB에서 쿼리#
마이그레이션의 두 번째 단계에서는 다음 구성 설정이 필요합니다:
teleport:
  storage:
    audit_events_uri:
    - 'dynamodb://events_table_name'
    - 'athena://db.table?otherQueryParams'

Auth Service 인스턴스가 재시작되면 locationS3 매개변수를 사용하여 지정된 S3 버킷에 Parquet 파일이 저장되는지 확인해야 합니다.
DynamoDB에서 Athena로 이전 데이터 마이그레이션#
이 단계에서는 클라이언트 머신을 사용하여 Amazon DynamoDB에서 데이터를 내보내고 Athena 로거에 게시합니다. Amazon DynamoDB의 테이블 크기보다 최소 2배 큰 디스크 크기를 가진 EC2 인스턴스를 사용하는 것을 권장합니다.
마이그레이션 도구 사용 지침은 GitHub에서 찾을 수 있습니다.
exportTime을 이중 쓰기가 시작된 시간으로 설정해야 합니다.
내보낸 데이터를 검증하므로 -dry-run 플래그로 첫 번째 마이그레이션을 실행하는 것을 권장합니다. 오류가 보고되지 않으면 -dry-run 플래그 없이 실제 마이그레이션을 진행하십시오.
DynamoDB와 Athena 모두에 이중 쓰기하고, Athena에서 쿼리#
Teleport 구성 파일의 audit_events_uri 값의 순서를 변경하십시오:
teleport:
  storage:
    audit_events_uri:
    - 'athena://db.table?otherQueryParams'
    - 'dynamodb://events_table_name'

Auth Service가 재시작되면 감사 로그 페이지에서 이벤트가 보이는지 확인해야 합니다.
DynamoDB 쓰기 비활성화#
DynamoDB 쓰기를 비활성화하면 데이터 손실 없이 DynamoDB로 롤백할 수 없습니다. Athena와 DynamoDB 모두에 이중 쓰기를 하는 것은 성능에 큰 영향을 미치지 않으며, 시스템이 이미 Athena에서 쿼리를 실행하더라도 일정 시간 동안 이중 쓰기를 유지하는 것을 권장합니다.
DynamoDB 쓰기를 비활성화하려면 audit_events_uri 배열에서 DynamoDB URL을 제거하십시오.
GCS#
Google Cloud Storage (GCS)는 녹화된 세션의 스토리지로 사용할 수 있습니다. GCS는 감사 로그나 클러스터 상태를 저장할 수 없습니다. 다음은 Teleport Auth Service가 녹화된 세션을 GCS 버킷에 저장하도록 구성하는 방법의 예시입니다.
teleport:
  storage:
      # 녹화된 세션을 저장할 GCS 경로.
      audit_sessions_uri: 'gs://$BUCKET_NAME/records?projectID=$PROJECT_ID&credentialsPath=$CREDENTIALS_PATH'

클러스터 성능과 고가용성을 보장하기 위해 Standard 스토리지 클래스로 Dual-Region 모드에서 버킷을 생성하는 것을 권장합니다.
위 예시의 다음 변수를 자체 값으로 교체하십시오:


$BUCKET_NAME을 원하는 GCS 버킷의 이름으로 교체합니다. 버킷이 없으면 생성됩니다.
지정된 버킷에 다음 권한이 부여되었는지 확인하십시오:

storage.buckets.get
storage.objects.create
storage.objects.get
storage.objects.list
storage.objects.update
storage.objects.delete

최종 blob으로 조립된 후 멀티파트 파일을 정리하려면 storage.objects.delete가 필요합니다.
버킷이 없는 경우 storage.buckets.create 권한도 부여되어 있는지 확인하십시오.


$PROJECT_ID를 GCS가 활성화된 GCP 프로젝트로 교체합니다.


$CREDENTIALS_PATH를 프로젝트에 적용 가능한 서비스 계정으로 구성된 JSON 형식 GCP 자격 증명 파일의 경로로 교체합니다.


Firestore#
GCP에서 Teleport를 실행하는 경우, 고가용성을 달성하기 위해 Firestore를 스토리지 백엔드로 사용할 수 있습니다. Firestore 백엔드는 두 가지 유형의 Teleport 데이터를 지원합니다:

클러스터 상태
감사 로그 이벤트

Firestore는 녹화된 세션을 저장할 수 없습니다. 위에 표시된 것처럼 Google Cloud Storage (GCS)를 사용하는 것을 권장합니다. Firestore를 사용하도록 Teleport를 구성하려면:

아래와 같이 teleport.yaml의 "storage" 섹션에서 Firestore 백엔드를 사용하도록 모든 Teleport Auth 서버를 구성하십시오.
Firestore 스토리지 백엔드에 연결된 여러 auth 서버를 배포하십시오.
여러 proxy 노드를 배포하십시오.
모든 Teleport 리소스 서비스가 클러스터의 Auth Service 인스턴스 주소로 auth_servers 구성 설정이 채워져 있거나 고가용성 모드에서 Auth Service 인스턴스의 로드 밸런서를 사용하는지 확인하십시오.

teleport:
  storage:
    type: firestore
    # 프로젝트 ID https://support.google.com/googleapi/answer/7014113?hl=en
    project_id: Example_GCP_Project_Name

    # Firestore 테이블 이름.
    collection_name: Example_TELEPORT_FIRESTORE_TABLE_NAME

    # 사용할 선택적 데이터베이스 ID. 제공되지 않으면 프로젝트의
    # 기본 데이터베이스가 사용됩니다.
    database_id: Example_TELEPORT_FIRESTORE_DATABASE_ID

    credentials_path: /var/lib/teleport/gcs_creds

    # 이 설정은 Teleport가 감사 이벤트를 세 곳으로 보내도록 구성합니다:
    # Firestore에 복사본을 유지하고, 로컬 파일 시스템에 복사본을 유지하고, 이벤트를 stdout으로 출력합니다.
    # 참고: Firestore 이벤트 테이블은 일반 Teleport 데이터베이스 테이블과 다른 스키마를 가지고 있으므로,
    # 동일한 테이블을 양쪽에 사용하려고 하면 오류가 발생합니다.
    # Firestore와 같이 고가용성 스토리지를 사용할 때, 목록은 항상 고가용성 스토리지 방법을 먼저 지정해야 합니다.
    # 이것이 Teleport 웹 UI가 표시할 이벤트의 소스로 사용하는 것이기 때문입니다.
    audit_events_uri:  ['firestore://Example_TELEPORT_FIRESTORE_EVENTS_TABLE_NAME?projectID=$PROJECT_ID&credentialsPath=$CREDENTIALS_PATH&databaseID=$DATABASE_ID', 'file:///var/lib/teleport/audit/events', 'stdout://']

    # 이 설정은 Teleport가 녹화된 세션을 GCP 스토리지에 저장하도록 구성합니다:
    audit_sessions_uri: gs://Example_TELEPORT_GCS_BUCKET/records


Example_GCP_Project_Name 및 Example_TELEPORT_FIRESTORE_TABLE_NAME을 자체 설정으로 교체하십시오. Teleport가 테이블을 자동으로 생성합니다.
Example_TELEPORT_FIRESTORE_TABLE_NAME과 Example_TELEPORT_FIRESTORE_EVENTS_TABLE_NAME은 반드시 다른 Firestore 테이블이어야 합니다. 각각의 스키마가 다릅니다. 동일한 테이블 이름을 양쪽에 사용하면 오류가 발생합니다.
위의 GCP 인증 설정은 머신 자체가 Firestore 테이블에 접근할 수 있는 서비스 계정이 있는 GCE 인스턴스에서 실행되는 경우 생략할 수 있습니다.
위의 감사 로그 설정은 선택 사항입니다. 지정된 경우 Teleport는 Firestore에 감사 로그를 저장하며 세션 녹화는 반드시 GCS 버킷에 저장해야 합니다. 즉, audit_xxx 설정이 모두 존재해야 합니다. 설정되지 않으면 Teleport는 감사 로그에 로컬 파일 시스템을 기본값으로 사용합니다. 즉, Auth Service 인스턴스에서 /var/lib/teleport/log입니다.

Azure Blob Storage#
세션 스토리지를 위한 Azure Blob Storage는 Teleport 13.3부터 사용 가능합니다.
Azure Blob Storage는 녹화된 세션의 스토리지로 사용할 수 있습니다. Azure Blob Storage는 감사 로그나 클러스터 상태를 저장할 수 없습니다. 다음은 Teleport Auth Service 인스턴스가 Azure Blob Storage 스토리지 계정에 녹화된 세션을 저장하도록 구성하는 방법의 예시입니다.
teleport:
  storage:
    audit_sessions_uri: azblob://account-name.blob.core.windows.net

Teleport는 계정의 두 컨테이너를 사용합니다. 이름은 기본적으로 inprogress 및 session이지만 URI 단편의 매개변수로 구성할 수 있습니다.
teleport:
  storage:
    audit_sessions_uri: azblob://account-name.core.blob.windows.net#session_container=session_container_name&inprogress_container=inprogress_container_name

권한#
Teleport는 inprogress 컨테이너에 다음 권한이 필요합니다:

Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete (inprogress 컨테이너에만 해당)

또한 Teleport는 시작 시 컨테이너가 존재하는지 확인하며, 존재 여부를 확인할 수 없는 경우 생성을 시도합니다. Teleport에 Microsoft.Storage/storageAccounts/blobServices/containers/read를 부여하면 확인이 가능하고, Microsoft.Storage/storageAccounts/blobServices/containers/write를 부여하면 생성이 가능합니다.
일정 기간 동안 녹화가 변경 불가능한 상태로 유지된 후 삭제될 수 있도록 session 컨테이너에 시간 기반 보존 정책과 수명 주기 관리 정책을 설정하는 것을 강력히 권장합니다. Teleport는 녹화를 자동으로 삭제하지 않습니다.
시간 기반 보존 정책이 있으면 Teleport에 사용자 지정 역할을 정의하지 않고 컨테이너로 범위가 지정된 "Blob Storage Data Contributor" 역할을 안전하게 부여할 수 있습니다.
인증#
Teleport는 환경 변수, Microsoft Entra Workload ID 자격 증명, 또는 관리 ID 자격 증명으로 지정된 Microsoft Entra ID 자격 증명을 활용합니다.
SQLite#
Auth Service는 Teleport 구성 파일의 storage 섹션에 type이 지정되지 않거나 type이 sqlite 또는 dir로 설정된 경우 SQLite 백엔드를 사용합니다. SQLite 백엔드는 높은 처리량을 위해 설계되지 않았으며 Teleport의 고가용성 구성의 요구를 충족할 수 없습니다.
SQLite를 백엔드로 사용하려는 경우 클러스터를 천천히 확장하고 Auth Service 로그에서 SLOW TRANSACTION이라는 경고 메시지 수를 모니터링하십시오. 이는 클러스터가 SQLite 백엔드의 기능을 초과했다는 신호입니다.
클러스터를 HA 가능 백엔드를 사용하도록 마이그레이션하기 전까지 임시 방편으로, SQLite 백엔드를 구성하여 시스템 충돌이나 전원 손실에 대한 탄력성을 희생하는 대신 디스크 동기화 양을 줄일 수 있습니다. 옵션의 의미에 대한 설명은 공식 SQLite 문서를 참조하십시오. 어떤 구성이든 클러스터 상태를 정기적으로 백업하는 것을 권장합니다.
디스크 동기화를 줄이려면:
teleport:
  storage:
    type: sqlite
    sync: NORMAL

디스크 동기화를 완전히 비활성화하려면:
teleport:
  storage:
    type: sqlite
    sync: "OFF"

파일 잠금을 지원하는 파일 시스템 (즉, 네트워크 파일 시스템이 아닌 로컬 파일 시스템)에서 실행하는 경우, 신뢰성을 희생하지 않고 상당히 향상된 성능을 위해 SQLite 데이터베이스를 Write-Ahead Logging을 사용하도록 구성할 수 있습니다 (WAL 모드에 대한 공식 문서 참조):
teleport:
  storage:
    type: sqlite
    sync: NORMAL
    journal: WAL

SQLite 백엔드 및 기타 필요한 데이터는 Teleport 데이터 디렉터리에 기록됩니다.
기본적으로 Teleport의 데이터 디렉터리는 /var/lib/teleport입니다. 위치를 수정하려면 Teleport 구성 파일 내에서 data_dir 값을 설정하십시오.
teleport:
  data_dir: /var/lib/teleport_data

CockroachDB#
Enterprise
CockroachDB 스토리지 백엔드를 사용하려면 Teleport Enterprise가 필요합니다.

Teleport는 고가용성을 달성하고 리전 장애에서 살아남기 위해 CockroachDB를 스토리지 백엔드로 사용할 수 있습니다. Teleport 키 및 사용자 레코드와 같은 비밀이 저장되는 곳이므로 이 구성에서 CockroachDB에 대한 접근을 보호하기 위한 조치를 취해야 합니다.
최소한 CockroachDB가 Teleport가 테이블을 생성할 수 있도록 구성해야 합니다. Teleport는 권한이 주어지면 데이터베이스를 생성하지만, 데이터베이스가 이미 존재하는 경우에는 필요하지 않습니다.
CREATE DATABASE database_name;
CREATE USER database_user;
GRANT CREATE ON DATABASE database_name TO database_user;

또한 CockroachDB의 클러스터 설정에서 변경 피드를 활성화해야 합니다. SYSTEM MODIFYCLUSTERSETTING이 부여된 경우 Teleport가 이 설정을 자체적으로 구성합니다.
SET CLUSTER SETTING kv.rangefeed.enabled = true;

CockroachDB를 배포하고 구성하는 몇 가지 방법이 있으며, 세부 사항은 이 가이드의 범위에 포함되지 않습니다. CockroachDB 배포에 대한 자세한 내용은 CockroachDB 배포 옵션을 참조하십시오. 다중 리전 생존 목표를 구성하는 방법에 대한 자세한 내용은 다중 리전 생존 목표를 참조하십시오.
CockroachDB를 스토리지 백엔드로 사용하도록 Teleport를 구성하려면:

아래와 같이 teleport.yaml의 storage 섹션에서 CockroachDB 백엔드를 사용하도록 모든 Teleport Auth Service 인스턴스를 구성하십시오.
CockroachDB 스토리지 백엔드에 연결된 여러 Auth Service 인스턴스를 배포하십시오.
여러 Proxy Service 인스턴스를 배포하십시오.
Proxy Service 인스턴스와 직접 Auth Service에 연결하는 모든 Teleport 에이전트 서비스가 Auth Service 인스턴스의 로드 밸런서 주소로 auth_server 구성 설정이 채워져 있는지 확인하십시오.

teleport:
  storage:
    type: cockroachdb

    # conn_string은 필수 매개변수입니다. PostgreSQL 와이어 프로토콜을 사용하여
    # CockroachDB에 연결하는 데 사용되는 PostgreSQL 연결 문자열입니다. 클라이언트
    # 매개변수는 URL을 사용하여 지정할 수 있습니다. 사용 가능한 매개변수의 자세한 목록은
    # https://www.cockroachlabs.com/docs/v25.3/connection-parameters.html을 참조하십시오
    #
    # 인증서가 기본 ~/.postgresql 위치에 저장되어 있지 않은 경우,
    # sslcert, sslkey, sslrootcert 매개변수로 지정해야 합니다.
    #
    # pool_max_conns는 클러스터 상태 데이터베이스에 사용되는 연결 풀의
    # 최대 연결 수를 결정하는 추가 매개변수입니다 (변경 피드는
    # 추가 연결을 사용함). 기본값은 사용 가능한 CPU 수에 따라 다릅니다.
    conn_string: postgresql://user_name@database-address/teleport_backend?sslmode=verify-full&pool_max_conns=20

    # change_feed_conn_string은 선택적 매개변수입니다. 지정되지 않으면 Teleport는
    # conn_string에 지정된 동일한 값을 기본값으로 사용합니다. 변경 피드 연결을
    # 설정할 때 다른 사용자 또는 연결 매개변수를 사용하도록 Teleport를 구성하는 데 사용할 수 있습니다.
    #
    # 인증서가 기본 ~/.postgresql 위치에 저장되어 있지 않은 경우,
    # sslcert, sslkey, sslrootcert 매개변수로 지정해야 합니다.
    change_feed_conn_string: postgresql://user_name@database-address/teleport_backend?sslmode=verify-full

    # ttl_job_cron은 CockroachDB가 유효 기간에 따라 백엔드 항목을 만료시키는 간격을
    # 구성하는 선택적 매개변수입니다. 기본적으로 20분마다 실행되도록 구성됩니다.
    # Teleport가 더 이상 연결하지 않거나 필요하지 않은 오래된 리소스를 정리하는 데 사용됩니다.
    # 이것을 더 자주 실행하도록 구성하면 CockroachDB에 성능 영향이 있을 수 있습니다.
    ttl_job_cron: '*/20 * * * *'