Jira 접근 요청 플러그인 실행 방법 | Teleport 공식 기술 문서 한국판 by 인포그랩

Jira 접근 요청 플러그인 실행 방법

이 가이드는 Teleport 접근 요청 플러그인을 Jira에 설정하는 방법을 설명합니다. Teleport의 Jira 통합을 통해 Teleport 접근 요청을 Jira 문제로 관리할 수 있습니다.

Teleport Jira 플러그인은 Jira 프로젝트 보드를 Teleport 클러스터에서 처리되는 접근 요청과 동기화합니다. Teleport 내에서 접근 요청의 상태를 변경하면 플러그인이 보드를 업데이트합니다. 그리고 보드에서 접근 요청의 상태를 업데이트하면, 플러그인은 잘못된 접근 요청을 수정하기 위해 플러그인에서 실행되는 Jira 웹훅에 알립니다.

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

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

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

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

전제 조건

실행 중인 Teleport 클러스터. Teleport를 시작하려면 가입하기 무료 체험판을 이용해 보세요.
tctl 관리 도구 및 tsh 클라이언트 도구 버전 >= 16.2.0.

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

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

애플리케이션과 웹훅을 생성할 수 있는 권한이 있는 Jira 계정이 필요합니다.
Jira 웹훅을 위한 등록된 도메인 이름이 필요합니다. Jira는 프로젝트 보드의 변경 사항을 웹훅에 알립니다.
Jira 플러그인을 실행할 환경이 필요합니다. 이는 다음 중 하나여야 합니다:
- 포트 80과 8081이 열려 있는 리눅스 가상 머신과 호스트에 접근할 수 있는 수단 (예: OpenSSH와 SSH 포트가 워크스테이션에 노출된 경우)
- 클라우드 제공업체를 통해 배포된 Kubernetes 클러스터. 이 가이드는 LoadBalancer 서비스 통해 Jira 플러그인으로 트래픽을 허용하는 방법을 보여주므로, 귀하의 환경은 이 유형의 서비스를 지원해야 합니다.
플러그인에서 운영하는 Jira 웹훅에 대한 TLS 자격 증명을 제공할 수 있는 수단이 필요합니다.
- 리눅스 서버에서 플러그인을 실행하는 경우, 플러그인이 접근할 수 있는 디렉토리에 TLS 자격 증명을 제공해야 합니다.
- 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단계/7. RBAC 리소스 정의

역할 접근 요청 활성화

Jira 플러그인을 설정하기 전에, Teleport 클러스터에서 역할 접근 요청을 활성화해야 합니다.

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.

editor-request-rbac.yaml라는 파일을 생성하고 다음 내용을 추가하세요:

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

정의한 역할을 생성하세요:

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

editor-requester 역할을 가진 사용자들로부터 요청을 검토할 수 있도록
editor-reviewer 역할을 자신의 계정에 할당하세요.

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

로컬 사용자의 역할을 콤마로 구분된 목록으로 가져옵니다:
```
ROLES=$(tsh status -f json | jq -r '.active.roles | join(",")')
```

로컬 사용자를 편집하여 새로운 역할을 추가합니다:

tctl users update $(tsh status -f json | jq -r '.active.username') \  --set-roles "${ROLES?},editor-reviewer"

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

github 인증 커넥터를 가져옵니다:
```
tctl get github/github --with-secrets > github.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 github.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 github.yaml 파일을 제거해야 합니다.
github.yaml을 편집하고 teams_to_roles 섹션에 editor-reviewer을 추가합니다.

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

여기에 예시가 있습니다:
```
  teams_to_roles:
    - organization: octocats
      team: admins
      roles:
        - access
+       - editor-reviewer
```
변경 사항을 적용합니다:
```
tctl create -f github.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 assum 하기 위해 다시 로그인합니다.

saml 구성 리소스를 가져옵니다:
```
tctl get --with-secrets saml/mysaml > saml.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 saml.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 saml.yaml 파일을 제거해야 합니다.
saml.yaml을 편집하고 attributes_to_roles 섹션에 editor-reviewer을 추가합니다.

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

여기에 예시가 있습니다:
```
  attributes_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - editor-reviewer
```
변경 사항을 적용합니다:
```
tctl create -f saml.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

oidc 구성 리소스를 가져옵니다:
```
tctl get oidc/myoidc --with-secrets > oidc.yaml
```
--with-secrets 플래그는 spec.signing_key_pair.private_key의 값을 oidc.yaml 파일에 추가합니다. 이 키는 민감한 값을 포함하고 있기 때문에, 리소스를 업데이트한 후 즉시 oidc.yaml 파일을 제거해야 합니다.
oidc.yaml을 편집하고 claims_to_roles 섹션에 editor-reviewer을 추가합니다.

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

