Infograb logo
Elastic Stack으로 Teleport 감사 이벤트 내보내기

Teleport의 Event Handler 플러그인은 Teleport Auth 서비스에서 감사 이벤트를 수신하고 이를 로그 관리 솔루션으로 전달하여 역사적 분석을 수행하고, 비정상적인 행동을 탐지하며, 사용자가 Teleport 클러스터와 상호작용하는 방식에 대한 더 나은 이해를 형성할 수 있도록 합니다.

이 가이드에서는 Teleport의 Event Handler 플러그인을 구성하여 Teleport 감사 이벤트를 Elastic Stack으로 보내는 방법을 보여줍니다. 이 설정에서는 Event Handler 플러그인이 Teleport에서 Logstash로 감사 이벤트를 전달하고, Logstash는 이를 Elasticsearch에 저장하여 Kibana에서 시각화 및 알림을 수행합니다.

필수 사항

  • 실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.

  • tctl 관리 도구와 tsh 클라이언트 도구.

    tctltsh 다운로드에 대한 지침은 설치를 방문하세요.

권장 사항: 짧은 수명의 Teleport 자격 증명을 플러그인에 제공하기 위해 머신 ID를 구성하십시오. 이 가이드를 따르기 전에 tbot 바이너리를 귀하의 인프라에서 실행하기 위해 머신 ID 배포 가이드를 따르십시오.

  • Linux 호스트에서 실행 중인 Logstash 버전 8.4.1 이상. 이 가이드에서는 이 호스트에서 Event Handler 플러그인도 실행합니다.

  • Elastic Cloud 계정 또는 자체 인프라에서 실행 중인 Elasticsearch 및 Kibana 버전 8.4.1 이상. Elasticsearch에서 사용자 생성 및 관리 권한이 필요합니다.

    이 가이드는 Elastic Stack 버전 8.4.1에서 테스트되었습니다.

1단계/4. Event Handler 플러그인 설정

Event Handler 플러그인은 Teleport 클러스터와 독립적으로 실행되는 바이너리입니다. 이 플러그인은 상호 TLS를 사용하여 Teleport 클러스터와 Logstash에 인증합니다. 이 섹션에서는 Logstash를 실행 중인 Linux 호스트에 Event Handler 플러그인을 설치하고 플러그인이 인증에 사용할 자격 증명을 생성합니다.

Event Handler 플러그인 설치

환경에 따라 Logstash 호스트에 Event Handler 플러그인을 설치하는 지침을 따르십시오:

Event Handler 플러그인은 amd64arm64 바이너리로 제공됩니다. 필요한 버전으로 ARCH를 교체하세요.

curl -L -O https://cdn.teleport.dev/teleport-event-handler-v16.2.0-linux-ARCH-bin.tar.gz
tar -zxvf teleport-event-handler-v16.2.0-linux-ARCH-bin.tar.gz
sudo ./teleport-event-handler/install

Event Handler 플러그인은 amd64arm64 바이너리로 제공됩니다. 필요한 버전으로 ARCH를 교체하세요.

curl -L -O https://cdn.teleport.dev/teleport-event-handler-v16.2.0-darwin-ARCH-bin.tar.gz
tar -zxvf teleport-event-handler-v16.2.0-darwin-ARCH-bin.tar.gz
sudo ./teleport-event-handler/install

Docker가 설치되고 실행 중인지를 확인하세요.

docker pull public.ecr.aws/gravitational/teleport-plugin-event-handler:16.2.0

Helm이 Teleport Helm 리포지토리에 호스팅되는 차트를 설치할 수 있도록 하려면 helm repo add를 사용하세요:

helm repo add teleport https://charts.releases.teleport.dev

원격 리포지토리의 차트 캐시를 업데이트하려면 helm repo update를 실행하세요:

helm repo update

Go >= 1.22가 설치되어 있어야 합니다.

Universal Forwarder 호스트에서 다음 명령을 실행하세요:

git clone https://github.com/gravitational/teleport.git --depth 1 -b branch/v16
cd teleport/integrations/event-handler
make build

결과 실행 파일의 이름은 event-handler입니다. 이 가이드를 따르려면 이 파일의 이름을 teleport-event-handler로 변경하고 /usr/local/bin으로 이동하세요.

시작 구성 파일 생성

Teleport Event Handler 플러그인을 위한 자리 표시자 값이 포함된 구성 파일을 생성합니다. 이 가이드의 후반부에서 환경에 맞는 구성 파일을 편집할 것입니다.

configure 명령어를 실행하여 샘플 구성을 생성합니다. mytenant.teleport.sh를 Teleport Enterprise Cloud 테넌트의 DNS 이름으로 교체합니다:

teleport-event-handler configure . mytenant.teleport.sh:443

configure 명령어를 실행하여 샘플 구성을 생성합니다. teleport.example.com:443을 Teleport의 프록시 서비스의 DNS 이름과 HTTPS 포트로 교체합니다:

teleport-event-handler configure . teleport.example.com:443

configure 명령어를 실행하여 샘플 구성을 생성합니다. TELEPORT_CLUSTER_ADDRESS를 Teleport 인증 서비스 또는 프록시 서비스의 DNS 이름과 포트로 할당합니다:

TELEPORT_CLUSTER_ADDRESS=mytenant.teleport.sh:443
docker run -v `pwd`:/opt/teleport-plugin -w /opt/teleport-plugin public.ecr.aws/gravitational/teleport-plugin-event-handler:16.2.0 configure . ${TELEPORT_CLUSTER_ADDRESS?}

