Jenkins에 Machine ID 배포하기

Jenkins는 지속적인 통합 및 지속적인 배포(CI/CD) 파이프라인을 구축하는 데 자주 사용되는 오픈 소스 자동화 서버입니다.

이 가이드에서는 기존 Jenkins 파이프라인을 최소한의 변경으로 Machine ID를 활용하도록 마이그레이션하는 방법을 보여줍니다.

전제 조건

Jenkins와 Teleport를 사용하기 위해 필요한 도구는 다음과 같습니다.

실행 중인 Teleport 클러스터 버전 이상. Teleport를 시작하려면, 가입하기 위해 무료 평가판에 등록하거나 데모 환경 설정하기를 참조하세요.
tctl 관리 도구와 tsh 클라이언트 도구.

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

ssh OpenSSH 도구
Jenkins
당신의 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 명령어를 실행할 수도 있습니다.

아키텍처

시작하기 전에 Jenkins는 보안이 notoriously 어려운 도구라는 점을 언급해야 합니다. Machine ID는 여러분의 인프라를 보호하는 데 중요한 부분이지만, 그 자체만으로는 충분하지 않습니다. 아래에서는 여러분의 Jenkins 설치 보안을 개선하는 데 도움이 되는 기본 지침을 제공할 것입니다.

단일 호스트 배포

가장 간단한 Jenkins 배포는 컨트롤러(구성, 플러그인, UI를 저장하는 프로세스)와 에이전트(작업을 실행하는 프로세스)가 동일한 호스트에서 실행되는 경우입니다. 이 배포 모델은 시작하기 간단하지만, 단일 파이프라인 내의 jenkins 사용자가 손상되면 전체 CI/CD 인프라가 손상될 수 있습니다.

멀티호스트 배포

조금 더 복잡하지만 더 안전한 배포 방식은 Jenkins 컨트롤러와 에이전트를 다른 호스트에서 실행하고 특정 에이전트에 작업 부하를 고정하는 것입니다. 이 모델은 단순 배포보다 개선된 사항으로, 단일 파이프라인의 손상으로 인해 CI/CD 인프라의 일부만 영향을 받도록 제한할 수 있습니다.

최선의 실천

가능한 경우 두 번째 배포 모델을 사용하는 것을 강력히 권장하며, 가능할 경우 일시적인 호스트와 IAM 참여를 고려해야 합니다. 이 모델을 사용하여 Machine ID를 활용할 때는, 호스트당 Machine ID 봇을 생성하고 특정 파이프라인을 작업자로 고정하세요. 이렇게 하면 각 파이프라인에 서버 접근 범위를 최소화하고, 하나의 파이프라인이 손상될 경우 피해 범위를 줄이며, 악성 행동이 감지될 경우 파이프라인을 원격으로 감사하고 잠글 수 있습니다.

Jenkins 배포

1/2 단계 Machine ID 구성 및 시작

먼저 Machine ID에 대한 새 역할을 만들지 아니면 기존 역할을 사용할지 결정하세요. tctl get roles 명령을 실행하여 기존 역할을 검사할 수 있습니다.

아래 예제에서는 api-workers.yaml이라는 파일을 생성하고 다음 내용을 추가하여 api-workers라는 새 역할을 만들어 group: api라는 레이블과 Linux 사용자 jenkins로 노드에 로그인할 수 있도록 합니다.

kind: "role"
version: "v3"
metadata:
  name: "api-workers"
spec:
  allow:
    logins: ["jenkins"]
    node_labels:
      "group": "api"

클라이언트 컴퓨터에서 tsh를 사용하여 Teleport에 로그인한 후 tctl을 사용하세요.

tctl create -f api-workers.yaml
tctl bots add jenkins --roles=api-workers

Teleport Auth Server에 연결하고 tctl을 사용하여 시스템에서 어떤 역할이 있는지 확인하세요.

tctl create -f api-workers.yaml
tctl bots add jenkins --roles=api-workers

Machine ID를 사용하면 Linux 접근 제어 목록(ACL)을 사용하여 디스크의 인증서에 대한 접근을 제어할 수 있습니다. 이를 통해 Jenkins의 접근을 Machine ID가 발급하는 단기 인증서로 제한할 수 있습니다.

