Infograb logo
PagerDuty 접근 요청 플러그인 실행

Teleport의 PagerDuty 통합을 통해 엔지니어들은 사건을 신속하게 해결하기 위해 필요한 인프라에 접근할 수 있으며, 이는 공격 벡터가 될 수 있는 장기적인 관리 권한 없이 가능합니다.

Teleport의 PagerDuty 통합은 Teleport 역할 접근 요청을 PagerDuty 사건으로 취급하고, 적절한 대기 팀에 알리며, Teleport를 통해 요청을 승인하거나 거부할 수 있게 해줍니다. 또한, 사건의 영향을 받는 서비스의 대기 팀에 있는 사용자가 요청을 하는 경우, 플러그인을 구성하여 역할 접근 요청을 자동으로 승인하도록 설정할 수 있습니다.

Teleport Enterprise Cloud에서 Teleport는 PagerDuty 통합 을(를) 관리하며, Teleport 웹 UI에서 PagerDuty 통합 을(를) 등록할 수 있습니다.

Teleport 웹 UI를 방문하여 화면 상단 메뉴 바에서 Access Management를 클릭하십시오.

왼쪽 사이드바에서 Enroll New Integration을 클릭하여 "새 통합 등록" 페이지로 이동합니다:

"통합 유형 선택" 메뉴에서 귀하의 통합에 대한 타일을 클릭하십시오. 그럼 통합 설정을 위한 지침이 포함된 페이지와 통합 구성을 위한 양식이 표시됩니다.

이 가이드는 PagerDuty를 위한 Teleport의 접근 요청 플러그인을 설정하는 방법을 설명할 것입니다.

전제 조건

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하여 무료 평가판을 이용해 보십시오.

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

    tctltsh 다운로드에 대한 지침은 설치 를 방문하십시오.

권장: 플러그인에 단기간 사용 가능한 Teleport 자격 증명을 제공하기 위해 Machine ID를 구성합니다. 이 가이드를 따르기 전에 Machine ID 배포 가이드를 따라 tbot 바이너리를 인프라에서 실행하세요.

  • "Admin", "Global Admin" 또는 "Account Owner" 역할이 있는 PagerDuty 계정. 이 역할들은 사용자 프로필을 목록화하고 조회할 수 있는 API 토큰을 생성하는 데 필요합니다.

    PagerDuty에서 사용자 페이지를 방문하고 "Permissions & Teams" 탭으로 이동한 뒤, "Base Role" 필드의 값을 확인하면 귀하의 역할을 확인할 수 있습니다.

  • PagerDuty 플러그인을 실행할 Linux 호스트 또는 Kubernetes 클러스터.

  • 연결이 가능한지 확인하기 위해 tsh login 으로 로그인한 다음, 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오.

    예를 들어:

    tsh login --proxy=teleport.example.com --user=email@example.com
    tctl status

    클러스터 teleport.example.com

    버전 17.0.0-dev

    CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    클러스터에 연결할 수 있고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 워크스테이션에서 후속 tctl 명령어를 실행할 수 있습니다.
    자신의 Teleport 클러스터를 호스팅하는 경우, Teleport Auth Service를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1/8단계. 서비스 생성

PagerDuty 플러그인의 시演을 위해 PagerDuty에서 두 개의 서비스를 생성합니다. 각 서비스에 대해 "이름" 필드만 입력하고 나머지 설정 화면은 건너뛰어 기본값으로 남겨 둡니다:

  • Teleport Access Request Notifications
  • My Critical Service

우리는 PagerDuty 플러그인이 특정 사용자가 접근 요청을 생성할 때 Teleport Access Request Notifications 서비스에 사건을 생성하도록 구성할 것입니다.

My Critical Service 의 대기 팀에 있는 사용자들(이 경우 귀하의 PagerDuty 사용자)에 대해, PagerDuty 플러그인은 접근 요청을 자동으로 승인하도록 구성하며, 이들이 서비스를 신속하게 조사할 수 있도록 합니다.

2/8단계. RBAC 리소스 정의