감사를 내보내기 위해서는 루트 인증서와 클라이언트 자격 증명이 비밀로 제공되어야 합니다. 다음 명령어를 사용하여 Kubernetes에서 해당 비밀을 생성하세요:

kubectl create secret generic teleport-event-handler-client-tls --from-file=ca.crt=ca.crt,client.crt=client.crt,client.key=client.key

이것은 ca.crt, client.crt, 및 client.key의 내용을 비밀로 패킹하여 Helm 차트가 적절한 경로에 쉽게 장착할 수 있도록 합니다.

configure 명령어를 실행하여 샘플 구성을 생성합니다:

docker run -v `pwd`:/opt/teleport-plugin -w /opt/teleport-plugin public.ecr.aws/gravitational/teleport-plugin-event-handler:16.2.0 configure .

다음 출력을 볼 수 있습니다:

Teleport event handler 16.2.0

[1] mTLS Fluentd 인증서가 생성되어 ca.crt, ca.key, server.crt, server.key, client.crt, client.key에 저장되었습니다.
[2] 샘플 teleport-event-handler 역할 및 사용자 파일 teleport-event-handler-role.yaml이 생성되었습니다.
[3] 샘플 fluentd 구성 파일 fluent.conf가 생성되었습니다.
[4] 플러그인 구성 파일 teleport-event-handler.toml이 생성되었습니다.

플러그인은 여러 설정 파일을 생성합니다:

ls -l

-rw------- 1 bob bob 1038 Jul 1 11:14 ca.crt

-rw------- 1 bob bob 1679 Jul 1 11:14 ca.key

-rw------- 1 bob bob 1042 Jul 1 11:14 client.crt

-rw------- 1 bob bob 1679 Jul 1 11:14 client.key

-rw------- 1 bob bob 541 Jul 1 11:14 fluent.conf

-rw------- 1 bob bob 1078 Jul 1 11:14 server.crt

-rw------- 1 bob bob 1766 Jul 1 11:14 server.key

-rw------- 1 bob bob 260 Jul 1 11:14 teleport-event-handler-role.yaml

-rw------- 1 bob bob 343 Jul 1 11:14 teleport-event-handler.toml

파일목적
ca.crtca.keyFluentd를 위한 자체 서명된 CA 인증서 및 개인 키
server.crtserver.keyFluentd 서버 인증서 및 키
client.crtclient.keyFluentd 클라이언트 인증서 및 키, 모두 생성된 CA에 의해 서명됨
teleport-event-handler-role.yamlTeleport의 이벤트 핸들러를 위한 사용자역할 자원 정의
fluent.confFluentd 플러그인 구성

이 가이드는 이벤트 핸들러가 로그 포워더와 동일한 호스트 또는 Kubernetes 포드에서 실행되고 있다고 가정합니다. 만약 그렇지 않다면, 이벤트 핸들러가 localhost 이외의 주체를 위한 mTLS 인증서를 생성하도록 지시해야 합니다. 이를 위해 teleport-event-handler 구성 명령의 --cn--dns-names 플래그를 사용하십시오.

예를 들어, 로그 포워더가 forwarder.example.com에서 접근 가능하고 이벤트 핸들러가 handler.example.com일 경우, 다음 configure 명령어를 실행하면 됩니다:

teleport-event-handler configure --cn=handler.example.com --dns-names=forwarder.example.com

이 명령어는 주체가 --cn의 값으로 설정된 클라이언트 및 서버 인증서를 생성합니다.

--dns-names 플래그는 쉼표로 구분된 DNS 이름 목록을 허용합니다. 목록의 각 DNS 이름에 대해 서버 인증서(로그 포워더에 제공할 인증서)의 주체 대체 이름(SAN)을 추가합니다. 이벤트 핸들러는 각 DNS 이름을 조회하여 SAN 추가 전에 확인하고, 조회 실패 시 오류와 함께 종료합니다.

우리는 Logstash 구성에서 Fluentd를 위해 생성된 파일을 재사용할 것입니다.

RBAC 리소스 정의

teleport-event-handler configure 명령어는 teleport-event-handler-role.yaml이라는 파일을 생성했습니다. 이 파일은 teleport-event-handler 역할과 event API에 대한 읽기 전용 접근 권한을 가진 사용자를 정의합니다:

kind: role
metadata:
  name: teleport-event-handler
spec:
  allow:
    rules:
      - resources: ['event', 'session']
        verbs: ['list','read']
version: v5
---
kind: user
metadata:
  name: teleport-event-handler
spec:
  roles: ['teleport-event-handler']
version: v2

이 파일을 작업 공간으로 이동시키거나 (위의 스니펫을 붙여넣어) 재생성하고, 작업 공간에서 tctl을 사용하여 역할과 사용자를 생성하세요:

tctl create -f teleport-event-handler-role.yaml

사용자 "teleport-event-handler"가 생성되었습니다

역할 'teleport-event-handler'가 생성되었습니다

Elastic Stack 호스트에서 Teleport를 실행 중인 경우 예를 들어 Kibana의 HTTP 엔드포인트를 Teleport Application Service를 통해 노출하고 있는 경우, 위의 tctl create 명령을 실행하면 다음과 유사한 오류가 발생합니다:

