Teleport의 PagerDuty 통합을 사용하면, 엔지니어들은 공격 벡터가 될 수 있는 영구적인 관리자 권한 없이도 인시던트를 신속하게 해결하는 데 필요한 인프라에 접근할 수 있습니다. 이 가이드는 PagerDuty용 Teleport Access Request 플러그인 설정 방법을 설명합니다.

작동 방식#

Teleport의 PagerDuty 통합을 사용하면 Teleport Role Access Request를 PagerDuty 인시던트로 처리하고, 적절한 온콜 팀에 알리고, Teleport를 통해 요청을 승인하거나 거부할 수 있습니다. 또한 요청을 하는 사용자가 인시던트에 영향을 받는 서비스의 온콜 팀에 있는 경우 Role Access Request를 자동으로 승인하도록 플러그인을 설정할 수 있습니다.

사전 요구사항#

• A running Teleport Enterprise cluster. If you want to get started with Teleport, sign up for a free trial or set up a demo environment.

• The tctl and tsh clients.

  Installing `tctl` and `tsh` clients

  1. Determine the version of your Teleport cluster. The tctl and tsh clients must be at most one major version behind your Teleport cluster version. Send a GET request to the Proxy Service at /v1/webapi/find and use a JSON query tool to obtain your cluster version. Replace with the web address of your Teleport Proxy Service:

     $ TELEPORT_DOMAIN=
     $ TELEPORT_VERSION="$(curl -s https://$TELEPORT_DOMAIN/v1/webapi/find | jq -r '.server_version')"
     

  2. Follow the instructions for your platform to install tctl and tsh clients:

Recommended: Configure Machine & Workload Identity to provide short-lived Teleport credentials to the plugin. Before following this guide, follow a Machine & Workload Identity deployment guide to run the tbot binary on your infrastructure.

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

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

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

To check that you can connect to your Teleport cluster, sign in with tsh login, then verify that you can run tctl commands using your current credentials.

For example, run the following command, assigning to the domain name of the Teleport Proxy Service in your cluster and to your Teleport username:

$ tsh login --proxy= --user=
$ tctl status
# Cluster  (=teleport.url=)
# Version  (=teleport.version=)
# CA pin   (=presets.ca_pin=)

If you can connect to the cluster and run the tctl status command, you can use your current credentials to run subsequent tctl commands from your workstation. If you host your own Teleport cluster, you can also run tctl commands on the computer that hosts the Teleport Auth Service for full permissions.

1/8단계. 서비스 생성#

PagerDuty 플러그인을 시연하기 위해 PagerDuty에서 두 개의 서비스를 생성합니다. 각 서비스에 대해 "이름" 필드만 채우고 다른 모든 설정 화면은 건너뛰어 기본값을 유지합니다:

• Teleport Access Request Notifications
• My Critical Service

특정 사용자가 Access Request를 생성할 때 Teleport Access Request Notifications 서비스에서 인시던트를 생성하도록 PagerDuty 플러그인을 설정합니다.

My Critical Service의 온콜 팀에 있는 사용자(이 경우 PagerDuty 사용자)의 경우, 서비스의 인시던트를 신속하게 조사할 수 있도록 Access Request를 자동으로 승인하도록 PagerDuty 플러그인을 설정합니다.

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

Teleport PagerDuty 플러그인은 Teleport Auth Service에서 Access Request 이벤트를 수신하고, 이 이벤트를 기반으로 PagerDuty API와 상호작용합니다.

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

• 내장된 editor 역할을 요청할 수 있는 editor-requester 역할. 사용자가 이 역할을 요청할 때마다 PagerDuty 인시던트를 열어 Teleport Access Request Notifications 서비스의 온콜 팀에 알리도록 이 역할을 설정합니다.
• demo-role이라는 역할을 요청할 수 있는 demo-role-requester 역할. 요청을 하는 사용자가 My Critical Service의 온콜 팀에 있을 때마다 이 요청을 자동 승인하도록 PagerDuty 플러그인을 설정합니다.
• PagerDuty 플러그인이 Teleport Auth Service에 인증하기 위해 가정하는 access-plugin이라는 사용자 및 역할. 이 역할은 My Critical Service의 온콜 팀에 있는 사용자의 Access Request를 자동으로 승인할 권한을 갖게 됩니다.
• 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 Service는 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' has been created
role '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 어노테이션을 읽습니다. 요청을 하는 사용자가 어노테이션의 값으로 나열된 서비스의 온콜 팀에 있으면, 플러그인은 자동으로 Access Request를 승인합니다.

이 경우 PagerDuty 플러그인은 My Critical Service의 온콜 팀에 있는 모든 사용자의 요청을 승인합니다.

리소스를 생성합니다:

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

access-plugin#

Teleport의 Access Request 플러그인은 Access Request를 나열, 읽기, 업데이트할 권한이 있는 사용자로 Teleport 클러스터에 인증합니다. 이를 통해 플러그인은 Teleport Auth Service에서 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 역할에는 demo-role이 값으로 있는 allow.review_requests.roles 필드가 포함되어 있습니다. 이렇게 하면 플러그인이 demo-role 역할에 대한 요청을 검토할 수 있습니다.

