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

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

클러스터 상태

클러스터 상태는 Auth Service에 의해 구성된 중앙 저장 위치에 저장됩니다. 클러스터 상태에는 다음이 포함됩니다:

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

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

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

인증 서비스 상태

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

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

로드 밸런서를 Layer 4(TCP) 로드 밸런싱, 라운드 로빈 로드 밸런싱 및 300초의 유휴 시간 초과를 사용하도록 구성합니다.

프록시 서비스 상태

Teleport 프록시는 상태가 없으므로 여러 인스턴스를 실행하는 것이 간단합니다.

기본 구성을 사용하는 경우, 로드 밸런서를 구성하여 포트 3080을 Teleport Proxy Service를 실행하는 서버로 전달하도록 설정하십시오. 프록시 서비스가 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

/readyz 엔드포인트는 Teleport 서비스가 문제 없이 실행되고 있는 경우 {"status":"ok"}를 응답합니다. 이 엔드포인트는 로드 밸런서의 상태 검사가 성공하도록 프록시 인터페이스에 노출되어야 합니다. 이는 프록시 인스턴스에서만 수행하고 포트 3000은 공용 인터넷에 노출되지 않도록 해야 합니다. 다른 서비스의 경우 127.0.0.1 로컬 루프백 인터페이스를 계속 사용하십시오.

우리는 아래에서 Teleport를 매우 가용하게 만들기 위해 etcd, PostgreSQL, DynamoDB 및 Firestore 스토리지 백엔드를 사용하는 방법을 설명할 것입니다.

Etcd

Teleport는 etcd를 스토리지 백엔드로 사용할 수 있어 고가용성 배포를 달성할 수 있습니다. 이 구성에서 etcd에 대한 접근을 보호하기 위해 조치를 취해야 합니다. Teleport 비밀(예: 키 및 사용자 기록)이 저장되는 위치이기 때문입니다.

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

• etcd 버전 3.3 이상을 사용하고 있는지 확인합니다.
• etcd의 클러스터 하드웨어 권장 사항을 따르십시오. 특히 최상의 성능을 위해 SSD 또는 고성능 가상화 블록 장치 스토리지를 활용하십시오.
• etcd 설치 후 etcd 보안 가이드를 사용하여 피어 및 클라이언트 TLS 인증을 구성하십시오.
  • TLS 설정이 없을 경우 etcd가 제공하는 이 스크립트를 사용할 수 있습니다.
• 아래와 같이 구성 파일의 "storage" 섹션에서 모든 Teleport Auth Service 인스턴스가 etcd를 사용하도록 구성하십시오.
• etcd 백엔드에 연결된 여러 Auth Service 인스턴스를 배포하십시오.
• Auth Service에 연결하기 위해 auth_server가 가리키는 Proxy Service 인스턴스를 여러 개 배포하십시오.

teleport:
  storage:
     type: etcd

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

     # etcd에 연결하는 데 필요한 TLS 클라이언트 인증서 및 키 파일의 경로.
     #
     # 이를 생성하려면
     # https://coreos.com/os/docs/latest/generate-self-signed-certificates.html
     # 를 따르거나 etcd가 제공하는 스크립트를 사용하십시오.
     tls_cert_file: /var/lib/teleport/etcd-cert.pem
     tls_key_file: /var/lib/teleport/etcd-key.pem

     # etcd 노드를 인증하기 위한 신뢰할 수 있는 CA 인증서 파일 (선택적).
     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 오버헤드 바이트)를 초과하는 값을 설정할 수 있습니다.
     # 두 개의 값을 동기화하시기 바랍니다.
     #
     # 상세 정보는 https://etcd.io/docs/v3.4.0/dev-guide/limit/ 참조하십시오.
     #
     # 예시로 크기를 15MiB로 설정합니다.
     etcd_max_client_msg_size_bytes: 15728640

PostgreSQL

PostgreSQL 클러스터 상태 및 감사 로그 저장은 Teleport 13.3부터 사용할 수 있습니다.

Teleport는 고가용성을 달성하기 위해 PostgreSQL를 스토리지 백엔드로 사용할 수 있습니다. 이 구성에서 PostgreSQL 접근을 보호하기 위해 조치를 취해야 합니다. Teleport 비밀(예: 키 및 사용자 기록)이 저장되는 위치이기 때문입니다. PostgreSQL 백엔드는 두 가지 유형의 Teleport 데이터를 지원합니다:

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