ERROR: tctl must be either used on the auth server or provided with the identity file via --identity flag

이 오류를 피하려면, 워크스테이션에 teleport-event-handler-role.yaml 파일을 생성한 후 Teleport 클러스터에 로그인하여 로컬에서 tctl 명령을 실행하십시오.

Event Handler 역할에 대한 자격 증명 발급 활성화

역할이 생성되었으므로 이제 Machine ID 봇이 이 역할에 대한 자격 증명을 생성할 수 있도록 허용해야 합니다.

이는 tctl로 수행할 수 있으며, my-bot을 당신의 봇 이름으로 교체합니다:

tctl bots update my-bot --add-roles teleport-event-handler

이벤트 핸들러 플러그인이 Teleport 클러스터에서 이벤트를 전달하기 위해서는 클러스터의 인증 기관에서 서명된 자격 증명이 필요합니다.
teleport-event-handler 사용자는 스스로 이러한 자격 증명을 요청할 수 없으며, 자격 증명을 요청하기 위해 다른 사용자가 이 계정을 임시로 사용해야 합니다.

teleport-event-handler 사용자를 임시로 사용할 수 있는 역할을 생성하십시오. 먼저, 아래의 YAML 문서를 teleport-event-handler-impersonator.yaml이라는 파일에 붙여넣습니다:

kind: role
version: v5
metadata:
  name: teleport-event-handler-impersonator
spec:
  options:
    # max_session_ttl은 이 역할을 가진 사용자에게 발급된 SSH 인증서의 TTL(유효 기간)을 정의합니다.
    max_session_ttl: 10h

  # 이 섹션은 이 역할의 사용자에게 허용되는 리소스/동작 조합 목록을 선언합니다.
  # 기본적으로 아무것도 허용되지 않습니다.
  allow:
    impersonate:
      users: ["teleport-event-handler"]
      roles: ["teleport-event-handler"]

다음으로, 역할을 생성하십시오:

tctl create teleport-event-handler-impersonator.yaml

이 역할을 이벤트 핸들러에 대한 서명된 자격 증명을 생성하는 사용자에게 추가하십시오:

teleport-event-handler-impersonator 역할을 Teleport 사용자에게 할당하려면 인증 제공자에 맞는 적절한 명령어를 실행하세요:

  1. 로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:

    ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
  2. 로컬 사용자를 편집하여 새로운 역할을 추가합니다:

    tctl users update $(tsh status -f json | jq -r '.active.username') \ --set-roles "${ROLES?},teleport-event-handler-impersonator"
  3. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. github 인증 커넥터를 가져옵니다:

    tctl get github/github --with-secrets > github.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.

  2. github.yaml을 편집하고 teams_to_roles 섹션에 teleport-event-handler-impersonator을 추가합니다.

    이 역할에 매핑할 팀은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 하지만 팀에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 팀이어야 합니다.

    여기에 예시가 있습니다:

      teams_to_roles:
        - organization: octocats
          team: admins
          roles:
            - access
    +       - teleport-event-handler-impersonator
    
  3. 변경 사항을 적용합니다:

    tctl create -f github.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

  1. saml 구성 리소스를 가져옵니다:

    tctl get --with-secrets saml/mysaml > saml.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.

  2. saml.yaml을 편집하고 attributes_to_roles 섹션에 teleport-event-handler-impersonator을 추가합니다.

    이 역할에 매핑할 속성은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      attributes_to_roles:
        - name: "groups"
          value: "my-group"
          roles:
            - access
    +       - teleport-event-handler-impersonator
    
  3. 변경 사항을 적용합니다:

    tctl create -f saml.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

  1. oidc 구성 리소스를 가져옵니다:

    tctl get oidc/myoidc --with-secrets > oidc.yaml

    --with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.

  2. oidc.yaml을 편집하고 claims_to_roles 섹션에 teleport-event-handler-impersonator을 추가합니다.

    이 역할에 매핑할 클레임은 귀하의 조직에서 어떻게 역할 기반 접근 제어(RBAC)를 설계했느냐에 따라 달라집니다. 그러나 그룹에는 귀하의 사용자 계정이 포함되어야 하며, 조직 내에서 가능한 한 작은 그룹이어야 합니다.

    여기에 예시가 있습니다:

      claims_to_roles:
        - name: "groups"
          value: "my-group"
          roles:
            - access
    +       - teleport-event-handler-impersonator
    
  3. 변경 사항을 적용합니다:

    tctl create -f oidc.yaml
  4. Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

액세스 플러그인 신원 내보내기

플러그인에 Teleport 신원 파일에 대한 액세스를 부여합니다. 더 짧은 생명 주기로 가장 위험도가 낮은 Machine ID를 사용하는 것이 좋습니다. 그러나 데모 배포에서는 tctl을 사용하여 더 긴 생명 주기의 신원 파일을 생성할 수 있습니다:

tbot을 구성하여 the plugin에 필요한 자격증명을 생성하는 출력을 만듭니다. the plugin가 Teleport API에 접근할 것이므로, 올바른 출력 유형은 identity입니다.

이 가이드에서는 directory 대상을 사용합니다. 이를 통해 자격증명이 디스크의 지정된 디렉토리에 기록됩니다. 이 디렉토리는 tbot이 실행되는 리눅스 사용자가 쓸 수 있고, the plugin가 실행될 리눅스 사용자가 읽을 수 있어야 합니다.