Teleport PagerDuty 플러그인은 Teleport Auth 서비스로부터 접근 요청 이벤트를 수신하여 이러한 이벤트에 따라 PagerDuty API와 상호작용하여 작동합니다.

이 섹션에서는 다음과 같은 RBAC 리소스를 정의하여 PagerDuty 플러그인을 구성하는 방법을 보여 드립니다:

  • editor-requester 라고 하는 역할로, 내장된 editor 역할을 요청할 수 있습니다. 이 역할은 사용자가 요청할 때마다 PagerDuty 사건을 열도록 구성되어, Teleport Access Request Notifications 서비스의 대기 팀에 알립니다.
  • demo-role-requester 라는 역할로, demo-role 이라는 역할을 요청할 수 있습니다. PagerDuty 플러그인은 사용자가 My Critical Service 의 대기 팀에 속할 때 이 요청을 자동으로 승인하도록 구성합니다.
  • PagerDuty 플러그인이 Teleport Auth 서비스에 인증하기 위해 가정할 사용자 및 역할인 access-plugin . 이 역할은 My Critical Service 의 대기 팀 사용자로부터의 접근 요청을 자동으로 승인할 수 있는 권한을 가집니다.
  • PagerDuty 플러그인이 Teleport 클러스터와 인증하는 데 사용할 수 있는 서명된 자격 증명을 생성할 수 있도록 하는 access-plugin-impersonator 라는 역할.

editor-requester

editor-request-rbac.yaml 파일을 생성하고 다음 내용을 포함하십시오. 이는 editor 역할을 위한 요청을 검토할 수 있는 editor-reviewer 라는 역할과 이 역할을 요청할 수 있는 editor-requester 역할을 정의합니다.

kind: role
version: v5
metadata:
  name: editor-reviewer
spec:
  allow:
    review_requests:
      roles: ["editor"]
---
kind: role
version: v5
metadata:
  name: editor-requester
spec:
  allow:
    request:
      roles: ["editor"]
      thresholds:
        - approve: 1
          deny: 1
      annotations:
        pagerduty_notify_service: ["Teleport Access Request Notifications"]

Teleport Auth 서비스는 Access Request를 제출하는 Teleport 사용자 역할에 기반하여 Access Request 이벤트에 메타데이터를 주석으로 추가합니다. PagerDuty 플러그인은 이러한 주석을 읽어 새 Access Request 이벤트에 대한 응답 방법을 결정합니다.

editor-requester 역할을 가진 사용자가 editor 역할을 요청할 때마다 PagerDuty 플러그인은 pagerduty_notify_service 주석을 읽고 지정된 서비스인 Teleport Access Request Notifications 에 사고를 열도록 PagerDuty에 알리며, editor-reviewer 역할을 가진 사람이 요청을 승인하거나 거부할 때까지 이 과정을 지속합니다.

정의한 역할을 생성하십시오:

tctl create -f editor-request-rbac.yaml
role 'editor-reviewer' 가 생성되었습니다.role 'editor-requester' 가 생성되었습니다.

demo-role-requester

demo-role-requester.yaml 파일을 생성하고 다음 내용을 포함하십시오:

kind: role
version: v5
metadata:
  name: demo-role
---
kind: role
version: v5
metadata:
  name: demo-role-requester
spec:
  allow:
    request:
      roles: ["demo-role"]
      thresholds:
        - approve: 1
          deny: 1
      annotations:
        pagerduty_services: ["My Critical Service"]

demo-role-requester 역할을 가진 사용자는 demo-role 역할을 요청할 수 있습니다. 이러한 사용자가 요청할 경우 PagerDuty 플러그인은 pagerduty_services 주석을 읽습니다. 요청하는 사용자가 주석의 값으로 나열된 서비스의 온콜 팀에 있는 경우, 플러그인은 Access Request를 자동으로 승인합니다.

이 경우, PagerDuty 플러그인은 My Critical Service 에 대한 온콜 팀의 사용자가 요청하는 경우 어떤 요청도 승인합니다.