PostgreSQL 백엔드는 PostgreSQL 13 이상과 클러스터 상태의 경우에만 wal2json 논리 디코딩 플러그인이 필요합니다. 이 플러그인은 Debian 및 RPM 기반 리눅스 배포를 위한 PostgreSQL Apt 및 Yum 리포지토리의 모든 안정화 버전 패키지에서 사용할 수 있거나 지침을 따라 컴파일할 수 있습니다. Azure Database for PostgreSQL에서는 플러그인이 별도의 작업 없이 사전 설치되어 있습니다.

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

PostgreSQL 백엔드는 데이터베이스에서 변경 사항의 스트림을 얻기 위해 논리 디코딩 기능을 사용해야 하며, 이로 인해 wal_level 매개변수는 논리로 설정되어야 하고, max_replication_slots 매개변수는 실행하는 Teleport Auth Service 인스턴스 수 만큼 또는 그 이상으로 설정해야 합니다(네트워크 조건을 고려).

Teleport Auth Service는 PostgreSQL 클러스터에 연결할 때 복제 슬롯을 생성해야 하며, 장기 실행 거래는 이를 방해할 것입니다. 따라서 다른 클러스터 작업이 단기 거래로만 구성된 경우에만 클러스터 상태를 공유 PostgreSQL 클러스터에 저장하는 것이 좋습니다.

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는 관리 서비스(예: Azure Database for PostgreSQL)가 API를 통해 슈퍼유저 계정을 생성할 수 있도록 하는 경우를 수용하기 위해 initiating replication 역할 속성을 자신에게 부여하려고 시도합니다. 이는 PostgreSQL 클러스터가 Teleport 전용일 경우에만 활용해야 합니다.

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

• 모든 Teleport Auth Service 인스턴스가 teleport.yaml의 storage 섹션에서 PostgreSQL 백엔드를 사용하도록 구성하십시오.
• 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는 이에 대해
    # change_feed_conn_string의 연결 문자열을 사용합니다. Teleport 13.4 이상에서 사용할 수 있습니다.
    change_feed_conn_string: postgresql://replication_user_name@database-address/teleport_backend?sslmode=verify-full

    # audit_events_uri가 postgresql:// 스킴을 사용하면 PostgreSQL 백엔드를 
    # 감사 로그 저장에 사용할 것입니다. URI는 클러스터 상태 conn_string과 일치하는 libpq 호환 연결 문자열입니다.
    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

인증

우리는 PostgreSQL에 Teleport를 인증하기 위해 클라이언트 인증서를 사용하는 것을 강력히 추천하며, TLS 사용을 강제하고 서버 인증서 검증을 클라이언트 측에서 진행해야 합니다.

pg_hba.conf 파일을 업데이트하여 Teleport 연결이 클라이언트 인증서를 사용하도록 다음 줄을 추가해야 합니다. 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 파일에 비밀번호를 구성하는 것을 권장합니다.

Azure AD 인증

Azure에서 Teleport를 실행하는 경우 Teleport는 Azure AD 인증을 활용하여 Azure Database for PostgreSQL 서버에 비밀 관리 없이 연결할 수 있습니다:

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는 데이터베이스 비밀번호로 사용될 자격 증명을 자동으로 가져옵니다. 데이터베이스 사용자는 Azure AD를 통해 연결을 허용하도록 구성되어야 합니다.

Teleport는 환경 변수, Azure AD 작업 부하 신원 자격 증명 또는 관리되는 신원 자격 증명을 사용합니다.

Google Cloud IAM 인증

Google Cloud에서 Teleport를 실행하는 경우 Teleport는 IAM 인증을 활용하여 GCP Cloud SQL for PostgreSQL에 비밀 관리 없이 연결할 수 있습니다:

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

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

    # Cloud SQL 인스턴스에 연결하는 데 사용할 IP 주소 유형입니다. 유효한 옵션은:
    # - "" (기본적으로 "public"으로 설정)
    # - "public"
    # - "private"
    # - "psc" (Private Service Connect용)
    gcp_ip_type: public

    # 호스트와 포트는 필요하지 않으므로 비워두십시오.
    conn_string: postgresql://service-account@project.iam@/teleport_backend

    audit_events_uri:
      - postgresql://service-account@project.iam@/teleport_audit#auth_mode=gcp-cloudsql&gcp_connection_name=project:location:instance&gcp_ip_type=public