tbot 구성을 수정하여 identity 출력을 추가하세요.

리눅스 서버에서 tbot을 실행하는 경우, /opt/machine-id 디렉토리에 자격증명 파일을 쓰기 위해 directory 출력을 사용하세요:

outputs:
- type: identity
  destination:
    type: directory
    # 이 가이드에서는 /opt/machine-id를 목적지 디렉토리로 사용합니다.
    # 필요에 따라 사용자 정의할 수 있습니다. 여러 출력은 동일한
    # 대상을 공유할 수 없습니다.
    path: /opt/machine-id

Kubernetes에서 tbot을 실행하는 경우, 대신 Kubernetes 비밀에 자격증명 파일을 기록하세요:

outputs:
  - type: identity
    destination:
      type: kubernetes_secret
      name: teleport-event-handler-identity

tbot을 백그라운드 서비스로 운영하는 경우, 이를 재시작하세요. tbot을 원샷 모드로 실행하는 경우 지금 실행하세요.

이제 /opt/machine-id 아래에 identity 파일이 보이거나 teleport-event-handler-identity이라는 이름의 Kubernetes 비밀이 보일 것입니다. 이는 the plugin가 Teleport Auth Service와 인증하는 데 필요한 개인 키와 서명된 인증서를 포함하고 있습니다.

모든 Teleport 사용자와 마찬가지로, teleport-event-handler는 Teleport 클러스터에 연결하기 위해 서명된 자격 증명이 필요합니다. 이러한 자격 증명을 요청하기 위해 tctl auth sign 명령을 사용합니다.

다음의 tctl auth sign 명령은 teleport-event-handler 사용자로 가장하고, 서명된 자격 증명을 생성하며, 로컬 디렉토리에 ID 파일을 작성합니다:

tctl auth sign --user=teleport-event-handler --out=identity

plugin는 TLS를 통해 Teleport Auth Service의 gRPC 엔드포인트에 연결합니다.

ID 파일인 identity는 TLS 및 SSH 자격 증명을 포함합니다. plugin는 SSH 자격 증명을 사용하여 Proxy Service에 연결하고, 이 Proxy Service는 Auth Service에 대한 리버스 터널 연결을 설정합니다. plugin는 이 리버스 터널과 TLS 자격 증명을 사용하여 Auth Service의 gRPC 엔드포인트에 연결합니다.

기본적으로, tctl auth sign은 비교적 짧은 수명의 인증서를 생성합니다. 프로덕션 배포의 경우, Machine ID를 사용하여 플러그인에 대해 인증서를 프로그램matically Issuing과 Renew하는 것을 권장합니다. 우리의 Machine ID 시작 가이드를 참조하여 자세히 알아보세요.

기존 자격 증명보다 유효 기간이 긴 인증서를 발급할 수 없습니다. 예를 들어, 1000시간의 TTL을 가진 인증서를 발급하려면 최소한 1000시간 동안 유효한 세션으로 로그인해야 합니다. 즉, 사용자는 최소 1000시간(60000분)의 max_session_ttl을 허용하는 역할을 가지고 있어야 하며, 로그인할 때 --ttl을 지정해야 합니다:

tsh login --proxy=teleport.example.com --ttl=60060

Linux 서버에서 plugin를 실행하는 경우, plugin를 위한 인증서 파일을 보관할 데이터 디렉토리를 만드세요:

sudo mkdir -p /var/lib/teleport/api-credentials
sudo mv identity /var/lib/teleport/plugins/api-credentials

Kubernetes에서 plugin를 실행하는 경우, Teleport ID 파일을 포함하는 Kubernetes 비밀을 생성하세요:

kubectl -n teleport create secret generic --from-file=identity teleport-event-handler-identity

Teleport 자격 증명이 만료되면, 다시 tctl auth sign 명령을 실행하여 갱신해야 합니다.

2단계/4. Logstash 파이프라인 구성

Event Handler 플러그인은 Teleport로부터 감사 로그를 사용자가 구성한 엔드포인트에 HTTP 요청을 보내어 전달합니다. 이러한 요청을 처리하고 로그를 추출하여 Elasticsearch로 전송하는 Logstash 파이프라인을 정의합니다.

Event Handler 플러그인을 위한 역할 생성

Logstash 파이프라인은 Elasticsearch 인덱스와 인덱스 생애 주기 관리 정책을 생성하고 관리할 수 있는 권한이 필요합니다. 또한 Elasticsearch 배포에 대한 정보를 가져올 수 있어야 합니다. 이러한 권한을 가진 역할을 생성하여 나중에 Event Handler를 위한 Elasticsearch 사용자에게 할당할 수 있도록 합니다.

Kibana에서 "관리" > "역할"로 이동하여 "역할 생성"을 클릭합니다. 새 역할에 대한 이름으로 teleport-plugin을 입력합니다. "Elasticsearch" 섹션 아래에서 "클러스터 권한"에서 manage_index_templates, manage_ilm, 및 monitor를 입력합니다.

"인덱스 권한" 아래에서 "인덱스" 필드에 audit-events-*를 입력하고 "특권" 필드에 write, 및 manage를 입력합니다. "역할 생성"을 클릭합니다.

Event Handler를 위한 Elasticsearch 사용자 생성

Logstash가 Elasticsearch API에 요청할 때 인증할 수 있는 Elasticsearch 사용자를 생성합니다.