리소스를 생성하십시오:

tctl create -f demo-role-requester.yaml;
Warning

자동 승인을 작동시키기 위해서는 Access Request를 생성하는 사용자의 Teleport 사용자 이름이 또한 PagerDuty 계정과 연결된 이메일 주소여야 합니다. 이 가이드에서는 demo-role-requester 역할을 귀하의 Teleport 계정에 추가할 것입니다. 이는 우리가 귀하의 PagerDuty와도 연결된 이메일 주소라고 가정합니다. 따라서 귀하는 demo-role 역할을 요청할 수 있습니다.

access-plugin

Teleport의 Access Request 플러그인은 Access Request를 나열, 읽기 및 업데이트할 수 있는 권한이 있는 사용자로서 Teleport 클러스터에 인증됩니다. 이를 통해 플러그인은 Teleport Auth 서비스에서 Access Request를 검색하고 이를 검토자에게 제시하며 검토 후 수정할 수 있습니다.

다음 내용을 access-plugin.yaml 이라는 파일에 추가하여 access-plugin 이라는 사용자 및 역할을 정의하십시오:

kind: role
version: v5
metadata:
  name: access-plugin
spec:
  allow:
    rules:
      - resources: ["access_request"]
        verbs: ["list", "read"]
      - resources: ["access_plugin_data"]
        verbs: ["update"]
    review_requests:
      roles: ["demo-role"]
      where: 'contains(request.system_annotations["pagerduty_services"], "My Critical Service")'
---
kind: user
metadata:
  name: access-plugin
spec:
  roles: ["access-plugin"]
version: v2

access-plugin 역할에는 allow.review_requests.roles 필드에 demo-role 이 포함되어 있습니다. 이는 플러그인이 demo-role 역할에 대한 요청을 검토할 수 있도록 합니다.

또한 access-plugin 역할은 My Critical Service 와 관련된 Access Request만 검토하도록 제한하고 있습니다. 이를 위해 review_requests.where 필드에 술어 표현식을 정의하였습니다. 이 표현식은 요청이 pagerduty_services 라는 주석이 포함된 경우에만 demo-role 에 대한 요청을 검토할 수 있음을 나타냅니다.

where 필드는 특정 요청을 검토할 수 있는지 여부를 결정하는 술어 표현식을 포함합니다. 표현식에서는 두 가지 기능을 포함할 수 있습니다:

기능설명예제
equals필드와 값이 동일함.equals(request.reason, "resolve an incident")
contains문자열 목록에 값이 포함됨.contains(reviewer.traits["team"], "devops")

where 필드를 사용할 때 다음 필드를 술어 표현식에 포함할 수 있습니다:

필드유형설명
reviewer.roles[]string검토자의 Teleport 역할 이름 목록
reviewer.traitsmap[string][]string특성 이름별로 검토자의 Teleport 특성 맵
request.roles[]string사용자가 요청하는 Teleport 역할 목록
request.reasonstring요청에 첨부된 이유
request.system_annotationsmap[string][]string주석 키에 의해 요청의 주석에 대한 맵, 예: pagerduty_services

함수를 결합할 때는 다음 연산자를 사용할 수 있습니다:

연산자형식설명
&&function && function두 함수가 모두 true로 평가될 때 true로 평가됩니다.
||function || function하나 또는 두 함수가 모두 true로 평가될 때 true로 평가됩니다.
!!function함수가 false로 평가될 때 true로 평가됩니다.

함수의 예시로는 equals(request.reason, "resolve an incident")가 있습니다. Access Request에 이유로 "해결하기 위해 사건"이 포함되지 않은 요청을 일치시키려면, !equals(request.reason, "resolve an incident") 함수를 사용할 수 있습니다.

사용자 및 역할을 생성하십시오:

tctl create -f access-plugin.yaml

access-plugin-impersonator

모든 Teleport 사용자와 마찬가지로, Teleport Auth Service는 access-plugin 사용자를 짧은 수명의 TLS 자격 증명을 발급하여 인증합니다. 이 경우, access-plugin 역할과 사용자를 가장하는 방식으로 자격 증명을 수동으로 요청해야 합니다.