여기에 예시가 있습니다:
```
  claims_to_roles:
    - name: "groups"
      value: "my-group"
      roles:
        - access
+       - editor-reviewer
```
변경 사항을 적용합니다:
```
tctl create -f oidc.yaml
```
Teleport 클러스터에서 로그아웃한 후 새로운 역할을 asum 하기 위해 다시 로그인합니다.

editor-requester 역할을 가진 사용자 myuser를 생성하세요. 이 사용자는
editor 역할을 요청하지 않는 한 클러스터 구성을 편집할 수 없습니다:

tctl users add myuser --roles=editor-requester

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

이 가이드의 후반부에서 myuser가 editor 역할을 요청할 것이며,
이를 통해 요청을 검토할 수 있습니다.

플러그인용 사용자 및 역할 생성

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

access-plugin이라는 사용자와 역할을 정의하려면 아래 내용을 access-plugin.yaml이라는 파일에 추가하세요:

kind: role
version: v5
metadata:
  name: access-plugin
spec:
  allow:
    rules:
      - resources: ['access_request']
        verbs: ['list', 'read', 'update']
      - resources: ['access_plugin_data']
        verbs: ['update']
---
kind: user
metadata:
  name: access-plugin
spec:
  roles: ['access-plugin']
version: v2

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

tctl create -f access-plugin.yaml

모든 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_USER=$(tsh status --format=json | jq -r .active.username)
tctl get users/${TELEPORT_USER?} > myuser.yaml

myuser.yaml을 편집하여 방금 생성한 역할을 포함합니다:

  roles:
   - access
   - auditor
   - editor
+  - access-plugin-impersonator

변경 사항을 적용합니다:

tctl create -f myuser.yaml

Teleport 클러스터에서 로그아웃한 후 다시 로그인하세요. 이제 access-plugin 역할 및 사용자에 대해 서명된 인증서를 생성할 수 있습니다.

2단계/7. Teleport Jira 플러그인 설치

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

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

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

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

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

teleport-jira version
teleport-jira v16.2.0 git:teleport-jira-v16.2.0-fffffffff go1.22

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

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

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

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

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

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

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

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

teleport-jira version
teleport-jira v16.2.0 git:teleport-jira-v16.2.0-fffffffff go1.22

Helm이 Teleport Helm 저장소에 호스팅된 차트를 설치할 수 있도록 허용하세요:

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

원격 저장소에서 차트의 캐시를 업데이트하세요:

helm repo update

3단계/7. 접근 플러그인 ID 내보내기

플러그인에게 Teleport ID 파일에 대한 접근을 허용하십시오. 우리는 기계 ID를 사용하는 것이 짧은 수명의 ID 파일을 생성하므로 더 안전하다고 권장합니다. 하지만 데모 배포에서는 tctl로 긴 수명의 ID 파일을 생성할 수 있습니다:

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-slack-identity

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

이제 /opt/machine-id 아래에 identity 파일이 보이거나 teleport-plugin-slack-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-jira-identity

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

4단계/7. Jira 프로젝트 설정

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

접근 요청 관리를 위한 프로젝트 생성

Jira에서 상단 내비게이션 바를 찾아 프로젝트 -> 프로젝트 생성을 클릭하십시오. 템플릿으로 Kanban을 선택한 후 템플릿 사용을 선택하십시오. 회사 관리 프로젝트 선택을 클릭합니다.

프로젝트 이름을 입력할 수 있는 화면이 나타납니다. 이 가이드에서는 "Teleport 접근 요청"이라는 프로젝트 이름을 사용하는 것으로 가정하며, 기본적으로 키는 TAR를 수신합니다.

"저장소, 문서 및 기타 연결"이 해제되어 있는지 확인한 후 프로젝트 생성을 클릭하십시오.

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

대기 중
승인됨
거부됨
만료

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

귀하의 프로젝트 보드에 이러한 열(및 오직 이 열)만 포함되어 있어야 하며, 각 열은 동일한 이름의 상태를 가져야 합니다. 그렇지 않으면 Jira 접근 요청 플러그인이 예기치 않은 방식으로 작동할 수 있습니다. 모든 다른 열과 상태를 제거하십시오.

보드로 돌아가기를 클릭하여 변경 사항을 검토하십시오.

요청 ID 필드 설정

Teleport Jira 플러그인은 Teleport 접근 요청 프로젝트의 작업이 개별 접근 요청을 추적하는 데 사용하는 teleportAccessRequestId라는 필드를 포함할 것을 기대합니다. 이는 사용자가 접근 요청을 변조하거나 위조하는 것을 방지합니다.

