Infograb logo
PagerDuty 액세스 요청 플러그인 실행

Teleport의 PagerDuty 통합을 통해 엔지니어는 인프라에 액세스하여 신속하게 사건을 해결할 수 있습니다. 오랜 관리 권한 없이도 필요할 때 사용할 수 있습니다. 이것은 공격의 벡터가 될 수 있습니다.

Teleport의 PagerDuty 통합을 통해 Teleport 역할 액세스 요청을 PagerDuty 사건으로 처리하고, 적절한 대기 팀에 알림을 보내며 요청을 Teleport를 통해 승인하거나 거부할 수 있습니다. 또한 사용자가 사건에 영향을 미치는 서비스에 대한 대기 팀에 속해 있는 경우, 플러그인을 구성하여 역할 액세스 요청을 자동으로 승인할 수 있습니다.

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

Teleport 웹 UI를 방문하고 화면 상단의 메뉴 바에서 Access Management를 클릭하세요.

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

"통합 유형 선택" 메뉴에서 귀하의 통합 용 타일을 클릭하세요. 통합 설정 지침과 통합 구성을 위한 양식이 있는 페이지가 표시됩니다.

이 가이드는 PagerDuty를 위한 Teleport의 액세스 요청 플러그인 설정 방법을 설명합니다.

전제 조건

  • 실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.

  • tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

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

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

  • "관리자", "글로벌 관리자" 또는 "계정 소유자" 역할이 있는 PagerDuty 계정. 이 역할은 사용자 프로필을 나열하고 조회할 수 있는 API 토큰을 생성하는 데 필요합니다.

    PagerDuty에서 사용자 페이지를 방문하고 "권한 및 팀" 탭으로 이동한 다음 "기본 역할" 필드의 값을 확인하여 역할을 확인할 수 있습니다.

  • PagerDuty 플러그인을 실행할 Linux 호스트 또는 Kubernetes 클러스터가 필요합니다.

  • 당신의 Teleport 클러스터에 연결할 수 있는지 확인하려면, tsh login으로 로그인한 다음 현재 자격 증명을 사용하여 tctl 명령어를 실행할 수 있는지 확인하십시오.

    예를 들어:

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

    클러스터 teleport.example.com

    버전 16.2.0

    CA 핀 sha256:abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678abdc1245efgh5678

    클러스터에 연결하고 tctl status 명령어를 실행할 수 있다면, 현재 자격 증명을 사용하여 작업대에서 후속 tctl 명령어를 실행할 수 있습니다.

    자신의 Teleport 클러스터를 호스팅하는 경우, Teleport 인증 서비스를 호스팅하는 컴퓨터에서 전체 권한으로 tctl 명령어를 실행할 수도 있습니다.

1단계/8. 서비스 생성

PagerDuty 플러그인을 보여주기 위해 PagerDuty에서 두 개의 서비스를 생성합니다. 각 서비스에 대해 "이름" 필드만 입력하고 다른 구성 화면은 건너뛰어 기본값으로 두십시오:

  • Teleport Access Request Notifications
  • My Critical Service

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

My Critical Service의 대기 팀에 속한 사용자의 경우 (이 경우, 귀하의 PagerDuty 사용자), PagerDuty 플러그인을 구성하여 액세스 요청을 자동으로 승인하여 신속하게 서비스에서 사건을 조사할 수 있도록 할 것입니다.

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

Teleport PagerDuty 플러그인은 Teleport 인증 서비스에서 액세스 요청 이벤트를 수신하고 이러한 이벤트를 기반으로 PagerDuty API와 상호작용합니다.

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

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

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 인증 서비스는 액세스 요청 이벤트를 Teleport 사용자의 역할에 따라 메타데이터와 함께 주석을 달아 전송합니다. PagerDuty 플러그인은 이러한 주석을 읽어 새로운 액세스 요청 이벤트에 어떻게 응답할지를 결정합니다.

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

정의한 역할을 생성합니다:

tctl create -f editor-request-rbac.yaml
role 'editor-reviewer' has been createdrole 'editor-requester' has been created

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 주석을 읽습니다. 사용자가 요청을 하는 경우 대기 팀에 속하는 경우, 플러그인은 액세스 요청을 자동으로 승인할 것입니다.

이 경우 PagerDuty 플러그인은 My Critical Service의 대기 팀에 속한 사용자가 만든 요청을 승인합니다.

리소스를 생성합니다:

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