자체 호스팅되는 Teleport Enterprise 클러스터를 실행 중이고 Auth Service 호스트에서 tctl 을 사용하는 경우, 이미 가장하는 권한이 있을 것입니다.

사용자에게 access-plugin 에 대한 가장하는 권한을 부여하려면, 다음 YAML 문서를 access-plugin-impersonator.yaml 이라는 파일에 붙여넣어 access-plugin-impersonator 라는 역할을 정의하십시오:

kind: role
version: v5
metadata:
  name: access-plugin-impersonator
spec:
  allow:
    impersonate:
      roles:
        - access-plugin
      users:
        - access-plugin

access-plugin-impersonator 역할을 생성하십시오:

tctl create -f access-plugin-impersonator.yaml

사용자에게 역할 추가

이 가이드의 뒷부분에서는 Teleport 사용자가 추가 권한이 필요한 세 가지 작업을 수행합니다:

  • PagerDuty 플러그인이 Teleport 클러스터에 연결하는 데 사용할 서명된 자격 증명 생성
  • editor 역할에 대한 액세스 요청 수동 검토
  • demo-role 역할에 대한 액세스 요청 생성

이러한 권한을 사용자에게 부여하려면, 앞서 정의한 editor-reviewer , access-plugin-impersonator , 및 demo-role-requester 역할을 사용자에게 추가하십시오.

사용자 정의를 편집기에서 엽니다:

TELEPORT_USER=$(tsh status --format=json | jq -r .active.username)
tctl edit users/${TELEPORT_USER?}

사용자를 편집하여 방금 생성한 역할을 포함시킵니다:

  roles:
   - access
   - auditor
   - editor
+  - editor-reviewer
+  - access-plugin-impersonator
+  - demo-role-requester

편집기에서 파일을 저장하고 닫아 변경 사항을 적용합니다.

Teleport 클러스터에서 로그아웃한 후 다시 로그인하십시오. 이제 editor 역할에 대한 요청을 검토하고, demo-role 역할을 요청하며, access-plugin 역할 및 사용자에 대한 서명된 인증서를 생성할 수 있습니다.

액세스를 요청할 사용자 생성

editor-requester 역할을 가진 myuser 라는 사용자를 생성하십시오. 이 가이드의 뒷부분에서는 PagerDuty 플러그인을 테스트하기 위해 이 사용자가 액세스 요청을 생성할 것입니다:

tctl users add myuser --roles=editor-requester

tctl 은 터미널에 초대 URL을 출력합니다. URL에 방문하여 처음으로 myuser 로 로그인하고, Teleport 클러스터에 구성된 대로 자격 증명을 등록하십시오.

3/8단계. Teleport PagerDuty 플러그인 설치

Access Request Plugins는 다운로드를 위해 amd64arm64 Linux 바이너리로 제공됩니다.
ARCH 를 필요한 버전으로 교체하십시오.

curl -L -O https://cdn.teleport.dev/teleport-access-pagerduty-v13.3.7-linux-ARCH-bin.tar.gz
tar -xzf teleport-access-pagerduty-v13.3.7-linux-ARCH-bin.tar.gz
cd teleport-access-pagerduty
sudo ./install

바이너리가 설치되었는지 확인하십시오:

teleport-pagerduty version
teleport-pagerduty v13.3.7 git:teleport-pagerduty-v13.3.7-fffffffff go1.22
docker pull public.ecr.aws/gravitational/teleport-plugin-pagerduty:13.3.7

다음 명령을 실행하여 플러그인이 설치되었는지 확인하십시오:

docker run public.ecr.aws/gravitational/teleport-plugin-pagerduty:13.3.7 version
teleport-pagerduty v13.3.7 git:teleport-pagerduty-v13.3.7-api/14.0.0-gd1e081e 1.22

사용 가능한 태그 목록은 Amazon ECR Public Gallery를 방문하십시오.

