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

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

클러스터 상태

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

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

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

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

Auth 서비스 상태

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

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

로드 밸런서를 Layer 4(TCP) 로드 밸런싱, 라운드 로빈 로드 밸런싱, 300초 유휴 타임아웃을 사용하도록 구성합니다.

프록시 서비스 상태

Teleport 프록시는 상태가 없기 때문에 여러 인스턴스를 실행하는 것이 간단합니다.

기본 구성을 사용하는 경우, 로드 밸런서를 구성하여 포트 3080 을 Teleport 프록시 서비스가 실행 중인 서버로 전달합니다. 프록시 서비스가 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를 스토리지 백엔드로 사용하여 고가용성 배포를 구현할 수 있습니다. Teleport 비밀(키 및 사용자 기록 등)이 저장될 위치인 etcd 에 대한 접근을 보호하기 위해 조치를 취해야 합니다.

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에서 제공한 스크립트
    # https://github.com/etcd-io/etcd/tree/master/hack/tls-setup 을 사용하십시오.
    tls_cert_file: /var/lib/teleport/etcd-cert.pem
    tls_key_file: /var/lib/teleport/etcd-key.pem

    # etcd 노드를 인증하는 신뢰할 수 있는 CA 권한이 있는 선택적 파일
    #
    # 위의 스크립트를 사용하여 클라이언트 TLS 인증서를 생성한 경우,
    # 이 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 오버헤드 바이트)를 증가시키는 데 사용됩니다.
    # 이 값이 `--max-request-bytes` 로 지정된 etcd 서버의 값을 초과하지 않는지 확인하십시오.
    # 두 값을 동기화 상태로 유지하십시오.
    #
    # 자세한 내용은 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 논리적 디코딩 플러그인이 필요합니다. 이 플러그인은 PostgreSQL Apt 및
Yum 저장소에서 모든 안정적인 버전의 패키지로 사용할 수 있으며, 저장소에 제공된 지침을 따라 컴파일할 수 있습니다.
이 플러그드는 Azure Database for
PostgreSQL에서 추가적인 조치 없이 사전 설치되어 있습니다.

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

클러스터 상태를 위한 PostgreSQL 백엔드는 데이터베이스에서 변경 사항 스트림을 가져오기 위해 논리적 디코딩을 사용할 수 있어야 하며,
따라서 wal_level 매개변수를 logical 로 설정해야 하고,
max_replication_slots 또한 실행할 Teleport Auth Service 인스턴스 수만큼 이상으로 설정해야 합니다 (네트워크 조건을 고려하여 더 높은 숫자가 권장됩니다).

Teleport Auth Service는 PostgreSQL 클러스터에 대한 새로운 연결을 재설립할 때 및 시작 시 복제 슬롯을 생성할 수 있어야 하며,
장기 실행 중인 트랜잭션은 이를 방해할 수 있습니다. 따라서, Teleport 클러스터 상태를 공유 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 전용인 경우에만 사용해야 합니다.

PostgreSQL 사용을 위해 Teleport를 구성하려면:

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

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에 사용합니다. 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 호환 연결 문자열이지만 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 파일에서 구성하는 것이 좋습니다.

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" (프라이빗 서비스 연결)
    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에 연결된 서비스 계정 자격 증명을 사용합니다.

PostgreSQL 연결 문자열에 사용된 서비스 계정이 기본 자격 증명의 서비스 계정과 다른 경우, Teleport는 기본 자격 증명을 사용하여 연결 문자열에 사용된 서비스 계정을 서비스 계정 토큰 작성자로 가장합니다.

개발

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

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

#!/bin/bash

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

# CA 키 및 self-signed 인증서 생성.
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

컨테이너 시작 시 Teleport 사용자가 생성되도록 하는 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 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다.
• Teleport Auth Service 를 Kubernetes에서 실행 중인 경우, IAM Roles for Service Accounts (IRSA)를 사용할 수 있습니다.
• 그렇지 않은 경우, 환경 변수를 사용해야 합니다.

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 - 사용할 아마존 지역을 설정합니다.

• 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로 설정된 경우, 모든 객체가 이 키로 암호화됩니다 (단, disablesse 가 false 인 경우). 자세한 내용은 아래에서 확인할 수 있습니다.

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

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

S3 IAM 정책

시작 시, Teleport 인증 서비스(Auth Service)는 세션 기록 저장소로 설정된 S3 버킷이 존재하는지 확인합니다. 만약 해당 버킷이 존재하지 않는 경우, 인증 서비스는 버킷을 생성하고 구성하려고 시도합니다.