자동 승인이 작동하려면 액세스 요청을 생성하는 사용자의 Teleport 사용자 이름이 PagerDuty 계정과 연관된 이메일 주소와 동일해야 합니다. 본 가이드에서는 귀하의 이메일 주소로 PagerDuty에 가입된 demo-role-requester 역할을 귀하의 Teleport 계정에 추가할 것입니다.

access-plugin

Teleport의 액세스 요청 플러그인은 액세스 요청을 나열, 읽기 및 업데이트할 수 있는 권한을 가진 사용자로 귀하의 Teleport 클러스터에 인증합니다. 이렇게 함으로써 플러그인은 Teleport 인증 서비스에서 액세스 요청을 검색하고, 이를 검토자에게 보여주며, 검토 후 수정할 수 있습니다.

다음 내용을 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 역할에는 요청에 대한 검토 요청 역할로 demo-role을 포함하는 allow.review_requests.roles 필드가 포함되어 있습니다. 이를 통해 플러그인이 demo-role 역할 요청을 검토할 수 있게 됩니다.

또한 access-plugin 역할은 My Critical Service와 연관된 액세스 요청만 검토하도록 제한하고 있습니다. 이를 위해 review_requests.where 필드에 predicate expression을 정의합니다. 이 표현식은 요청이 pagerduty_services라는 주석 키와 My Critical Service라는 값을 포함하지 않으면 플러그인이 요청을 검토할 수 없음을 나타냅니다.

where 필드는 검토자가 특정 요청을 검토할 수 있는지 여부를 결정하는 predicate expression을 포함합니다. predicate expression에 두 가지 함수를 포함할 수 있습니다:

FunctionDescriptionExample
equalsA field is equivalent to a value.equals(request.reason, "resolve an incident")
containsA list of strings includes a value.contains(reviewer.traits["team"], "devops")

where 필드를 사용할 때 다음 필드를 predicate expression에 포함할 수 있습니다:

FieldTypeDescription
reviewer.roles[]stringA list of the reviewer's Teleport role names
reviewer.traitsmap[string][]stringA map of the reviewer's Teleport traits by the name of the trait
request.roles[]stringA list of the Teleport roles a user is requesting
request.reasonstringThe reason attached to the request
request.system_annotationsmap[string][]stringA map of annotations for the request by annotation key, e.g., pagerduty_services

함수를 다음과 같은 연산자를 사용하여 결합할 수 있습니다:

OperatorFormatDescription
&&function && functionEvaluates to true if both functions evaluate to true
||function || functionEvaluates to true if either one or both functions evaluate to true
!!functionEvaluates to true if the function evaluates to false

함수의 예로는 equals(request.reason, "resolve an incident")가 있습니다. 액세스 요청이 이유 없이 제출될 때 (즉, "incident 해결"이 아님) allow 조건을 구성하기 위해, 사용할 수 있는 표현식은 !equals(request.reason, "resolve an incident")입니다.

사용자와 역할을 생성합니다:

tctl create -f access-plugin.yaml

access-plugin-impersonator

모든 Teleport 사용자와 마찬가지로, Teleport 인증 서비스는 짧은 기간의 TLS 자격 증명을 발급하여 access-plugin 사용자 인증을 수행합니다. 이 경우, access-plugin 역할 및 사용자를 impersonate하여 자격 증명을 수동으로 요청해야 합니다.

셀프 호스팅된 Teleport Enterprise 클러스터를 운영 중이며 인증 서비스 호스트에서 tctl을 사용하는 경우, 이미 impersonation 권한이 있습니다.

귀하의 사용자에게 access-plugin에 대한 impersonation 권한을 부여하려면, access-plugin-impersonator라는 역할을 정의하고 다음 YAML 문서를 access-plugin-impersonator.yaml 파일에 붙여넣습니다:

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 get users/${TELEPORT_USER?} > myuser.yaml

myuser.yaml을 편집하여 다음과 같이 방금 생성한 역할을 포함시킵니다:

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

변경 사항을 적용합니다:

tctl create -f myuser.yaml

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 플러그인 설치

액세스 요청 플러그인은 amd64arm64 Linux 이진 파일로 다운로드할 수 있습니다. ARCH를 필요로 하는 버전으로 바꿔주세요.

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

이진 파일이 설치되었는지 확인하세요:

teleport-pagerduty version
teleport-pagerduty v16.2.0 git:teleport-pagerduty-v16.2.0-fffffffff go1.22
docker pull public.ecr.aws/gravitational/teleport-plugin-pagerduty:16.2.0

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