소스에서 설치하려면 gitgo 가 설치되어 있어야 합니다. Go가 설치되어 있지 않다면, Go 다운로드 페이지를 방문하십시오.

git clone https://github.com/gravitational/teleport -b branch/v17
cd teleport/integrations/access/pagerduty
git checkout 13.3.7
make

teleport-pagerduty 바이너리를 PATH로 이동하십시오.

바이너리가 설치되었는지 확인하십시오:

teleport-pagerduty version
teleport-pagerduty v13.3.7 git:teleport-pagerduty-v13.3.7-fffffffff go1.22

Helm이 Teleport Helm 저장소에 호스트된 차트를 설치할 수 있도록 허용합니다:

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

원격 저장소에서 차트 캐시를 업데이트합니다:

helm repo update

4/8단계. 액세스 플러그인 아이덴티티 내보내기

플러그인에 Teleport 아이덴티티 파일에 대한 액세스를 제공합니다. 우리는 머신 ID를 사용하는 것을 권장하며, 이는 유출되었을 경우 덜 위험한 짧은 수명의 아이덴티티 파일을 생성하기 위해서입니다. 그러나 데모 배포에서는 tctl 을 사용하여 긴 수명의 아이덴티티 파일을 생성할 수 있습니다:

tbot 을 구성하여 the plugin 에 필요한 자격 증명을 생성하는 출력을 설정합니다. the plugin 가 Teleport API에 액세스할 것이므로, 사용할 올바른 출력 유형은 identity 입니다.

이 안내서에서는 directory 대상을 사용할 것입니다. 이는 이러한 자격 증명을 디스크의 지정된 디렉토리에 작성합니다. 이 디렉토리는 tbot 이 실행되는 Linux 사용자가 쓸 수 있도록 하여야 하며, the plugin 가 실행되는 Linux 사용자가 읽을 수 있도록 해야 합니다.

tbot 구성을 수정하여 identity 출력을 추가합니다.

Linux 서버에서 tbot 을 실행하는 경우, directory 출력을 사용하여 /opt/machine-id 디렉토리에 신원 파일을 작성합니다:

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-plugin-pagerduty-identity

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

이제 /opt/machine-id 아래에 identity 파일 또는 teleport-plugin-pagerduty-identity 라는 Kubernetes 비밀이 생성된 것을 볼 수 있습니다. 이 파일에는 the plugin 가 Teleport Auth 서비스에 인증하기 위해 필요한 개인 키와 서명된 인증서가 포함되어 있습니다.

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

다음 tctl auth sign 명령은 access-plugin 사용자로 가장하여 서명된 자격 증명을 생성하고, 로컬 디렉토리에 아이덴티티 파일을 작성합니다:

tctl auth sign --user=access-plugin --out=identity

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

아이덴티티 파일인 identity 는 TLS 및 SSH 자격 증명을 모두 포함합니다. plugin는 SSH 자격 증명을 사용하여 Proxy Service에 연결하고, Proxy Service는 Auth Service로의 역 터널 연결을 설정합니다. plugin는 이 역 터널과 TLS 자격 증명을 사용하여 Auth Service의 gRPC 엔드포인트에 연결합니다.

기본적으로 tctl auth sign 은 상대적으로 짧은 수명의 인증서를 생성합니다. 운영 배포를 위해, 우리는 Machine ID를 사용하여 프로그램적으로 인증서를 발급하고 갱신할 것을 제안합니다. 이에 대한 자세한 내용은 Machine ID 시작 가이드를 참조하십시오.

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

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

리눅스 서버에서 plugin를 실행 중이라면, plugin의 인증서 파일을 보관할 데이터 디렉토리를 생성하십시오:

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

Kubernetes에서 plugin를 실행 중이라면, Teleport 아이덴티티 파일을 포함하는 Kubernetes 비밀을 생성하십시오:

kubectl -n teleport create secret generic --from-file=identity teleport-plugin-pagerduty-identity

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

5/8단계. PagerDuty API 키 설정