인증 서비스가 세션 기록 버킷을 관리하기 위해 필요한 IAM 권한은 사용자가 직접 버킷을 생성할 것인지, 아니면 인증 서비스가 버킷을 생성하고 구성하도록 허용할 것인지에 따라 달라집니다.

{
    "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 매개변수는 대칭 표준 사양 KMS 키에 해당하는 유효한 KMS CMK ID로 설정할 수 있습니다.
일반적인 사용 사례를 위한 예제 템플릿 KMS 키 정책이 아래에 제공됩니다. IAM 사용자는 기본적으로 어떤 키에도 액세스할 수 없습니다.
권한은 정책에서 명시적으로 부여해야 합니다.

암호화/복호화

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

[iam-key-admin-arn]을 관리 키 액세스 권한을 가져야 하는 사용자(s)의 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]을 관리 키 액세스 권한을 가져야 하는 사용자(s)의 IAM 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": "[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 로 설정합니다 (관리 콘솔의 Permissions에서).
• audit_sessions_uri 에 acl=bucket-owner-full-control 을 추가합니다.

소유권 전송을 강제하려면 B 의 버킷 정책을 설정하여 bucket-owner-full-control 캔드 ACL을 포함한 업로드만 허용해야 합니다.

{
  "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 Documentation을 참조하십시오.

DynamoDB

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

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

Teleport는 DynamoDB 및 DynamoDB Streams 엔드포인트를 사용하여 스토리지 백엔드 관리를 합니다.

DynamoDB는 녹화된 세션을 저장할 수 없습니다. 이를 위해 AWS S3를 사용하는 것이 좋습니다, 위에 설명된 대로.

AWS에 대한 인증

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

the Teleport Auth Service 가 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여하십시오.

• the Teleport Auth Service 를 EC2 인스턴스에서 실행 중인 경우, EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다.
• the Teleport Auth Service 를 Kubernetes에서 실행 중인 경우, IAM Roles for Service Accounts (IRSA)를 사용할 수 있습니다.
• 그렇지 않은 경우, 환경 변수를 사용해야 합니다.

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Teleport Auth 서비스가 인증하는 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:

{  
    "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 스토리지 백엔드에 연결된 Auth 서버를 최대 두 대 배포합니다.
• 여러 프록시 노드를 배포합니다.
• 모든 Teleport 리소스 서비스에 auth_servers 구성 설정이 클러스터의 Auth 서비스 인스턴스 주소로 채워져 있는지 확인합니다.

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으로 출력합니다.
    # NOTE: DynamoDB 이벤트 테이블은 일반 Teleport 데이터베이스 테이블과 다른 스키마를 가지므로, 두 테이블에 대해 동일한 테이블을 사용하려고 시도하면 오류가 발생합니다.
    # DynamoDB와 같은 고가용성 스토리지를 사용할 때는 목록이 항상 가장 먼저 고가용성 스토리지 방법을 지정하는지 확인해야 합니다.
    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 서비스 인스턴스에서 감사 로그를 위한 로컬 파일 시스템으로 기본값을 설정합니다, 즉 /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 온디맨드

최고의 성능을 위해 Provisioed 모드로 용량을 수동으로 구성하는 대신 온디맨드 모드를 사용하는 것이 좋습니다. 이는 낮은 사용량 추정이나 증가된 사용량으로 인해 Teleport에 영향을 주는 DynamoDB 조절을 방지하는 데 도움이 됩니다.

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

AWS FIPS 엔드포인트 구성

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

use_fips_endpoint 를 true 또는 false 로 설정합니다. true 일 경우, FIPS Dynamo 엔드포인트가 사용됩니다.
false 일 경우, 일반 Dynamo 엔드포인트가 사용됩니다. 설정되지 않은 경우, AWS 환경 변수 AWS_USE_FIPS_ENDPOINT 가 사용되는 엔드포인트를 결정합니다.
--fips 플래그와 함께 Teleport가 실행되면 FIPS 엔드포인트도 사용됩니다.

구성 옵션 우선순위는 다음과 같은 순서로 적용됩니다.

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

아테나

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

AWS에서 Teleport를 실행하는 경우, 높은 가용성을 달성하기 위해 S3에 저장된 Parquet 파일을 관리하는 Athena 기반 감사 로그 시스템을 사용할 수 있습니다. Athena 백엔드는 오직 하나의 Teleport 데이터 유형, 즉 감사 이벤트만 지원합니다.

Athena 감사 백엔드는 DynamoDB보다 규모와 검색에서 더 나은 성능을 제공합니다.

Athena 감사 로그는 최종 일관성을 유지합니다. Teleport 웹 UI에서 이벤트를 볼 수 있기까지 최대 1분이 걸릴 수 있습니다(이는 batchMaxInterval 설정 및 이벤트 부하에 따라 다릅니다).

인프라 설정

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

다음 Terraform 스크립트를 사용하여 Athena 백엔드를 지원하는 데 필요한 인프라를 설정할 수 있습니다:

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://"

다음은 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 호스트네임은 Glue 데이터베이스와 Athena 감사 로거에서 사용할 테이블을 가리키는 database.table 로 구성됩니다.

기타 매개변수는 Athena URL 내의 쿼리 매개변수로 지정됩니다.

다음 매개변수는 필수입니다:

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

AWS 인증

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

Teleport Auth 서비스 가 AWS에 인증하는 데 사용할 수 있는 자격 증명에 대한 액세스를 부여하십시오.

• Teleport Auth 서비스 를 EC2 인스턴스에서 실행 중인 경우, EC2 인스턴스 메타데이터 서비스 방법을 사용할 수 있습니다.
• Teleport Auth 서비스 를 Kubernetes에서 실행 중인 경우, IAM Roles for Service Accounts (IRSA)를 사용할 수 있습니다.
• 그렇지 않은 경우, 환경 변수를 사용해야 합니다.

AWS_ACCESS_KEY_ID=00000000000000000000
AWS_SECRET_ACCESS_KEY=0000000000000000000000000000000000000000
AWS_DEFAULT_REGION=<YOUR_REGION>

Teleport Auth 서비스가 인증할 IAM 역할은 다음 섹션에 지정된 정책을 가지고 있어야 합니다.

IAM 정책

Teleport에 할당된 IAM 역할이 Athena에 대해 충분한 액세스 권한으로 구성되어 있는지 확인하십시오. 아래에는 Auth 서비스가 감사 이벤트 백엔드로 사용하기 위해 요구하는 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"
    }
  ]
}

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

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