아래 예제에서는 teleport라는 Linux 사용자를 생성하여 Machine ID를 실행하지만, 단기 인증서는 Linux 사용자 jenkins로 디스크에 기록됩니다.

sudo adduser \    --disabled-password \    --no-create-home \    --shell=/bin/false \    --gecos "" \    teleport

tbot init 명령을 사용하여 필요한 디렉토리를 생성하고 초기화하세요.

sudo tbot init \    --destination-dir=/opt/machine-id \    --bot-user=teleport \    --owner=teleport:teleport \    --reader-user=jenkins

봇 데이터 디렉토리를 생성하고 Linux 사용자(예를 들어, teleport)에게 접근 권한을 부여합니다. tbot이 이 사용자로 실행됩니다.

봇 디렉토리를 생성하고 소유권을 teleport 사용자에게 할당합니다.
sudo mkdir -p /var/lib/teleport/bot
sudo chown teleport:teleport /var/lib/teleport/bot
teleport 사용자에게 디렉토리에 접근할 수 있는 권한을 부여합니다.
sudo chmod +x /var/lib/teleport /var/lib/teleport/bot

다음으로 각 Jenkins 워커의 백그라운드에서 Machine ID를 시작해야 합니다.

먼저 /etc/tbot.yaml에 대해 Machine ID의 구성 파일을 생성하세요.

version: v2
# "example.teleport.sh:443"를 여러분의 Teleport Proxy 또는 Teleport Cloud 테넌트의 주소로 바꾸세요.
proxy_server: "example.teleport.sh:443"
onboarding:
  join_method: "token"
  # `tctl bots add`를 실행했을 때 출력된 토큰 이름으로 필드 토큰을 바꾸세요.
  token: "00000000000000000000000000000000"
storage:
  type: directory
  path: /var/lib/teleport/bot
outputs:
  - type: identity
    destination:
      type: directory
      path: /opt/machine-id

`tbot` systemd 유닛 파일 생성

기본적으로, tbot는 데몬 모드에서 실행됩니다. 그러나 이를 Linux 호스트의 서비스 관리자 내에서 서비스로 구성해야 합니다. 서비스 관리자는 부팅 시 tbot를 시작하고 실패할 경우 다시 시작되도록 보장합니다. 이 안내서에서는 systemd를 시연하지만 tbot는 모든 일반적인 대안과 호환되어야 합니다.

tbot install systemd를 사용하여 systemd 서비스 파일을 생성합니다:

tbot install systemd \   --write \   --config /etc/tbot.yaml \   --user teleport \   --group teleport \   --anonymous-telemetry

다음 항목을 바꾸는 것을 잊지 마세요:

teleport를 tbot를 실행하려는 Linux 사용자 이름으로 바꿉니다.
/etc/tbot.yaml을 생성한 구성 파일의 경로로 바꿉니다.

--write를 생략하면 systemd 서비스 파일이 디스크에 작성되는 대신 콘솔에 출력됩니다.

--anonymous-telemetry는 익명 사용 수집을 제출할 수 있게 합니다. 이는 tbot의 향후 개발을 형성하는 데 도움이 됩니다. 이를 생략하여 비활성화할 수 있습니다.

다음으로 서비스를 활성화하여 부팅 시 시작되도록 하고 서비스를 시작합니다:

sudo systemctl daemon-reload
sudo systemctl enable tbot
sudo systemctl start tbot

서비스가 성공적으로 시작되었는지 확인합니다:

sudo systemctl status tbot

2/2 단계. Jenkins 파이프라인 업데이트 및 실행

Jenkins 파이프라인 내에서 Machine ID를 사용하는 것은 이제 한 줄의 변경 사항입니다. 예를 들어, 원격 호스트에서 hostname 명령을 실행하려면 Jenkins 파이프라인에 다음을 추가하세요.

steps {
  sh "ssh -F /opt/machine-id/ssh_config root@node-name.example.com hostname"
}

모든 준비가 완료되었습니다. 이제 Jenkins에 회전 가능하고 감사 가능하며 Teleport 접근 제어로 제어할 수 있는 머신 아이덴티티에 연결된 단기 인증서를 제공했습니다.

다음 단계

TELEPORT_ANONYMOUS_TELEMETRY에 대한 추가 정보

Teleport 원문 보기