PagerDuty 플러그인이 사건을 생성 및 수정하고 사용자, 서비스, 온콜 정책을 목록화하는 데 사용할 API 키를 생성합니다.

PagerDuty 대시보드에서 Integrations → API Access Keys로 이동하여 Create New API Key를 클릭합니다. 키 설명을 추가합니다. 예: "Teleport 통합". "Read-only API Key"는 선택하지 않습니다. 키를 로컬 머신의 파일에 복사합니다. 나중에 플러그인 구성 파일에서 키를 사용합니다.

6/8단계. PagerDuty 플러그인 구성

이 시점에서 PagerDuty 플러그인이 Teleport 및 PagerDuty API에 연결하는 데 사용할 자격 증명을 생성했습니다. 이제 이러한 자격 증명을 사용하도록 PagerDuty 플러그인을 구성하고, 환경에 필요한 설정을 조정할 것입니다.

Teleport의 PagerDuty 플러그인은 TOML 형식의 독자적인 구성 파일을 가지고 있습니다. PagerDuty 플러그인을 실행할 호스트에서 다음 명령어를 실행하여 보일러플레이트 구성을 생성합니다:

teleport-pagerduty configure > teleport-pagerduty.toml
sudo mv teleport-pagerduty.toml /etc

PagerDuty Helm Chart는 플러그인을 구성하기 위해 YAML 값 파일을 사용합니다. Helm이 설치된 호스트에서 다음 예제를 기반으로 teleport-pagerduty-values.yaml 라는 파일을 생성합니다:

teleport:
  address: "" # Teleport Auth Server GRPC API 주소
  identitySecretName: "" # 아이덴티티 비밀 이름
  identitySecretPath: "" # 아이덴티티 비밀 경로

pagerduty:
  apiKey: "" # PagerDuty API 키
  userEmail: "" # PagerDuty 봇 사용자 이메일 (관리자 이메일일 수 있음)

PagerDuty 플러그인은 구성이 /etc/teleport-pagerduty.toml 에 있어야 한다고 예상하지만, 이 가이드에서 플러그인 이진 파일을 실행할 때 --config 플래그를 사용하여 이를 무시할 수 있습니다.

아래 설명에 따라 /etc/teleport-pagerduty.toml 에 있는 구성 파일을 편집합니다:

[teleport]

PagerDuty 플러그인은 이 섹션을 사용하여 Teleport 클러스터에 연결합니다:

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 가 됩니다.

자신이 Linux 서버에서 실행되는 tbot 바이너리를 사용하여 플러그인에 자격 증명을 제공하는 경우, identity 의 값이 tbot 에서 생성하도록 구성한 인증서 파일의 경로와 동일한지 확인하십시오, /opt/machine-id/identity .

플러그인을 구성하여 인증서 파일을 주기적으로 다시 로드하도록 하여 만료된 자격 증명으로 Teleport Auth Service에 연결하려 하지 않도록 합니다.

구성의 teleport 섹션에 다음을 추가하십시오:

refresh_identity = true

[pagerduty]

api_key 를 이전에 생성한 PagerDuty API 키에 할당합니다.

user_email 을 API 키와 연결된 계정의 PagerDuty 사용자 이메일 주소에 할당합니다. PagerDuty 플러그인이 새로운 사건을 생성할 때, PagerDuty는 이 사건을 해당 사용자에 의해 생성된 것으로 표시합니다.

이 가이드는 Teleport PagerDuty 플러그인이 새로운 접근 요청 사건을 알릴 서비스 를 결정하기 위해 pagerduty_notify_service 주석을 사용하고, 자동 승인 구성을 위해 pagerduty_services 주석을 사용한다고 가정하고 있습니다.

이러한 주석의 이름을 Teleport 역할에서 다르게 사용하고 싶다면 pagerduty.notify_servicepagerduty.services 필드에 할당할 수 있습니다.

최종 구성은 다음과 유사해야 합니다:

# teleport-pagerduty 구성 TOML 파일 예시