또한 access-plugin 역할을 My Critical Service와 연결된 Access Request만 검토하도록 제한하고 있습니다. 이를 위해 review_requests.where 필드에 조건식을 정의했습니다. 이 식은 플러그인이 pagerduty_services 키와 My Critical Service 값이 있는 어노테이션이 요청에 포함되지 않으면 demo-role 요청을 검토할 수 없다는 것을 나타냅니다.

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

$ tctl create -f access-plugin.yaml

access-plugin-impersonator#

모든 Teleport 사용자와 마찬가지로, Teleport Auth Service는 단기 TLS 자격 증명을 발급하여 access-plugin 사용자를 인증합니다. 이 경우 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 역할에 대한 Access Request 수동 검토
• demo-role 역할에 대한 Access Request 생성

이 권한을 사용자에게 부여하려면, 앞서 정의한 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 플러그인을 테스트하기 위해 이 사용자로 Access Request를 생성합니다:

$ tctl users add myuser --roles=editor-requester

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

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

4/8단계. 액세스 플러그인 ID 내보내기#

플러그인에 Teleport ID 파일 접근 권한을 부여합니다. 유출 시 위험도가 낮은 단기 ID 파일을 생성하기 위해 Machine ID를 사용하는 것을 권장하지만, 데모 배포에서는 tctl로 장기 ID 파일을 생성할 수 있습니다:

services:
- type: identity
  destination:
    type: directory
    # For this guide, /opt/machine-id is used as the destination directory.
    # You may wish to customize this. Multiple outputs cannot share the same
    # destination.
    path: /opt/machine-id

services:
  - type: identity
    destination:
      type: kubernetes_secret
      name: teleport-plugin-pagerduty-identity

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

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

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

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

5/8단계. PagerDuty API 키 설정#

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

PagerDuty 대시보드에서 통합 → API 액세스 키로 이동하여 새 API 키 생성을 클릭합니다. 키 설명(예: "Teleport integration")을 추가합니다. "읽기 전용 API 키"의 체크를 해제합니다. 로컬 머신의 파일에 키를 복사합니다. 나중에 플러그인 설정 파일에서 이 키를 사용합니다.

6/8단계. PagerDuty 플러그인 설정#

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

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

teleport:
  address: ""                 # Teleport Auth Service GRPC API 주소
  identitySecretName: ""      # ID 시크릿 이름
  identitySecretPath: ""      # ID 시크릿 경로

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

아래 설명에 따라 /etc/teleport-pagerduty.toml의 설정 파일을 편집합니다:

[teleport]#

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

If you are providing credentials to the plugin using a tbot binary that runs on a Linux server, make sure the value of identity is the same as the path of the identity file you configured tbot to generate, /opt/machine-id/identity.

Configure the plugin to periodically reload the identity file, ensuring that it does not attempt to connect to the Teleport Auth Service with expired credentials.

Add the following to the teleport section of the configuration:

refresh_identity = true

[pagerduty]#

api_key를 이전에 생성한 PagerDuty API 키로 지정합니다.

user_email을 API 키와 연결된 PagerDuty 계정의 사용자 이메일 주소로 지정합니다. PagerDuty 플러그인이 새 인시던트를 생성하면, PagerDuty는 이 인시던트를 해당 사용자가 생성한 것으로 표시합니다.

최종 설정은 다음과 유사해야 합니다:

<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport-pagerduty-cloud.toml</code>)</p></div>

<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport-pagerduty-helm-cloud.yaml</code>)</p></div>

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

$ 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:(=teleport.version=) start

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

$ kubectl logs deploy/teleport-plugin-pagerduty

$ kubectl rollout restart deployment teleport-plugin-pagerduty

Access Request 생성#

Teleport 사용자 myuser로 editor 역할에 대한 Access Request를 생성합니다:

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에서 Access Request에 대한 정보가 포함된 새 인시던트가 표시됩니다:

요청 해결#

Once you receive an Access Request message, click the link to visit Teleport and approve or deny the request:

자동 승인 트리거#

Teleport 사용자로 demo-role 역할에 대한 Access Request를 생성합니다.

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

Access Request가 APPROVED로 표시됩니다:

$ 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 설정#

이 섹션은 Linux 호스트에서 Teleport PagerDuty 플러그인을 실행하는 경우에만 해당됩니다.

프로덕션 환경에서는 systemd와 같은 init 시스템을 통해 Teleport 플러그인 데몬을 시작하는 것을 권장합니다. systemd를 위한 권장 Teleport 플러그인 서비스 유닛 파일은 다음과 같습니다:

<div class="admonition note"><div class="admonition-title">Note</div><p>이 섹션의 내용은 원문 문서를 참조하세요. (<code>teleport-pagerduty.service</code>)</p></div>

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

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

$ sudo systemctl enable teleport-pagerduty
$ sudo systemctl start teleport-pagerduty

문제 해결#