Cloud SQL에 대한 IAM 인증 및 논리 복제를 활성화하려면 Cloud SQL 인스턴스에 대해 cloudsql.iam_authentication 및 cloudsql.logical_decoding 플래그를 on으로 설정해야 합니다. 데이터베이스 사용자는 논리 디코딩 기능을 사용하기 위해 REPLICATION 역할 속성을 가져야 합니다. 자세한 내용은 논리 복제 및 디코딩 설정을 참조하십시오.

Teleport가 IAM 인증을 사용하여 Cloud SQL Go 연결자를 사용할 수 있도록 하려면 대상 데이터베이스 사용자에 대한 서비스 계정의 서비스 계정이 "Cloud SQL Client"/roles/cloudsql.client 및 "Cloud SQL Instance User"/roles/cloudsql.instanceUser 역할을 할당받아야 합니다.

Teleport는 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 통해, 작업 부하 신원 연합 자격 증명 또는 VM에 첨부된 서비스 계정 자격 증명을 사용합니다.

연결 문자열에서 사용되는 서비스 계정과 기본 자격 증명의 서비스 계정이 다른 경우, Teleport는 기본 자격 증명을 사용하여 Service Account Token Creator 역할로 연결 문자열에서 사용한 서비스 계정을 가장하게 됩니다.

개발

프로덕션 인스턴스의 PostgreSQL에 연결할 준비가 되지 않았다면 Docker를 사용하여 PostgreSQL의 임시 인스턴스를 설정하는 다음 지침을 사용할 수 있습니다.

먼저 다음 스크립트를 디스크에 복사하고 실행하여 Teleport와 PostgreSQL이 안전하게 상호 인증된 연결을 설정하는 데 사용되는 CA, 클라이언트 인증서 및 서버 인증서를 생성합니다:

#!/bin/bash

# certs 디렉토리 생성.
mkdir -p ./certs
cd certs/

# CA 키 및 자체 서명된 인증서 생성.
openssl genpkey -algorithm RSA -out ca.key
openssl req -x509 -new -key ca.key -out ca.crt -subj "/CN=root"

# 인증서를 생성하는 함수.
create_certificate() {
    local name="$1"
    local dns_name="$2"

    openssl genpkey \
        -algorithm RSA \
        -out "${name}.key"
    openssl req -new \
        -key "${name}.key" \
        -out "${name}.csr" \
        -subj "/CN=${dns_name}"
    openssl x509 -req \
        -in "${name}.csr" \
        -CA ca.crt \
        -CAkey ca.key \
        -out "${name}.crt" \
        -extfile <(printf "subjectAltName=DNS:${dns_name}") \
        -CAcreateserial

    chmod 0600 "${name}.key"
}

# SAN이 있는 클라이언트 인증서 생성.
create_certificate "client" "teleport"

# SAN이 있는 서버 인증서 생성.
create_certificate "server" "localhost"

echo "인증서 및 키가 성공적으로 생성되었습니다."

다음으로, 공식 PostgreSQL Docker 이미지를 사용하여 Dockerfile을 생성하고 그 안에 wal2json을 추가합니다:

FROM postgres:15.0
RUN apt-get update
RUN apt-get install -y postgresql-15-wal2json

Telemetry 사용자를 초기화할 수 있도록 Docker 컨테이너 시작 시 생성될 init.sql 파일을 생성합니다:

CREATE USER teleport WITH REPLICATION CREATEDB;

PostgreSQL에 대한 연결을 강제하기 위해 인증서 기반 인증을 위한 pg_hba.conf 파일을 생성합니다:

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

WAL 수준과 인증에 사용될 인증서를 구성하는 postgresql.conf 파일을 생성합니다:

listen_addresses = '*'
port = 5432
max_connections = 20
shared_buffers = 128MB
temp_buffers = 8MB
work_mem = 4MB

wal_level=logical
max_replication_slots=10

ssl=on
ssl_ca_file='/certs/ca.crt'
ssl_cert_file='/certs/server.crt'
ssl_key_file='/certs/server.key'

다음 명령어로 PostgreSQL 컨테이너를 시작합니다:

docker run --rm --name postgres \
    -e POSTGRES_DB=db \
    -e POSTGRES_USER=user \
    -e POSTGRES_PASSWORD=password \
    -v $(pwd)/data:/var/lib/postgresql/data \
    -v $(pwd)/certs:/certs \
    -v $(pwd)/postgresql.conf:/etc/postgresql/postgresql.conf \
    -v $(pwd)/pg_hba.conf:/etc/postgresql/pg_hba.conf \
    -v $(pwd)/init.sql:/docker-entrypoint-initdb.d/init.sql \
    -p 5432:5432 \
    $(docker build -q .) \
    postgres \
    -c hba_file=/etc/postgresql/pg_hba.conf \
    -c config_file=/etc/postgresql/postgresql.conf