[teleport]
auth_server = "myinstance.teleport.sh:443"                  # Teleport Cloud 프록시 HTTPS 주소
identity = "/var/lib/teleport/plugins/pagerduty/identity"   # Identity 파일 경로
refresh_identity = true                                     # Identity 파일을 주기적으로 갱신

[pagerduty]
api_key = "key"               # PagerDuty API 키
user_email = "me@example.com" # PagerDuty 봇 사용자 이메일 (관리자 이메일일 수 있음)

[log]
output = "stderr" # 로거 출력. "stdout", "stderr" 또는 "/var/lib/teleport/pagerduty.log" 중 하나를 선택할 수 있습니다.
severity = "INFO" # 로거 심각도. "INFO", "ERROR", "DEBUG" 또는 "WARN" 중 하나를 선택할 수 있습니다.

teleport:
  # Teleport HTTPS Proxy 웹 주소, Teleport Enterprise Cloud의 경우 "your-account.teleport.sh:443" 형식이어야 합니다.
  address: "teleport.example.com:443"
  # Identity를 포함하는 Secret
  identitySecretName: teleport-plugin-pagerduty-identity
  # Secret 내에서 Identity 파일이 위치한 경로
  identitySecretPath: identity

pagerduty:
  apiKey: "key"                # PagerDuty API 키
  userEmail: "me@example.com"  # PagerDuty 봇 사용자 이메일 (관리자 이메일일 수도 있음)

log:
  output: "stderr"  # 로거 출력. "stdout", "stderr" 또는 "/var/lib/teleport/pagerduty.log" 중 하나를 선택할 수 있습니다.
  severity: "INFO"  # 로거 심각도. "INFO", "ERROR", "DEBUG" 또는 "WARN" 중 하나를 선택할 수 있습니다.

7/8 단계. PagerDuty 플러그인 테스트

PagerDuty 플러그인을 구성한 후, 다음 명령어를 실행하여 시작합니다.
-d 플래그는 플러그인이 PagerDuty 및 Teleport 클러스터에 연결할 수 있는지 확인하기 위한 디버그 정보를 제공합니다:

teleport-pagerduty start -d

DEBU DEBUG 로깅이 활성화되었습니다 logrus/exported.go:117

INFO Teleport Access PagerDuty 확장 0.1.0-dev.1 시작 중: pagerduty/main.go:124

DEBU Teleport 서버 버전 확인 중 pagerduty/main.go:226

DEBU 요청 감시자를 시작합니다... pagerduty/main.go:288

DEBU PagerDuty API 상태 확인 시작... pagerduty/main.go:170

DEBU :8081에서 보안 HTTPS 서버 시작 중 utils/http.go:146

DEBU 감시자가 연결되었습니다 pagerduty/main.go:252

DEBU PagerDuty API 상태 확인이 완료되었습니다. ok pagerduty/main.go:176

DEBU 웹훅 확장을 설정 중입니다 pagerduty/main.go:178

플러그인을 실행합니다:

docker run -v <path-to-config>:/etc/teleport-pagerduty.toml public.ecr.aws/gravitational/teleport-plugin-pagerduty:17.0.0-dev start

구성을 수정한 후, 다음 명령어로 봇을 실행합니다:

helm upgrade --install teleport-plugin-pagerduty teleport/teleport-plugin-pagerduty --values teleport-pagerduty-values.yaml

플러그인의 로그를 점검하려면 다음 명령어를 사용합니다:

kubectl logs deploy/teleport-plugin-pagerduty

디버그 로그는 teleport-pagerduty-helm.yaml 에서 log.severityDEBUG 로 설정하고 위의 helm upgrade ... 명령어를 다시 실행하여 활성화할 수 있습니다. 그런 다음 다음 명령어로 플러그인을 다시 시작할 수 있습니다:

kubectl rollout restart deployment teleport-plugin-pagerduty

접근 요청 생성

Teleport 사용자 myusereditor 역할에 대한 접근 요청을 생성합니다:

Teleport 관리자는 tctl 을 사용하여 다른 사용자에 대한 액세스 요청을 생성할 수 있습니다:

tctl request create myuser --roles=editor

사용자는 tsh 를 사용하여 액세스 요청을 생성하고 승인된 역할로 로그인할 수 있습니다:

tsh request create --roles=editor
요청 승인 중... (id: 8f77d2d1-2bbf-4031-a300-58926237a807)

사용자는 "액세스 요청" 탭을 방문하고 "새 요청"을 클릭하여 웹 UI를 사용하여 액세스를 요청할 수 있습니다:

PagerDuty 플러그인 호스트에서 다음과 유사한 로그를 볼 수 있습니다:

INFO   PagerDuty 인시던트 pd_incident_id:00000000000000을(를) 성공적으로 생성했습니다.
pd_service_name:Teleport 접근 요청 알림
request_id:00000000-0000-0000-0000-000000000000 request_op:put
request_state:PENDING pagerduty/app.go:366

PagerDuty에서는 접근 요청에 대한 정보가 포함된 새로운 인시던트를 볼 수 있습니다:

요청 해결

Access Request 메시지를 수신하면 링크를 클릭하여 Teleport를 방문하고 요청을 승인하거나 거부하십시오:

명령줄에서 Access Request를 검토할 수도 있습니다:

REQUEST_ID를 요청의 ID로 변경하십시오

tctl request approve REQUEST_ID
tctl request deny REQUEST_ID

REQUEST_ID를 요청의 ID로 변경하십시오

tsh request review --approve REQUEST_ID
tsh request review --deny REQUEST_ID
접근 요청 감사

PagerDuty 플러그인이 알림을 보낼 때, 알림을 수신한 누구나 포함된 링크를 따라 접근 요청 URL로 이동할 수 있습니다. 사용자는 접근 요청을 검토하기 위해 Teleport 역할을 통해 권한이 있어야 하지만, 올바른 사용자가 올바른 요청을 검토하고 있는지 확인하기 위해 Teleport 감사 로그를 반드시 확인해야 합니다.

접근 요청 검토를 감사할 때는 Teleport 웹 UI에서 Access Request Reviewed 유형의 이벤트를 확인하십시오.

자동 승인 트리거

귀하의 Teleport 사용자로서 demo-role 롤에 대한 액세스 요청을 생성하십시오.

귀하의 PagerDuty 플러그인 호스트에서 다음과 유사한 로그를 볼 수 있습니다:

INFO   요청 승인이 성공적으로 제출되었습니다
pd_user_email:myuser@example.com pd_user_name:내 사용자
request_id:00000000-0000-0000-0000-000000000000 request_op:put
request_state:PENDING pagerduty/app.go:511

귀하의 액세스 요청은 승인$1 으로 표시됩니다:

tsh requests ls
ID 사용자 역할 생성 (UTC) 상태------------------------------------ ------------------ --------- ------------------- --------00000000-0000-0000-0000-000000000000 myuser@example.com demo-role 12 Aug 22 18:30 UTC 승인됨

8/8단계. systemd 설정하기

이 섹션은 Linux 호스트에서 Teleport PagerDuty 플러그인을 실행하는 경우에만 관련이 있습니다.

운영 환경에서는 systemd와 같은 초기화 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것을 권장합니다. 아래는 systemd용으로 추천하는 Teleport 플러그인 서비스 유닛 파일입니다:

[Unit]
Description=Teleport Pagerduty Plugin
After=network.target

[Service]
Type=simple
Restart=on-failure
ExecStart=/usr/local/bin/teleport-pagerduty start --config=/etc/teleport-pagerduty.toml
ExecReload=/bin/kill -HUP $MAINPID
PIDFile=/run/teleport-pagerduty.pid

[Install]
WantedBy=multi-user.target

이를 /usr/lib/systemd/system/ 또는 systemd에서 지원하는 다른 유닛 파일 로드 경로teleport-pagerduty.service 로 저장하십시오.

플러그인을 활성화하고 시작하십시오:

sudo systemctl enable teleport-pagerduty
sudo systemctl start teleport-pagerduty
Teleport 원문 보기