이 가이드는 Jira용 Teleport Access Request 플러그인을 설정하는 방법을 설명합니다. Teleport의 Jira 통합을 사용하면 Jira 이슈로 Access Request를 관리할 수 있습니다.

작동 방식#

Teleport Jira 플러그인은 Jira 프로젝트 보드를 Teleport 클러스터에서 처리된 Access Request와 동기화합니다. Teleport 내에서 Access Request 상태를 변경하면 플러그인이 보드를 업데이트합니다. 보드에서 Access Request 상태를 업데이트하면, 플러그인이 실행하는 Jira 웹훅에 알림이 전송되어 Teleport의 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.

• 애플리케이션 및 웹훅을 생성할 권한이 있는 Jira 계정.

• Jira 웹훅용 등록된 도메인 이름. Jira는 프로젝트 보드의 변경 사항을 웹훅에 알립니다.

• Jira 플러그인을 실행할 환경. 다음 중 하나입니다:

  • 포트 80과 8081이 열려 있고 호스트에 접근할 수 있는 수단(예: 워크스테이션에 SSH 포트가 노출된 OpenSSH)이 있는 Linux 가상 머신.
  • 클라우드 공급자를 통해 배포된 Kubernetes 클러스터. 이 가이드는 LoadBalancer 서비스를 통해 Jira 플러그인으로 트래픽을 허용하는 방법을 보여주므로, 환경이 이 유형의 서비스를 지원해야 합니다.

• 플러그인이 실행하는 Jira 웹훅에 TLS 자격 증명을 제공하는 수단. TLS 인증서는 자체 서명이어서는 안 됩니다. 예를 들어, ACME 클라이언트를 사용하여 Let's Encrypt에서 웹훅의 TLS 자격 증명을 얻을 수 있습니다.

  • Linux 서버에서 플러그인을 실행하는 경우, 플러그인이 접근할 수 있는 디렉터리에 TLS 자격 증명을 제공해야 합니다.
  • Kubernetes에서 플러그인을 실행하는 경우, 플러그인이 읽을 수 있는 시크릿에 이 자격 증명을 써야 합니다. 이 가이드에서는 시크릿 이름이 teleport-plugin-jira-tls라고 가정합니다.

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단계. RBAC 리소스 정의#

Jira 플러그인을 설정하기 전에, Teleport 클러스터에서 Role Access Request를 활성화해야 합니다.

For the purpose of this guide, we will define an editor-requester role, which can request the built-in editor role, and an editor-reviewer role that can review requests for the editor role.

Create a file called editor-request-rbac.yaml with the following content:

kind: role
version: v7
metadata:
  name: editor-reviewer
spec:
  allow:
    review_requests:
      roles: ['editor']
---
kind: role
version: v7
metadata:
  name: editor-requester
spec:
  allow:
    request:
      roles: ['editor']
      thresholds:
        - approve: 1
          deny: 1

Create the roles you defined:

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

(!docs/pages/includes/create-role-using-web.mdx!)

Allow yourself to review requests by users with the editor-requester role by assigning yourself the editor-reviewer role.

(!docs/pages/includes/add-role-to-user.mdx role="editor-reviewer"!)

Create a user called myuser who has the editor-requester role. This user cannot edit your cluster configuration unless they request the editor role:

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

tctl will print an invitation URL to your terminal. Visit the URL and log in as myuser for the first time, registering credentials as configured for your Teleport cluster.

Later in this guide, you will have myuser request the editor role so you can review the request using the Teleport plugin.

2/8단계. Teleport Jira 플러그인 사용자 정의#

플러그인에 필요한 권한은 사전 설정된 access-plugin 역할에 구성되어 있습니다. 플러그인에 대한 자격 증명을 생성하려면, Machine ID 봇 사용자 또는 일반 Teleport 사용자를 정의합니다.

$ tctl bots update my-bot --add-roles access-plugin

kind: user
metadata:
  name: access-plugin
spec:
  roles: ['access-plugin']
version: v2
---
kind: role
version: v7
metadata:
  name: access-plugin-impersonator
spec:
  allow:
    impersonate:
      roles:
      - access-plugin
      users:
      - access-plugin

$ tctl create -f access-plugin-impersonator.yaml
user "access-plugin" has been created
role "access-plugin-impersonator" has been created

3/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-jira-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-jira-identity

4/8단계. Teleport Jira 플러그인 설치#

아래 지침에 따라 Teleport Jira 플러그인을 설치합니다. 플러그인을 호스트(예: EC2 인스턴스)에 배포하는지 Kubernetes 클러스터에 배포하는지에 따라 다릅니다.

Teleport Jira 플러그인은 Jira와 Teleport Proxy Service(또는 Teleport Enterprise Cloud 테넌트) 모두에 접근할 수 있는 호스트 또는 Kubernetes 클러스터에서 실행해야 합니다.

5/8단계. Jira 프로젝트 설정#

이 섹션에서는 Teleport 사용자가 Access Request를 생성하거나 업데이트할 때 Teleport 플러그인이 수정할 수 있는 Jira 프로젝트를 생성합니다. 그런 다음 플러그인은 Jira 웹훅을 사용하여 보드 상태를 모니터링하고 생성한 티켓의 변경 사항에 응답합니다.

