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

이 가이드에서는 기존 Jenkins 파이프라인을 마이그레이션하여 Teleport로 보호된 인프라에 연결하기 위해 머신 및 워크로드 아이덴티티를 활용하는 방법을 보여줍니다.

사전 조건#

Jenkins에서 Teleport를 사용하려면 다음 도구가 필요합니다.

• A running Teleport 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:

• ssh OpenSSH 도구
• Jenkins

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.

아키텍처#

시작하기 전에 Jenkins는 보안이 어렵기로 악명 높은 도구라는 점을 알아야 합니다. 머신 및 워크로드 아이덴티티는 인프라를 보안하는 하나의 구성 요소이지만 그것만으로는 충분하지 않습니다. 아래에서 Jenkins 설치의 보안 자세를 개선하는 데 도움이 되는 몇 가지 기본 지침을 제공합니다.

단일 호스트 배포#

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

다중 호스트 배포#

Jenkins 컨트롤러와 에이전트를 다른 호스트에서 실행하고 특정 에이전트에 워크로드를 고정하는 것이 조금 더 복잡하지만 더 안전한 배포입니다. 단일 파이프라인이 손상되었을 때의 영향 범위를 모든 인프라 대신 CI/CD 인프라의 하위 집합으로 제한할 수 있기 때문에 간단한 배포보다 개선된 방법입니다.

모범 사례#

가능하면 두 번째 배포 모델을 사용하고 임시 호스트 및 IAM 조인을 사용하는 것이 좋습니다. 이 모델에서 머신 및 워크로드 아이덴티티를 사용할 때는 호스트별로 별도의 봇을 만들고 실행하며 특정 파이프라인을 워커에 고정합니다. 이렇게 하면 각 파이프라인에 서버 접근을 위한 최소 범위를 부여하고 파이프라인 하나가 손상되었을 때의 영향 범위를 줄이며 악의적인 동작이 감지될 경우 파이프라인을 원격으로 감사하고 잠글 수 있습니다.

1단계/2단계. tbot 설정 및 시작#

먼저 Jenkins 워크플로에 새 역할을 만들지 기존 역할을 사용할지 결정합니다. tctl get roles를 실행하여 기존 역할을 검토할 수 있습니다.

아래 예시에서는 레이블 group: api가 있는 노드와 Linux 사용자 jenkins로 로그인할 수 있는 api-workers라는 새 역할을 만들기 위해 아래 내용으로 api-workers.yaml 파일을 만듭니다.

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

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

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

머신 및 워크로드 아이덴티티 에이전트 tbot을 사용하면 Linux 접근 제어 목록(ACL)을 사용하여 디스크의 인증서에 대한 접근을 제어할 수 있습니다. 이를 사용하여 tbot이 발급하는 단기 인증서에 대한 Jenkins의 접근을 제한합니다.

다음 예시에서는 tbot을 실행하기 위해 teleport라는 Linux 사용자를 만들지만 단기 인증서는 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

Create the bot data directory and grant permissions to access it to the Linux user (in our example, teleport) which tbot will run as.

# Make the bot directory and assign ownership to teleport user
$ sudo mkdir -p /var/lib/teleport/bot
$ sudo chown teleport:teleport /var/lib/teleport/bot
# Allow teleport user to open directory
$ sudo chmod +x /var/lib/teleport /var/lib/teleport/bot

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

먼저 /etc/tbot.yaml에 tbot 설정 파일을 만듭니다.

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
services:
  - type: identity
    destination:
      type: directory
      path: /opt/machine-id

tbot systemd 유닛 파일 만들기#

By default, tbot will run in daemon mode. However, this must then be configured as a service within the service manager on the Linux host. The service manager will start tbot on boot and ensure it is restarted if it fails.

If tbot was installed using the Teleport install script or teleport-update command, the tbot systemd service is automatically created for you.

After tbot.yaml is created, enable and start the service::

$ sudo systemctl enable tbot --now

Check the service has started successfully:

$ sudo systemctl status tbot

Service properties like User and Group may be configured using systemctl edit tbot.`

If tbot was installed manually, service configuration will need to be performed manually as well.

For this guide, systemd will be demonstrated but tbot should be compatible with all common alternatives.

Use tbot install systemd to generate a systemd service file:

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

Ensure that you replace:

• teleport with the name of Linux user you wish to run tbot as.
• /etc/tbot.yaml with the path to the configuration file you have created.

You can omit --write to print the systemd service file to the console instead of writing it to disk.

--anonymous-telemetry enables the submission of anonymous usage telemetry. This helps us shape the future development of tbot. You can disable this by omitting this.

Next, enable the service so that it will start on boot and then start the service:

$ sudo systemctl daemon-reload
$ sudo systemctl enable tbot --now

Check the service has started successfully:

$ sudo systemctl status tbot

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

Jenkins 파이프라인 내에서 tbot이 생성한 자격 증명을 사용하는 것은 이제 한 줄 변경입니다. 예를 들어 원격 호스트에서 hostname 명령을 실행하려면 Jenkins 파이프라인에 다음을 추가합니다.

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

이제 준비되었습니다. Jenkins에 순환, 감사 및 접근 제어로 제어할 수 있는 머신 아이덴티티에 연결된 단기 인증서를 제공했습니다.

다음 단계#

TELEPORT_ANONYMOUS_TELEMETRY에 대한 자세한 정보.