Kibana에서 왼쪽 상단의 햄버거 메뉴를 찾아 "관리"를 클릭한 다음 "사용자" > "사용자 생성"을 클릭합니다. "사용자 이름"에 teleport를 입력하고 안전한 비밀번호를 제공합니다.

이 사용자에게 앞서 정의한 teleport-plugin 역할을 할당합니다.

Logstash에 대한 TLS 자격 증명 준비

이 가이드의 후반부에서 Logstash 파이프라인은 감사 이벤트를 Teleport Event Handler 플러그인으로부터 수신하기 위해 HTTP 입력을 사용합니다.

Logstash의 HTTP 입력은 복호화되지 않은 PKCS #8 형식을 사용하는 개인 키로만 인증서를 서명할 수 있습니다. 위에서 teleport-event-handler configure를 실행했을 때, 그 명령은 암호화된 RSA 키를 생성했습니다. 이 키를 PKCS #8로 변환합니다.

RSA 키를 복호화하려면 비밀번호가 필요합니다. 이를 가져오기 위해, teleport-event-handler configure를 실행한 디렉토리에서 다음 명령을 실행하십시오:

cat fluent.conf | grep passphrase
private_key_passphrase "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff"

암호화된 RSA 키를 복호화되지 않은 PKCS #8 키로 변환합니다. 명령은 당신이 얻은 비밀번호를 입력하라고 요청합니다:

openssl pkcs8 -topk8 -in server.key -nocrypt -out pkcs8.key

새 키, 그리고 우리가 이전에 생성한 CA 및 인증서를 Logstash가 읽을 수 있도록 설정합니다:

chmod +r pkcs8.key ca.crt server.crt

인덱스 템플릿 정의

Event Handler 플러그인이 Logstash에 감사 이벤트를 보낼 때, Logstash는 이러한 이벤트를 어떻게 파싱할 것인지 알아야 합니다. 이 논리를 정의하기 위해 인덱스 템플릿을 만들 수 있으며, Elasticsearch는 수신한 데이터를 위해 인덱스를 구성하는 데 이를 사용합니다.

audit-events.json이라는 파일을 생성하고 다음 내용을 포함시킵니다:

{
  "index_patterns": ["audit-events-*"],
  "template": {
    "settings": {},
    "mappings": {
      "dynamic":"true"
    }
  }
}

이 인덱스 템플릿은 audit-events-* 패턴을 가진 모든 인덱스를 수정합니다. "dynamic": "true" 설정을 포함하고 있기 때문에, Elasticsearch에 수신하는 이벤트에 따라 인덱스 필드를 동적으로 정의하도록 지시합니다. 이는 이벤트 유형에 따라 다양한 필드를 사용하는 Teleport 감사 이벤트에 유용합니다.

Logstash 파이프라인 정의

Logstash를 실행 중인 호스트에서 Logstash 파이프라인을 정의하는 구성 파일을 생성합니다. 이 파이프라인은 포트 9601에서 로그를 수신하고 이를 Elasticsearch로 전달합니다.

Logstash를 실행 중인 호스트에서 /etc/logstash/conf.d/teleport-audit.conf라는 파일을 생성하고 다음 내용을 포함시킵니다:

input {
  http {
    port => 9601
    ssl =>  true
    ssl_certificate => "/home/server.crt"
    ssl_key =>  "/home/pkcs8.key"
    ssl_certificate_authorities => [
      "/home/ca.crt"
    ]
    ssl_verify_mode => "force_peer"
  }
}
output {
  elasticsearch {
    user => "teleport"
    password => "ELASTICSEARCH_PASSPHRASE"
    template_name => "audit-events"
    template => "/home/audit-events.json"
    index => "audit-events-%{+yyyy.MM.dd}"
    template_overwrite => true
  }
}

input.http 섹션에서는 ssl_certificatessl_certificate_authoritiesteleport-event-handler configure 명령이 이전에 생성한 서버 인증서 및 인증 기관 파일의 위치를 업데이트합니다.

Logstash는 CA 파일에 대해 클라이언트 인증서를 인증하고 Teleport Event Handler 플러그인에 서명된 인증서를 제공합니다.

ssl_key 필드를 이전에 생성한 pkcs8.key 파일의 경로를 포함하도록 편집합니다.

output.elasticsearch 섹션에서는 Elastic Cloud를 사용 중인지, 또는 자체 Elastic Stack 배포를 사용하는지에 따라 필드를 편집합니다:

cloud_authteleport:PASSWORD 문자열로 설정하고, 여기서 PASSWORD는 이전에 teleport 사용자에게 지정한 비밀번호로 대체합니다.

https://cloud.elastic.co/deployments를 방문하여 "Cloud ID" 필드를 찾아 그 값을 복사하고, 이를 Logstash 파이프라인 구성의 cloud_id 값으로 추가합니다. elasticsearch 섹션은 다음과 유사해야 합니다:

  elasticsearch {
    cloud_id => "CLOUD_ID"
    cloud_auth => "teleport:PASSWORD" 
    template_name => "audit-events"
    template => "/home/audit-events.json"
    index => "audit-events-%{+yyyy.MM.dd}"
    template_overwrite => true
  }

hosts를 Elasticsearch 호스트의 호스트 이름을 나타내는 문자열로 설정합니다.

userteleport로 설정하고, password를 이전에 생성한 teleport 사용자에 대한 비밀번호로 설정합니다.