마지막으로, teleport.yaml에서 PostgreSQL 연결을 사용하도록 스토리지 섹션을 업데이트하고 Teleport를 시작합니다:

teleport:
  storage:
    type: postgresql
    conn_string: "postgresql://teleport@localhost:5432/teleport_backend?sslcert=/path/to/certs/client.crt&sslkey=/path/to/certs/client.key&sslrootcert=/path/to/certs/ca.crt&sslmode=verify-full&pool_max_conns=20"

S3(세션 녹화)

Teleport는 S3를 세션 녹화와 감사 로그의 백엔드로 사용할 수 있습니다. S3는 클러스터 상태 백엔드로 사용할 수 없습니다. 이 섹션에서는 세션 녹화 백엔드로 S3를 사용하는 방법을 다룹니다. 감사 로그에 S3를 사용하는 방법에 대해서는 Athena 섹션을 참조하십시오.

S3 버킷에는 버전 관리가 활성화되어 있어야 합니다. 이는 세션 로그가 영구적으로 변경되거나 삭제될 수 없도록 보장합니다. Teleport는 항상 녹화의 가장 오래된 버전을 보고합니다.

AWS에 대한 인증

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

Teleport Auth Service에 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여합니다.

Teleport Auth Service를 EC2 인스턴스에서 실행하는 경우 EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다. 그렇지 않은 경우 환경 변수를 사용해야 합니다:

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

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는 이 값을 확인합니다.

  이 값이 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 - 사용해야 할 미리 설정된 ACL을 설정합니다. 미리 정의된 ACL 값 중 하나여야 합니다.

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

S3 IAM 정책

Teleport Auth Service가 시작될 때, 세션 기록 저장소에 대해 구성된 S3 버킷이
존재하는지 확인합니다. 존재하지 않으면, Auth Service는 버킷을 생성하고
구성하려고 시도합니다.