teleportAccessRequestId 필드를 설정하려면 왼쪽 내비게이션 바에서 프로젝트 설정을 클릭한 다음 문제 -> 필드를 클릭하십시오.

작업 메뉴에서 필드 편집을 클릭하십시오. 왼쪽 사이드바에서 사용자 정의 필드 탭을 클릭한 후 사용자 정의 필드 생성을 클릭합니다. teleportAccessRequestId라는 이름으로 짧은 텍스트 필드를 추가하십시오. 해당 필드를 이 화면과 연결하기 위해 기본 화면 옆의 체크박스를 클릭하십시오. 업데이트를 클릭합니다.

다음으로, 사용자 정의 필드를 Teleport 접근 요청 프로젝트에 추가하십시오. 프로젝트 > **Teleport 접근 요청(TAR)**으로 이동한 후 프로젝트 설정을 클릭하십시오. 왼쪽 사이드바에서 문제 -> 유형을 클릭한 다음 작업 > 필드를 클릭합니다. 필드 선택이라는 드롭다운 메뉴를 찾아 방금 추가한 teleportAccessRequestId 필드를 선택하십시오.

Jira API 토큰 가져오기

Teleport 접근 요청 플러그인이 Jira 프로젝트에 변경을 가하는 데 사용하는 API 토큰을 가져옵니다. 화면 오른쪽 상단의 기어 메뉴를 클릭한 다음 Atlassian 계정 설정을 클릭하십시오. 보안 > API 토큰 생성 및 관리 > API 토큰 생성을 클릭합니다.

어떤 레이블이든 선택하고 복사를 클릭하십시오. API 토큰을 나중에 Jira 플러그인을 구성할 때 사용할 수 있도록 편리한 위치(예: 비밀번호 관리자 또는 로컬 텍스트 문서)에 붙여넣으십시오.

Jira 웹훅 설정

이제 Teleport Jira 플러그인이 프로젝트를 관리하는 데 사용하는 API 키가 생성되었으므로, 웹훅을 생성하여 Jira가 프로젝트가 업데이트될 때 Teleport Jira 플러그인에 알리도록 설정합니다.

Jira로 돌아가십시오. 화면 오른쪽 상단의 기어 메뉴를 클릭하십시오. 시스템 > 웹훅 > 웹훅 생성을 클릭합니다.

"이름" 필드에 "Teleport 접근 요청 플러그인"을 입력하십시오. "URL" 필드에 앞서 생성한 플러그인 도메인 이름과 포트 8081을 입력하십시오.

"이름" 필드에 "Teleport 접근 요청 플러그인"을 입력하십시오. "URL" 필드에 앞서 생성한 플러그인 도메인 이름과 포트 443을 입력하십시오.

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

생성을 클릭하십시오.

5단계/7. Jira 접근 요청 플러그인 구성

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

구성 파일 생성

Teleport Jira 플러그인은 TOML 형식의 구성 파일을 사용합니다. 다음 명령을 실행하여 보일러플레이트 구성을 생성하십시오(구성 파일이 /etc/teleport-jira.toml에 놓이지 않으면 플러그인이 실행되지 않음):

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

이렇게 하면 아래와 같은 구성 파일이 생성됩니다:

(!examples/resources/plugins/teleport-jira-cloud.toml!)

Jira 플러그인에 대한 Helm 차트는 플러그인을 구성하는 YAML 값 파일을 사용합니다. 로컬 워크스테이션에서 다음 예제에 따라 teleport-jira-helm.yaml이라는 파일을 만듭니다:

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

구성 파일 편집

Teleport Jira 플러그인에 대해 생성된 구성 파일을 열고 다음 필드를 업데이트하십시오:

[teleport]

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

`jira`

url: Jira 테넌트의 URL, 예: https://[your-jira].atlassian.net.

username: API 토큰을 생성할 때 로그인한 사용자 이름입니다.

api_token: 이전에 가져온 Jira API 토큰입니다.

project: 우리 프로젝트의 프로젝트 키는 TAR입니다.

issue_type은 "작업"으로 남겨두거나 필드를 제거할 수 있습니다. "작업"은 기본값입니다.

`http`

[http] 설정 블록은 플러그인의 웹훅이 작동하는 방식을 설명합니다.

listen_addr는 플러그인이 수신하는 주소를 나타내며, 기본값은 :8081입니다. 앞서 가이드에서 추천한 대로 플러그인 호스트에서 포트 8081을 열어두었다면 이 옵션은 설정하지 않아도 됩니다.

public_addr는 웹훅의 공용 주소입니다. 이는 앞서 생성한 DNS A 레코드에 추가한 도메인 이름입니다.