elasticsearch 섹션은 다음과 유사해야 합니다:

  elasticsearch {
    hosts => "elasticsearch.example.com"
    user => "teleport" 
    password => "PASSWORD" 
    template_name => "audit-events"
    template => "/home/audit-events.json"
    index => "audit-events-%{+yyyy.MM.dd}"
    template_overwrite => true
  }

마지막으로, template을 이전에 생성한 audit-events.json 파일의 경로를 가리키도록 수정합니다.

우리가 이 파일로 생성할 인덱스 템플릿이 audit-events-* 접두사가 있는 인덱스에 적용되며, Logstash 파이프라인을 통해 생성된 인덱스는 "audit-events-%{+yyyy.MM.dd}라는 제목이 붙기 때문에, Elasticsearch는 자동으로 Teleport 감사 이벤트의 필드를 인덱싱합니다.

파이프라인에 대한 Elastic Common Schema 비활성화

Elastic Common Schema (ECS)는 Elastic Stack이 데이터를 파싱하고 시각화하는 데 사용하는 표준 필드 세트입니다. Teleport 감사 로그에서 모든 필드를 동적으로 인덱싱하도록 Elasticsearch를 구성하고 있기 때문에, Logstash 파이프라인에 대한 ECS를 비활성화합니다.

Logstash를 실행 중인 호스트에서 /etc/logstash/pipelines.yml를 편집하여 다음 항목을 추가합니다:

- pipeline.id: teleport-audit-logs
  path.config: "/etc/logstash/conf.d/teleport-audit.conf"
  pipeline.ecs_compatibility: disabled

이렇게 하면 Teleport 감사 로그 파이프라인에 대한 ECS가 비활성화됩니다.

Tip

pipelines.yml 파일이 teleport-audit.conf를 포함하는 기존 파이프라인을 정의하고 있는 경우, 예를 들어 path.config에서 와일드카드 값을 사용하는 경우, 기존 파이프라인 정의를 조정하여 더 이상 teleport-audit.conf에 적용되지 않도록 하십시오.

Logstash 파이프라인 실행

Logstash를 재시작합니다:

sudo systemctl restart logstash

Logstash 파이프라인이 성공적으로 시작되었는지 확인하려면 다음 명령을 실행하여 Logstash의 로그를 확인하십시오:

sudo journalctl -u logstash -f

Logstash 파이프라인이 http 입력을 초기화하고 실행되기 시작하면 다음과 유사한 로그가 표시되어야 합니다:

Sep 15 18:27:13 myhost logstash[289107]: [2022-09-15T18:27:13,491][INFO ][logstash.inputs.http][main][33bdff0416b6a2b643e6f4ab3381a90c62b3aa05017770f4eb9416d797681024] Starting http input listener {:address=>"0.0.0.0:9601", :ssl=>"true"}

이런 로그는 Logstash 파이프라인이 Elasticsearch에 연결되어 새 인덱스 템플릿을 설치했음을 나타냅니다:

Sep 12 19:49:06 myhost logstash[33762]: [2022-09-12T19:49:06,309][INFO ][logstash.outputs.elasticsearch][main] Elasticsearch version determined (8.4.1) {:es_version=>8}
Sep 12 19:50:00 myhost logstash[33762]: [2022-09-12T19:50:00,993][INFO ][logstash.outputs.elasticsearch][main] Installing Elasticsearch template {:name=>"audit-events"}

Logstash가 파이프라인 초기화에 실패하면 Elasticsearch에 계속 연결을 시도할 수 있습니다. 이 경우 다음과 같은 반복적인 로그를 볼 수 있습니다:

Sep 12 19:43:04 myhost logstash[33762]: [2022-09-12T19:43:04,519][WARN ][logstash.outputs.elasticsearch][main] Attempted to resurrect connection to dead ES instance, but got an error {:url=>"http://teleport:xxxxxx@127.0.0.1:9200/", :exception=>LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError, :message=>"Elasticsearch Unreachable: [http://127.0.0.1:9200/][Manticore::ClientProtocolException] 127.0.0.1:9200 failed to respond"}

문제 진단

Logstash 파이프라인 초기화 오류의 원인을 진단하려면 Logstash journalctl 로그에서 다음을 검색하십시오. 이는 파이프라인이 시작되고 있음을 나타냅니다. 관련 오류 로그는 이들 이후에 나와야 합니다:

Sep 12 18:15:52 myhost logstash[27906]: [2022-09-12T18:15:52,146][INFO][logstash.javapipeline][main] Starting pipeline {:pipeline_id=>"main","pipeline.workers"=>2, "pipeline.batch.size"=>125, "pipeline.batch.delay"=>50,"pipeline.max_inflight"=>250,"pipeline.sources"=>["/etc/logstash/conf.d/teleport-audit.conf"],:thread=>"#<Thread:0x1c1a3ee5 run>"}
Sep 12 18:15:52 myhost logstash[27906]: [2022-09-12T18:15:52,912][INFO][logstash.javapipeline][main] Pipeline Java execution initialization time {"seconds"=>0.76}

Elasticsearch TLS 비활성화

이 가이드는 Elasticsearch와 Logstash가 서로 TLS를 통해 통신하도록 구성되었다고 가정합니다.