Access Request 관리를 위한 프로젝트 생성#

Jira의 상단 탐색 바에서 프로젝트 -> 프로젝트 생성을 클릭합니다. 템플릿으로 Kanban을 선택한 다음 템플릿 사용을 클릭합니다. 회사 관리형 프로젝트 선택을 클릭합니다.

프로젝트 이름을 입력할 수 있는 화면이 표시됩니다. 이 가이드에서는 프로젝트가 "Teleport Access Requests"라고 가정하며, 기본적으로 키 TAR이 할당됩니다.

"저장소, 문서 등 연결"이 해제되어 있는지 확인한 다음 프로젝트 생성을 클릭합니다.

새 보드의 오른쪽 상단에 있는 세 점 메뉴에서 보드 설정을 클릭한 다음 열을 클릭합니다. 다음 네 가지 상태가 포함되도록 보드의 상태를 편집합니다:

1. Pending
2. Approved
3. Denied
4. Expired

각 상태와 동일한 이름의 열을 생성합니다. 결과는 다음과 같아야 합니다:

보드로 돌아가기를 클릭하여 변경 사항을 검토합니다.

Jira API 토큰 가져오기#

Access Request 플러그인이 Jira 프로젝트를 변경하는 데 사용할 API 토큰을 얻습니다. 화면 오른쪽 상단의 톱니바퀴 메뉴를 클릭한 다음 Atlassian 계정 설정을 클릭합니다. 보안 > API 토큰 생성 및 관리 > API 토큰 생성을 클릭합니다.

레이블을 선택하고 복사를 클릭합니다. 나중에 이 가이드에서 Jira 플러그인을 설정할 때 사용할 수 있도록 API 토큰을 편리한 위치(예: 비밀번호 관리자 또는 로컬 텍스트 문서)에 붙여넣습니다.

Jira 웹훅 설정#

Teleport Jira 플러그인이 프로젝트를 관리하는 데 사용할 API 키를 생성했으므로, 웹훅을 생성하여 프로젝트가 업데이트될 때 Jira가 Teleport Jira 플러그인에 알릴 수 있도록 활성화합니다.

Jira로 돌아갑니다. 화면 오른쪽 상단의 톱니바퀴 메뉴를 클릭합니다. 시스템 > WebHooks > WebHook 생성을 클릭합니다.

웹훅은 이슈가 생성, 업데이트 또는 삭제될 때만 알림을 받아야 합니다. 다른 모든 박스는 비워 둘 수 있습니다.

생성을 클릭합니다.

6/8단계. Jira Access Request 플러그인 설정#

이전에 Jira 플러그인이 Teleport와 Jira API에 연결하는 데 사용하는 자격 증명을 가져왔습니다. 이제 이 자격 증명을 사용하고 이전에 설정한 주소에서 Jira 웹훅을 실행하도록 플러그인을 설정합니다.

설정 파일 생성#

$ teleport-jira configure | sudo tee /etc/teleport-jira.toml > /dev/null

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

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

설정 파일 편집#

Teleport Jira 플러그인을 위해 생성된 설정 파일을 열고 다음 필드를 업데이트합니다:

[teleport]

Jira 플러그인은 이 섹션을 사용하여 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

7/8단계. Jira 플러그인 실행#

설정을 완료한 후, 이제 플러그인을 실행하고 Jira 기반 Access Request 흐름을 테스트할 수 있습니다:

$ sudo teleport-jira start
INFO   Starting Teleport Jira Plugin 12.1.1: jira/app.go:112
INFO   Plugin is ready jira/app.go:142

$ helm install teleport-plugin-jira teleport/teleport-plugin-jira \
  --namespace teleport \
  --values values.yaml \
  --version (=teleport.plugin.version=)

$ kubectl -n teleport get services/teleport-plugin-jira
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                          PORT(S)                      AGE
teleport-plugin-jira   LoadBalancer   10.100.135.75   abc123.us-west-2.elb.amazonaws.com   80:30625/TCP,443:31672/TCP   134m

웹훅 상태 확인#

/status 엔드포인트로 GET 요청을 보내 Jira 웹훅이 서비스를 시작했는지 확인합니다. 웹훅이 실행 중이면 문서 본문 없이 200 상태 코드를 반환합니다:

$ curl -v https://:8081/status 2>&1 | grep "^< HTTP/2"
< HTTP/2 200

$ curl -v https://:443/status 2>&1 | grep "^< HTTP/2"
< HTTP/2 200

Access Request 생성#

이전에 생성한 myuser 사용자로 클러스터에 로그인하고 Access Request를 생성합니다:

요청을 생성하면 Access Requests 보드의 "Pending" 열에 새 작업이 표시됩니다:

요청 해결#

새 Access Request에 해당하는 카드를 "Denied" 열로 이동한 다음 카드를 클릭하고 Teleport로 이동합니다. Access Request가 거부된 것을 확인할 수 있습니다.

8/8단계. systemd 설정#

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

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

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

$ sudo systemctl enable teleport-jira
$ sudo systemctl start teleport-jira

문제 해결#