docker run public.ecr.aws/gravitational/teleport-plugin-pagerduty:16.2.0 version
teleport-pagerduty v16.2.0 git:teleport-pagerduty-v16.2.0-api/14.0.0-gd1e081e 1.22

사용 가능한 태그 목록은 Amazon ECR Public Gallery를 방문하세요.

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

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

teleport-pagerduty 이진 파일을 PATH로 이동하세요.

이진 파일이 설치되었는지 확인하세요:

teleport-pagerduty version
teleport-pagerduty v16.2.0 git:teleport-pagerduty-v16.2.0-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이 실행되는 리눅스 사용자가 쓸 수 있고, 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-plugin-pagerduty-identity

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

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

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

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

tctl auth sign --user=access-plugin --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-plugin-pagerduty-identity

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

5단계/8. PagerDuty API 키 설정

PagerDuty 플러그인이 사건을 생성 및 수정하고 사용자, 서비스 및 대기 정책을 나열하는 데 사용할 API 키를 생성합니다.

PagerDuty 대시보드에서 통합 → API 액세스 키로 이동하여 새 API 키 생성을 클릭합니다. 키 설명을 추가합니다, 예: "Teleport 통합". "읽기 전용 API 키"를 선택 해제합니다. 로컬 컴퓨터의 파일에 키를 복사합니다. 나중에 플러그인 구성 파일에서 이 키를 사용할 것입니다.

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

teleport:
  address: ""                 # Teleport 인증 서버 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가 될 것입니다.

신뢰할 수 있는 링크를 통해 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 필드를 할당할 수 있습니다.

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

(!examples/resources/plugins/teleport-pagerduty-cloud.toml!)
(!examples/resources/plugins/teleport-pagerduty-helm-cloud.yaml!)

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

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

teleport-pagerduty start -d

DEBU DEBUG logging enabled logrus/exported.go:117

INFO Starting Teleport Access PagerDuty extension 0.1.0-dev.1: pagerduty/main.go:124

DEBU Checking Teleport server version pagerduty/main.go:226

DEBU Starting a request watcher... pagerduty/main.go:288

DEBU Starting PagerDuty API health check... pagerduty/main.go:170

DEBU Starting secure HTTPS server on :8081 utils/http.go:146

DEBU Watcher connected pagerduty/main.go:252

DEBU PagerDuty API health check finished ok pagerduty/main.go:176

DEBU Setting up the webhook extensions pagerduty/main.go:178

플러그인을 실행합니다:

docker run -v <path-to-config>:/etc/teleport-pagerduty.toml public.ecr.aws/gravitational/teleport-plugin-pagerduty:16.2.0 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 사용자 myuser로서 editor 역할에 대한 액세스 요청을 생성합니다:

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

tctl request create myuser --roles=editor

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

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

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

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

INFO   Successfully created PagerDuty incident pd_incident_id:00000000000000
pd_service_name:Teleport Access Request Notifications
request_id:00000000-0000-0000-0000-000000000000 request_op:put
request_state:PENDING pagerduty/app.go:366

PagerDuty에서 액세스 요청에 대한 정보를 포함한 새로운 사건을 확인할 수 있습니다:

요청 해결

접근 요청 메시지를 수신하면 링크를 클릭하여 Teleport를 방문하고 요청을 승인하거나 거부하세요:

명령줄에서도 접근 요청을 검토할 수 있습니다:

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   Successfully submitted a request approval
pd_user_email:myuser@example.com pd_user_name:My User
request_id:00000000-0000-0000-0000-000000000000 request_op:put
request_state:PENDING pagerduty/app.go:511

귀하의 액세스 요청은 승인으로 표시될 것입니다:

tsh requests ls
ID User Roles Created (UTC) Status------------------------------------ ------------------ --------- ------------------- --------00000000-0000-0000-0000-000000000000 myuser@example.com demo-role 12 Aug 22 18:30 UTC APPROVED

8단계/8. systemd 설정

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

생산에서는 init 시스템과 함께 Teleport 플러그인 데몬을 시작하는 것이 좋습니다. 다음은 systemd에 대한 권장 Teleport 플러그인 서비스 단위 파일입니다:

(!examples/systemd/plugins/teleport-pagerduty.service!)

이를 /usr/lib/systemd/system/ 또는 systemd에서 지원하는 다른 단위 파일 로드 경로teleport-pagerduty.service라는 이름으로 저장합니다.

플러그인을 활성화하고 시작합니다:

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