Elastic Stack 배포가 샌드박스 또는 보안이 낮은 환경(예: 데모 환경)에 있는 경우, Logstash용 journalctl 로그에 Elasticsearch에 연결할 수 없다는 내용이 표시되면, Logstash와 Elasticsearch 간의 통신에 대한 TLS를 비활성화할 수 있습니다.

/etc/elasticsearch/elasticsearch.yml 파일을 편집하여 xpack.security.http.ssl.enabledfalse로 설정한 후, Elasticsearch를 재시작합니다.

3단계/4. Event Handler 플러그인 실행

Teleport Event Handler 구성

이 섹션에서는 귀하의 환경에 맞게 Teleport Event Handler를 구성합니다.

이전에 teleport-event-handler.toml이라는 파일을 생성하여 Fluentd 이벤트 핸들러를 구성했습니다. 이 파일은 다음과 유사한 설정을 포함하고 있습니다:

storage = "./storage"
timeout = "10s"
batch = 20
namespace = "default"
# 창 크기는 이벤트 핸들러가 Teleport로부터 이벤트를 요청하는 
# 시간 창의 지속 시간을 구성합니다. 기본적으로, 이는 24시간으로 설정됩니다.
# 기본 창 크기에 대해 이벤트 볼륨을 관리할 수 없는 경우
# 창 크기를 줄이세요.
# 창 크기는 Go의 time.ParseDuration으로 구문 분석된 지속 시간 문자열로 지정해야 합니다.
window-size = "24h"

[forward.fluentd]
ca = "/home/bob/event-handler/ca.crt"
cert = "/home/bob/event-handler/client.crt"
key = "/home/bob/event-handler/client.key"
url = "https://fluentd.example.com:8888/test.log"
session-url = "https://fluentd.example.com:8888/session"

[teleport]
addr = "example.teleport.com:443"
identity = "identity"

구성을 수정하여 fluentd.example.com을 Fluentd 배포의 도메인 이름으로 교체하십시오.

다음 템플릿을 사용하여 teleport-plugin-event-handler-values.yaml을 생성하십시오:

eventHandler:
  storagePath: "./storage"
  timeout: "10s"
  batch: 20
  namespace: "default"
  # 창 크기는 이벤트 핸들러가 Teleport로부터 이벤트를 요청하는 
  # 시간 창의 지속 시간을 구성합니다. 기본적으로, 이는 24시간으로 설정됩니다.
  # 기본 창 크기에 대해 이벤트 볼륨을 관리할 수 없는 경우 
  # 창 크기를 줄이세요.
  # 창 크기는 Go의 time.ParseDuration으로 구문 분석된 지속 시간 문자열로 지정해야 합니다.
  windowSize: "24h"

teleport:
  address: "example.teleport.com:443"
  identitySecretName: teleport-event-handler-identity
  identitySecretPath: identity

fluentd:
  url: "https://fluentd.fluentd.svc.cluster.local/events.log"
  sessionUrl: "https://fluentd.fluentd.svc.cluster.local/session.log"
  certificate:
    secretName: "teleport-event-handler-client-tls"
    caPath: "ca.crt"
    certPath: "client.crt"
    keyPath: "client.key"

persistentVolumeClaim:
  enabled: true

구성 파일을 다음과 같이 업데이트합니다.

forward.fluentd.url을 앞서 구성한 Logstash의 http 입력, https://localhost:9601로 변경합니다. forward.fluentd.session-url도 동일한 값을 기본 URL 경로로 설정합니다: https://localhost:9601/.

teleport.addr을 Teleport Proxy 서비스의 호스트와 포트, 또는 Event Handler를 직접 연결하도록 구성한 경우 Auth 서비스로 설정합니다. 예: mytenant.teleport.sh:443.

addr: Teleport Proxy Service 또는 Teleport Enterprise Cloud 테넌트의 호스트 이름과 HTTPS 포트를 포함하세요 (예: teleport.example.com:443 또는 mytenant.teleport.sh:443).

identity: 이전에 내보낸 식별자 파일의 경로를 입력하세요.

client_key, client_crt, root_cas: 이 구성에서는 사용하지 않으므로 주석 처리하세요.

address: Teleport Proxy Service 또는 Teleport Enterprise Cloud 테넌트의 호스트 이름과 HTTPS 포트를 포함하세요 (예: teleport.example.com:443 또는 mytenant.teleport.sh:443).

identitySecretName: 이전에 생성한 Kubernetes 비밀의 이름으로 identitySecretName 필드를 입력하세요.

identitySecretPath: Kubernetes 비밀 내의 식별자 파일 경로로 identitySecretPath 필드를 입력하세요. 위의 지침을 따랐다면, 이는 identity가 될 것입니다.

이벤트 핸들러에 tbot 바이너리를 사용하여 자격 증명을 제공하는 경우, 리눅스 서버에서 실행됩니다. 이벤트 핸들러 구성의 identity 값이 tbot이 생성하도록 구성한 아이덴티티 파일의 경로인 /opt/machine-id/identity와 동일한지 확인하세요.

Teleport Event Handler 시작

Teleport 이벤트 핸들러를 시작하려면 아래 지침을 따르세요.

teleport-event-handler.toml 파일을 Linux 서버의 /etc로 복사하세요.
환경에 맞게 toml 파일 내의 설정을 업데이트하세요.
identitystorage와 같은 설정에서 절대 경로를 사용해야 합니다.
사용 중인 파일과 디렉토리는 teleport-event-handler 서비스를 실행하는 시스템 사용자만 접근할 수 있어야 합니다
예: /var/lib/teleport-event-handler.