Auth Service가 세션 기록 버킷을 관리하는 데 필요한 IAM 권한은
직접 버킷을 생성할 것인지, 아니면 Auth Service가 생성하고
구성하도록 활성화할 것인지에 따라 다릅니다:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BucketActions",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucketVersions",
                "s3:ListBucketMultipartUploads",
                "s3:ListBucket",
                "s3:GetEncryptionConfiguration",
                "s3:GetBucketVersioning"
            ],
            "Resource": "arn:aws:s3:::your-sessions-bucket"
        },
        {
            "Sid": "ObjectActions",
            "Effect": "Allow",
            "Action": [
                "s3:GetObjectVersion",
                "s3:GetObjectRetention",
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::your-sessions-bucket/*"
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "BucketActions",
            "Effect": "Allow",
            "Action": [
                "s3:PutEncryptionConfiguration",
                "s3:PutBucketVersioning",
                "s3:ListBucketVersions",
                "s3:ListBucketMultipartUploads",
                "s3:ListBucket",
                "s3:GetEncryptionConfiguration",
                "s3:GetBucketVersioning",
                "s3:CreateBucket"
            ],
            "Resource": "arn:aws:s3:::your-sessions-bucket"
        },
        {
            "Sid": "ObjectActions",
            "Effect": "Allow",
            "Action": [
                "s3:GetObjectVersion",
                "s3:GetObjectRetention",
                "s3:*Object",
                "s3:ListMultipartUploadParts",
                "s3:AbortMultipartUpload"
            ],
            "Resource": "arn:aws:s3:::your-sessions-bucket/*"
        }
    ]
}

S3 서버 측 암호화

Teleport는 S3에 업로드된 객체를 암호화하기 위해 사용자 지정 AWS KMS 고객 관리 키를 사용할 수 있습니다. 이를 통해 클러스터 인증자가 세션 녹화와 같은 객체를 읽을 수 있는 권한을 제한할 수 있습니다.

위의 sse_kms_key 매개변수는 모든 객체가 이 키로 암호화되도록 설정할 수 있습니다(단, disablesse가 false입니다). 일반적으로 사용 사례에 대한 KMS 키 정책의 예는 아래와 같이 제공됩니다. IAM 사용자는 기본적으로 키에 대한 접근 권한이 없습니다. 권한은 정책에 명시적으로 부여해야 합니다.

암호화/복호화

이 정책은 IAM 사용자가 객체를 암호화하고 복호화할 수 있도록 허용합니다. 이는 클러스터 인증자가 세션 녹화를 작성하고 재생할 수 있도록 허용합니다.

[iam-key-admin-arn]을(를) 관리 키 접근 권한이 있어야하는 사용자 IAM ARN으로 교체하고, [auth-node-iam-arn]을(를) Teleport 인증 노드가 사용하는 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-node-write-arn]을(를) 주 쓰기 전용 클러스터의 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": "[iam-node-write-arn]"
      },
      "Action": [
        "kms:Encrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Teleport CMK Auth Decrypt",
      "Effect": "Allow",
      "Principal": {
        "AWS": "[iam-node-read-arn]"
      },
      "Action": [
        "kms:Decrypt",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

ACL 예제: 객체 소유권 전송

AWS 계정 A에서 AWS 계정 B가 소유한 버킷으로 업로드하고 객체 소유권을 A가 유지하기를 원한다면 두 가지 방법 중 하나를 선택할 수 있습니다.

ACL 없이

ACL이 비활성화된 경우 객체 소유권은 버킷 소유자 강제로 설정되며 추가 조치는 필요하지 않습니다.

ACL 사용

• 객체 소유권을 버킷 소유자 선호로 설정합니다(관리 콘솔의 권한 아래).
• audit_sessions_uri에 acl=bucket-owner-full-control을 추가합니다.

소유권 전송을 강제하려면, 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는 기록된 세션을 저장할 수 없습니다. 위에서 설명한 것처럼 S3를 사용해야 합니다.

AWS에 대한 인증

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

Teleport Auth Service에 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여합니다.

Teleport Auth Service를 EC2 인스턴스에서 실행하는 경우 EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다. 그렇지 않은 경우 환경 변수를 사용해야 합니다:

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Teleport가 인증하는 IAM 역할은 다음 섹션에서 지정된 정책을 갖춰야 합니다.

IAM 정책

Teleport에 할당된 IAM 역할이 DynamoDB에 충분한 접근 권한으로 구성되었는지 확인하십시오.

On startup, the Teleport Auth Service checks whether the DynamoDB table you have
지정한 구성 파일에 존재하는지 확인합니다. 테이블이 존재하지 않는 경우,
Auth Service는 새 테이블을 생성하려고 시도합니다.

Auth Service가 DynamoDB 테이블을 관리하기 위해 요구하는 IAM 권한은
테이블을 직접 생성할 예정인지 아니면 Auth Service가 당신을 대신하여
자동으로 생성하고 구성할 것인지에 따라 다릅니다:

{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Sid": "ClusterStateStorage",  
            "Effect": "Allow",  
            "Action": [  
                "dynamodb:BatchWriteItem",  
                "dynamodb:UpdateTimeToLive",  
                "dynamodb:PutItem",  
                "dynamodb:DeleteItem",  
                "dynamodb:Scan",  
                "dynamodb:Query",  
                "dynamodb:DescribeStream",  
                "dynamodb:UpdateItem",  
                "dynamodb:DescribeTimeToLive",  
                "dynamodb:DescribeTable",  
                "dynamodb:GetShardIterator",  
                "dynamodb:GetItem",  
                "dynamodb:ConditionCheckItem",  
                "dynamodb:UpdateTable",  
                "dynamodb:GetRecords",  
                "dynamodb:UpdateContinuousBackups"  
            ],  
            "Resource": [  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-backend",  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-backend/stream/*"  
            ]  
        },  
        {  
            "Sid": "ClusterEventsStorage",  
            "Effect": "Allow",  
            "Action": [  
                "dynamodb:BatchWriteItem",  
                "dynamodb:UpdateTimeToLive",  
                "dynamodb:PutItem",  
                "dynamodb:DescribeTable",  
                "dynamodb:DeleteItem",  
                "dynamodb:GetItem",  
                "dynamodb:Scan",  
                "dynamodb:Query",  
                "dynamodb:UpdateItem",  
                "dynamodb:DescribeTimeToLive",  
                "dynamodb:UpdateTable",  
                "dynamodb:UpdateContinuousBackups"  
            ],  
            "Resource": [  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-events",  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-events/index/*"  
            ]  
        }  
    ]  
}  

{  
    "Version": "2012-10-17",  
    "Statement": [  
        {  
            "Sid": "ClusterStateStorage",  
            "Effect": "Allow",  
            "Action": [  
                "dynamodb:BatchWriteItem",  
                "dynamodb:UpdateTimeToLive",  
                "dynamodb:PutItem",  
                "dynamodb:DeleteItem",  
                "dynamodb:Scan",  
                "dynamodb:Query",  
                "dynamodb:DescribeStream",  
                "dynamodb:UpdateItem",  
                "dynamodb:DescribeTimeToLive",  
                "dynamodb:CreateTable",  
                "dynamodb:DescribeTable",  
                "dynamodb:GetShardIterator",  
                "dynamodb:GetItem",  
                "dynamodb:ConditionCheckItem",  
                "dynamodb:UpdateTable",  
                "dynamodb:GetRecords",  
                "dynamodb:UpdateContinuousBackups"  
            ],  
            "Resource": [  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-backend",  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-backend/stream/*"  
            ]  
        },  
        {  
            "Sid": "ClusterEventsStorage",  
            "Effect": "Allow",  
            "Action": [  
                "dynamodb:CreateTable",  
                "dynamodb:BatchWriteItem",  
                "dynamodb:UpdateTimeToLive",  
                "dynamodb:PutItem",  
                "dynamodb:DescribeTable",  
                "dynamodb:DeleteItem",  
                "dynamodb:GetItem",  
                "dynamodb:Scan",  
                "dynamodb:Query",  
                "dynamodb:UpdateItem",  
                "dynamodb:DescribeTimeToLive",  
                "dynamodb:UpdateTable",  
                "dynamodb:UpdateContinuousBackups"  
            ],  
            "Resource": [  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-events",  
                "arn:aws:dynamodb:us-west-2:1234567890:table/teleport-helm-events/index/*"  
            ]  
        }  
    ]  
}  

DynamoDB 백엔드 구성

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

• 모든 Teleport Auth 서버가 teleport.yaml의 "storage" 섹션에서 DynamoDB 백엔드를 사용하도록 구성하십시오.
• Auth 서버는 DynamoDB 및 DynamoDB Streams 엔드포인트에 접근할 수 있어야 합니다.
• DynamoDB 스토리지 백엔드에 연결된 최대 두 개의 인증 서버를 배포하십시오.
• 여러 프록시 노드를 배포하십시오.
• 모든 Teleport 리소스 서비스가 클러스터의 Auth Service 인스턴스 주소로 설정된 auth_servers 구성 설정을 보유하고 있는지 확인하십시오.

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에 복사본을 보존하고, 로컬 파일 시스템에 복사본을 보존하며 표준 출력으로도 이벤트를 출력합니다.
    # 주의: 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는 AWS TTL을 1년으로 설정하여 감사 이벤트를 저장합니다.
    # 아래와 같이 이 값을 구성할 수 있습니다. 설정을 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 - AWS FIPS 엔드포인트 구성.

DynamoDB 연속 백업

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

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

DynamoDB 온디맨드

최고의 성능을 위해 Provisioned 모드로 용량을 수동으로 구성하는 것보다 온디맨드 모드를 사용하는 것이 좋습니다. 이렇게 하면 Teleport에 영향을 미치는 추정된 사용량의 증가나 증가된 사용량으로 인한 DynamoDB 초과 행위를 예방할 수 있습니다.

• AWS 문서 - Amazon DynamoDB 온디맨드 및 요청당 지불

AWS FIPS 엔드포인트 구성

이 구성 옵션은 Amazon S3 및 Amazon DynamoDB에 적용됩니다.

use_fips_endpoint를 true 또는 false로 설정하십시오. true인 경우 FIPS(https://aws.amazon.com/compliance/fips/) Dynamo 엔드포인트가 사용됩니다. false인 경우 일반 Dynamo 엔드포인트가 사용됩니다. 설정되지 않은 경우 AWS 환경 변수 AWS_USE_FIPS_ENDPOINT가 사용되는 엔드포인트를 결정합니다. FIPS 엔드포인트는 Teleport가 --fips 플래그로 실행되면 사용됩니다.

구성 옵션 우선 순위는 다음과 같습니다:

• 위에서 설명한대로 use_fips_endpoint 쿼리 매개변수 설정
• Teleport를 실행할 때 --fips 플래그 사용
• AWS 환경 변수 사용

Athena

Athena 감사 로그 백엔드는 Teleport v14.0부터 사용 가능합니다.

AWS에서 Teleport를 실행하는 경우, Athena 기반의 감사 로그 시스템을 사용할 수 있으며 관리하는 Parquet 파일을 S3에 저장하여 고가용성을 달성할 수 있습니다. Athena 백엔드는 Teleport 데이터 중 감사 이벤트만 지원합니다.

Athena 감사 로그는 스케일과 검색에서 DynamoDB보다 우수합니다.

Athena 감사 로그는 결국 일관성이 있습니다. Teleport 웹 UI에서 이벤트를 볼 수 있기까지 최대 1분(배치 최대 간격 설정 및 이벤트 로드에 따라 소요됨)이 걸릴 수 있습니다.

인프라 설정

Auth Service는 SNS 주제에 구독된 SQS 큐를 사용하여 이벤트를 게시합니다. 단일 Auth Service 인스턴스가 SQS에서 이벤트를 배치로 읽은 후 Parquet 형식으로 변환하고 결과 데이터를 S3에 보냅니다. 쿼리 중에 Athena 엔진은 S3에서 이벤트를 검색하고 Glue 테이블에서 메타데이터를 읽습니다.

Athena 백엔드를 지원하기 위해 필요한 인프라를 구성하려면 다음 Terraform 스크립트를 사용할 수 있습니다:

(!examples/athena/variables.tf!)
(!examples/athena/athena.tf!)

Athena 감사 로그 백엔드 구성

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

• Teleport 버전 14.0.0 이상을 사용하고 있는지 확인합니다.
• 인프라를 준비합니다.
• Teleport 구성 파일의 audit_events_uri 배열 내에 Athena URL을 지정합니다:

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

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 호스트 이름은 database.table로 구성되어 있으며 Glue 데이터베이스와 Athena 감사 로거에서 사용될 테이블을 가리킵니다.

다음은 필수 매개변수의 설명입니다:

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

AWS에 대한 인증

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

Teleport Auth Service에 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여합니다.

Teleport Auth Service를 EC2 인스턴스에서 실행하는 경우 EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다. 그렇지 않은 경우 환경 변수를 사용해야 합니다:

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Teleport Auth Service가 인증하는 IAM 역할은 Athena를 사용하기 위한 충분한 접근 권한을 가진 정책을 갖춰야 합니다. 아래에 Teleport Auth Service가 Athena 감사 로그를 감사 이벤트 백엔드로 사용할 수 있도록 해야 하는 IAM 권한이 필요합니다.

정책 예제에서 다음 값을 교체해야 합니다:

{
    "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"
        }
    ]
}

### DynamoDB에서 Athena 감사 로그 백엔드로의 마이그레이션

<Admonition
  type="tip"
  title="팁"
>
  마이그레이션은 Amazon DynamoDB를 감사 로그로 사용하고 오래된 데이터를 유지하려는 경우에만 필요합니다.
</Admonition>

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

1. Athena 인프라 설정
1. DynamoDB와 Athena에 동시에 쓰고, DynamoDB에서 쿼리하기
1. DynamoDB에서 Athena로 이전 데이터 마이그레이션
1. DynamoDB와 Athena에 동시에 쓰고, Athena에서 쿼리하기
1. DynamoDB로의 쓰기 비활성화

Teleport 저장소 구성에서 `audit_events_uri`는 여러
URL을 허용합니다. 이러한 URL은 다양한 감사 로거에 대한 연결 구성을 위해 사용됩니다. 1개 이상이 사용되는 경우, 이벤트는 각 감사 시스템에 기록되고, 쿼리는 첫 번째 시스템에서 실행됩니다.

<Admonition
  type="tip"
  title="팁"
>
  마이그레이션 단계 1-4 동안 문제가 발생하면 `audit_events_uri` 필드에서 URL이 첫 번째 값이도록 하여 Amazon DynamoDB 솔루션으로 롤백하고 Athena URL을 제거하세요.
</Admonition>

이 단계 각각에 대한 자세한 설명은 아래에 있습니다.

#### DynamoDB와 Athena에 동시에 쓰고, DynamoDB에서 쿼리하기

마이그레이션의 두 번째 단계에서는 다음 구성을 설정해야 합니다:

```yaml
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'

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

• $BUCKET_NAME : 원하는 GCS 버킷의 이름입니다. 버킷이 존재하지 않으면 생성됩니다. 주어진 버킷에 대해 다음 권한이 부여되었는지 확인하세요:

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

  storage.objects.delete는 멀티파트 파일을 최종 Blob으로 조립한 후 청소하는 데 필요합니다.

  만약 버킷이 존재하지 않으면, storage.buckets.create 권한도 부여되었는지 확인하세요.

• $PROJECT_ID : GCS 활성화된 GCP 프로젝트입니다.

• $CREDENTIALS_PATH : 프로젝트에 적용 가능한 서비스 계정의 JSON 형식 GCP 자격 증명 파일의 경로입니다.

Firestore

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

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

Firestore는 기록된 세션을 저장할 수 없습니다. 위에서 설명한 GCS를 사용할 것을 권장합니다. Teleport를 Firestore 사용으로 구성하려면:

• 모든 Teleport Auth 서버를 teleport.yaml의 "storage" 섹션에서 Firestore 백엔드 사용으로 구성하세요.
• Firestore 스토리지 백엔드에 연결된 여러 Auth 서버를 배포하세요.
• 여러 프록시 노드를 배포하세요.
• 모든 Teleport 리소스 서비스가 auth_servers 구성 설정을 사용하여 클러스터의 Auth Service 인스턴스의 주소로 채워지거나, 고가용성 모드의 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

    credentials_path: /var/lib/teleport/gcs_creds

    # 이 설정은 Teleport가 세 가지 장소로 감사 이벤트를 보내도록 구성합니다:
    # Firestore에 복사본을 보존하고, 로컬 파일 시스템에 복사본을 보존하며, stdout에 이벤트를 씁니다.
    # NOTE: Firestore 이벤트 테이블은 일반 Teleport 데이터베이스 테이블과 다른 스키마를 가지므로
    # 두 가지 모두에 대해 동일한 테이블을 사용하려고 하면 오류가 발생합니다.
    # Firestore와 같은 고가용성 스토리지를 사용할 때는 목록이 항상
    # 결과를 표시하기 위해 Teleport 웹 UI가 사용하는 소스의 첫 번째에서 고가용성 스토리지 방법을 지정해야 합니다.
    audit_events_uri:  ['firestore://Example_TELEPORT_FIRESTORE_EVENTS_TABLE_NAME', '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 인증 설정은 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는 감사 로그나 클러스터 상태를 저장할 수 없습니다. 아래는 Azure Blob Storage 스토리지 계정에 기록된 세션을 저장하기 위해 Teleport Auth Service 인스턴스를 구성하는 방법의 예입니다.

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는 환경 변수를 통한 Azure AD 자격 증명, Azure AD Workload Identity 자격 증명, 또는 관리된 ID 자격 증명을 사용합니다.

SQLite

Auth Service는 Teleport 구성 파일에서 저장소 섹션에 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 데이터베이스를 쓰기-앞 기록(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

Teleport는 CockroachDB를 스토리지 백엔드로 사용할 수 있으며, 고가용성을 달성하고 지역 실패를 견딜 수 있습니다. 이 구성에서는 Teleport 암호와 사용자 기록과 같은 비밀에 대한 접근을 보호하기 위해 조치를 취해야 합니다.

최소한 CockroachDB에서 Teleport가 테이블을 생성할 수 있도록 구성해야 합니다. Teleport는 권한을 부여받으면 데이터베이스를 자동으로 생성하지만, 데이터베이스가 이미 존재하는 경우 이는 필요하지 않습니다.

CREATE DATABASE database_name;
CREATE USER database_user;
GRANT CREATE ON DATABASE database_name TO database_user;

CockroachDB의 클러스터 설정에서 변경 피드를 활성화해야 합니다. Teleport는 SYSTEM MODIFYCLUSTERSETTING 권한을 부여받으면 이 설정을 스스로 구성합니다.

SET CLUSTER SETTING kv.rangefeed.enabled = true;

CockroachDB를 배포하고 구성하는 방법에는 여러 가지가 있으며, 이에 대한 세부사항은 이 가이드의 범위를 벗어납니다. CockroachDB를 배포하는 방법에 대해서는 CockroachDB의 배포 옵션을 참조하세요. 다지역 생존 목표를 구성하는 방법에 대해서는 다지역 생존 목표를 참조하세요.

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

• 모든 Teleport Auth Service 인스턴스를 teleport.yaml의 storage 섹션에서 CockroachDB 백엔드를 사용하도록 구성하세요.
• 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/stable/connection-parameter
    # 에서 확인할 수 있습니다.
    #
    # 인증서가 기본 ~/.postgresql 위치에 저장되어 있지 않은 경우,
    # sslcert, sslkey 및 sslrootcert 매개변수로 지정해야 합니다.
    #
    # pool_max_conns는 클러스터 상태 데이터베이스에 사용되는 연결 풀 내의 최대
    # 연결 수를 결정하는 추가 매개변수입니다 (변경 피드는 추가 연결을 사용함).
    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 * * * *'