1. Athena 인프라 설정
2. DynamoDB와 Athena 모두에 이중 작성하고 DynamoDB에서 쿼리하기
3. DynamoDB에서 Athena로 이전 데이터 마이그레이션
4. DynamoDB와 Athena 모두에 이중 작성하고 Athena에서 쿼리하기
5. DynamoDB에 대한 기록 비활성화

Teleport 저장소 구성에서 audit_events_uri 는 여러 개의 URL을 허용합니다. 이러한 URL은 다양한 감사 로그 시스템에 대한 연결을 구성하는 데 사용됩니다. 1개 이상의 URL이 사용되면 이벤트는 각 감사 시스템에 기록되며, 쿼리는 첫 번째 시스템에서 실행됩니다.

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

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"

클러스터 성능과 고가용성을 보장하기 위해 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 는 최종 블롭으로 조립된 멀티파트 파일을 정리하는 데 필요합니다.

  버킷이 존재하지 않을 경우, 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 Auth 서버를 아래와 같이 teleport.yaml 의 "storage" 섹션에서 Firestore 백엔드를 사용하도록 구성합니다.
• Firestore 스토리지 백엔드에 연결된 여러 Auth 서버를 배포합니다.
• 여러 프록시 노드를 배포합니다.
• 모든 Teleport 리소스 서비스가 클러스터의 Auth 서비스 인스턴스 주소로 채워진 auth_servers 구성 설정을 가지고 있는지 확인하거나 고가용성 모드에서 Auth 서비스 인스턴스에 대한 로드 밸런서를 사용하세요.

teleport:
  storage:
    type: firestore
    # Project 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는 인증 서비스 인스턴스에서 감사 로그를 위해 로컬 파일 시스템(예: /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 데이터베이스를 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

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의 클러스터 설정에서 변경 피드를 활성화해야 합니다. Teleport는 SYSTEM MODIFYCLUSTERSETTING 권한이 부여되면 이 설정을 스스로 구성합니다.

SET CLUSTER SETTING kv.rangefeed.enabled = true;

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

CockroachDB를 저장소 백엔드로 사용하도록 Teleport를 구성하려면:

• 아래에 표시된 대로 teleport.yaml 의 storage 섹션에서 모든 Teleport Auth Service 인스턴스를 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는 클러스터 상태 데이터베이스에 사용되는 연결 풀에서 최대
    # 연결 수를 결정하는 추가 매개변수입니다(변경 피드는 추가 연결을 사용합니다). 기본값은
    # 사용 가능한 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 * * * *"