다음으로, 다음 내용을 포함한 시스템d 서비스 정의를 경로
/usr/lib/systemd/system/teleport-event-handler.service에 생성하세요:

[Unit]
Description=Teleport Event Handler
After=network.target

[Service]
Type=simple
Restart=always
ExecStart=/usr/local/bin/teleport-event-handler start --config=/etc/teleport-event-handler.toml --teleport-refresh-enabled=true
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/teleport-event-handler.pid

[Install]
WantedBy=multi-user.target

Machine ID를 사용하여 Event Handler에 단기 자격 증명을 제공하지 않는 경우,
--teleport-refresh-enabled true 플래그를 제거할 수 있습니다.

플러그인을 활성화하고 시작하세요:

sudo systemctl enable teleport-event-handler
sudo systemctl start teleport-event-handler

start 명령을 실행할 때 Teleport 이벤트 핸들러가 이벤트를 내보내기 시작할 시점을 구성할 수 있습니다.
이 예시는 2021년 5월 5일부터 내보내기를 시작합니다:

teleport-event-handler start --config /etc/teleport-event-handler.toml --start-time "2021-05-05T00:00:00Z"

시작 시점은 Teleport 이벤트 핸들러를 처음 실행할 때만 결정할 수 있습니다.
시간 범위를 나중에 변경하려면 핸들러의 구성 파일의 storage 필드에서 지정한 플러그인 상태 디렉토리를 제거하세요.

Teleport 이벤트 핸들러가 시작되면 스캔된 이벤트와 전달된 이벤트에 대한 알림이 표시됩니다:

sudo journalctl -u teleport-event-handler
DEBU Event sent id:f19cf375-4da6-4338-bfdc-e38334c60fd1 index:0 ts:2022-09-2118:51:04.849 +0000 UTC type:cert.create event-handler/app.go:140...

작업 공간에서 다음 명령을 실행하세요:

helm install teleport-plugin-event-handler teleport/teleport-plugin-event-handler \ --values teleport-plugin-event-handler-values.yaml \ --version 16.2.0

이전에 configure 명령을 실행한 디렉토리로 이동하고 다음 명령을 실행하세요:

docker run --network host -v `pwd`:/opt/teleport-plugin -w /opt/teleport-plugin public.ecr.aws/gravitational/teleport-plugin-event-handler:16.2.0 start --config=teleport-event-handler.toml

이 명령은 이벤트 핸들러 컨테이너를 미리 설정된 host 네트워크에 추가하며,
Docker 호스트 네트워킹 모드를 사용하고 네트워크 격리를 제거하여 이벤트 핸들러가
localhost에서 Fluentd 컨테이너와 통신할 수 있도록 합니다.

4단계/4. Kibana에서 데이터 뷰 생성

Kibana에서 Teleport 감사 이벤트를 탐색할 수 있도록 데이터 뷰를 생성합니다. Elastic Stack UI에서 왼쪽 상단의 햄버거 메뉴를 찾아 "관리" > "데이터 뷰"로 클릭합니다. "데이터 뷰 생성"을 클릭합니다.

"이름" 필드에 "Teleport 감사 이벤트"를 사용합니다. "인덱스 패턴"에는 audit-events-*를 사용하여 Logstash 파이프라인에 의해 생성된 모든 인덱스를 선택합니다. "타임스탬프 필드"에는 Teleport가 감사 이벤트에 추가한 time을 선택합니다.

데이터 뷰를 사용하려면 Elastic Stack UI의 상단 검색 상자에서 "Discover"를 입력합니다. 화면 왼쪽 상단의 드롭다운 메뉴를 클릭하고 "Teleport 감사 이벤트"를 선택합니다. 이제 Teleport 감사 이벤트를 검색하고 필터링하여 사용자가 Teleport 클러스터와 상호 작용하는 방식을 보다 잘 이해할 수 있습니다.

예를 들어 왼쪽 사이드바에서 event 필드를 클릭하여 Teleport 감사 이벤트의 이벤트 유형을 시간에 따라 시각화할 수 있습니다:

연결 문제 해결

Teleport Event Handler가 Teleport 클러스터에 연결하는 동안 오류 로그를 표시하는 경우 다음 사항을 확인하십시오:

  • Teleport 클러스터에 연결하는 데 사용 중인 인증서의 유효 기간이 만료되지 않았는지 확인하십시오. 이는 tctl auth sign 명령에서 --ttl 플래그의 값으로, 기본적으로 12시간입니다.
  • Teleport Event Handler 구성 파일(teleport-event-handler.toml)에 Teleport Proxy 서비스 또는 Auth 서비스의 올바른 호스트와 포트를 제공했는지 확인하십시오.

다음 단계

이제 감사 이벤트를 Elastic Stack으로 내보내고 있으므로, 감사 이벤트 참조를 참조하여 시각화 및 알림을 계획할 수 있습니다.

이 가이드에서는 Teleport Event Handler에 대한 자격 증명을 발급하기 위해 tctl auth sign 명령을 사용하지만, 프로덕션 클러스터는 더 안전하고 신뢰할 수 있는 갱신을 위해 Machine ID를 사용해야 합니다. 가이드참조를 통해 Machine ID 시작하는 방법을 알아보세요.

Teleport 원문 보기