https_key_file 및 https_cert_file은 이전에 Caddy를 통해 생성한 개인 키 및 인증서에 해당합니다. 다음 값을 사용하고, example.com를 플러그인에 대해 생성한 도메인 이름으로 지정하십시오:

https_key_file:

/var/teleport-jira/tls/certificates/acme-v02.api.letsencrypt.org-directory/example.com/example.com.key

https_cert_file:

/var/teleport-jira/tls/certificates/acme-v02.api.letsencrypt.org-directory/example.com/example.com.crt

`jira`

url: Jira 테넌트의 URL, 예: https://[your-jira].atlassian.net.

username: API 토큰을 생성할 때 로그인한 사용자 이름입니다.

apiToken: 이전에 가져온 API 토큰입니다.

project: 우리 프로젝트의 프로젝트 키는 TAR입니다.

issueType은 "작업"으로 남겨두거나 필드를 제거할 수 있습니다. "작업"은 기본값입니다.

`http`

http 설정 블록은 플러그인의 웹훅이 작동하는 방식을 설명합니다.

publicAddress: 웹훅의 공용 주소입니다. 이는 웹훅을 위해 생성한 도메인 이름입니다. (우리는 나중에 이 도메인 이름에 대한 DNS 레코드를 생성합니다.)

tlsFromSecret: 웹훅에 대한 TLS 자격 증명을 포함한 Kubernetes 비밀의 이름입니다. teleport-plugin-jira-tls를 사용하십시오. 이 비밀을 TLS 자격 증명으로 채우는 Certificate 리소스를 나중에 생성할 것입니다.

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

구성을 완료한 후 플러그인을 실행하고 Jira를 기반으로 한 접근 요청 흐름을 테스트할 수 있습니다:

리눅스 호스트에서 다음을 실행하십시오:

sudo teleport-jira start
INFO   Teleport Jira Plugin 12.1.1 시작됨 jira/app.go:112INFO   플러그인이 준비되었습니다 jira/app.go:142

Teleport Jira 플러그인에 대한 Helm 차트를 설치하십시오:

helm install teleport-plugin-jira teleport/teleport-plugin-jira \  --namespace teleport \  --values values.yaml \  --version 16.2.0

웹훅 도메인 이름과 Jira 플러그인 Helm 차트로 생성된 로드 밸런서의 주소를 연결하는 DNS 레코드를 생성하십시오.

로드 밸런서가 도메인 이름이나 IP 주소를 가지고 있는지 확인하십시오:

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

EXTERNAL-IP 필드가 도메인 이름 값인 경우, 웹훅의 도메인 이름이 로드 밸런서의 도메인 이름을 가리키도록 CNAME 레코드를 생성하십시오.

EXTERNAL-IP 필드의 값이 IP 주소인 경우, 대신 DNS의 A 레코드를 생성하십시오.

그런 다음 Jira 플러그인이 HTTPS를 위해 서명된 TLS 자격 증명을 생성해야 하며, 이는 Kubernetes 비밀로 작성될 것으로 예상됩니다.

웹훅 상태 확인

GET 요청을 /status 엔드포인트에 보내어 Jira 웹훅이 시작되었는지 확인하십시오. 웹훅이 실행되고 있다면, 본문이 없는 200 상태 코드를 반환할 것입니다:

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

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

접근 요청 생성

앞서 생성한 myuser 사용자로 클러스터에 로그인하고 접근 요청을 생성하십시오:

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

tctl request create myuser --roles=editor

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

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

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

요청을 생성하면 Teleport 접근 요청 보드의 "대기 중" 열에 새로운 작업이 표시됩니다:

요청 해결

새 접근 요청에 해당하는 카드를 "거부됨" 열로 이동시키고, 카드를 클릭한 다음 Teleport로 이동하십시오. 접근 요청이 거부되었음을 알 수 있습니다.

접근 요청 감사

Jira 프로젝트 보드에 접근할 수 있는 모든 사용자가 보드에 반영된 접근 요청의 상태를 수정할 수 있습니다. 올바른 사용자가 올바른 요청을 검토하고 있는지 확인하기 위해 Teleport 감사 로그를 확인할 수 있습니다.

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

7단계/7. systemd 설정

이 단계는 Teleport Jira 플러그인을 리눅스 머신에서 실행하는 경우에만 해당됩니다.

생산 환경에서는 init 시스템인 systemd를 통해 Teleport 플러그인 데몬을 실행하는 것을 추천합니다. 이는 systemd에 대한 권장 Teleport 플러그인 서비스 단위 파일입니다:

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

이 파일을 teleport-jira.service 또는 systemd에서 지원하는 다른 단위 파일 로드 경로로 저장하십시오.

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

Teleport 원문 보기