Tekton CI와 GitOps CD 분리: Task·Pipeline·Trigger 학습노트

『GitOps Cookbook』 6장을 읽으며 Tekton의 Task, Pipeline, Trigger를 한 흐름으로 정리했다. 처음에는 “Kubernetes 자체가 CI/CD server가 된다”는 점이 가장 인상적이었다. 다시 보면 더 중요한 질문은 실행 위치가 아니라 build identity와 deployment 권한을 어디에서 끊을 것인가다.

이 글은 당시의 Tekton CI 학습 맥락을 남기면서, direct kubectl apply와 GitOps CD를 구분하고 현재 builder·webhook 보안 경계를 보완한 기록이다.

Task·Pipeline·Run은 정의와 실행을 나눈다

Tekton Pipelines의 기본 개념은 다음과 같다.

resource	역할
Task	순차적으로 실행할 step, param, workspace, result 정의
TaskRun	Task 한 번의 실행 instance
Pipeline	여러 Task의 dependency와 data 전달 정의
PipelineRun	Pipeline 한 번의 실행 instance
Workspace	Task 사이에서 공유할 volume·directory 연결
Result	commit SHA나 image digest 같은 작은 output 전달

TaskRun이 실행되면 일반적으로 Pod가 만들어지고 Task 안의 step이 순서대로 실행된다. Pipeline의 Task는 선언한 dependency에 따라 순차 또는 병렬로 schedule될 수 있다. Workspace는 공유 storage를 연결할 뿐 secret 관리나 격리를 자동으로 해결해 주지는 않는다.

현재 tekton.dev/v1 형태의 최소 Task는 다음처럼 읽을 수 있다.

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: print-revision
spec:
  params:
    - name: revision
      type: string
  steps:
    - name: print
      image: bash:5.2
      script: |
        #!/usr/bin/env bash
        set -eu
        printf 'revision=%s\n' "$(params.revision)"

예제는 구조를 보여 주기 위해 version tag를 썼다. 운영 Task는 검증한 image digest를 고정하고, image provenance와 vulnerability 정책을 함께 관리한다.

CI는 source에서 검증된 artifact를 만든다

cloud-native CI 흐름을 작게 자르면 다음과 같다.

고정 commit checkout
  → dependency·unit test
  → container image build
  → scan·sign·attestation
  → registry push
  → image digest result

각 Task에는 필요한 ServiceAccount와 Workspace만 연결한다. source clone Task가 registry push credential을 가질 이유는 없다. build step이 cluster-wide Kubernetes 권한을 가질 이유도 없다. 한 Pipeline 안에서도 credential을 단계별로 나누는 것이 핵심이다.

공용 Task나 bundle을 가져올 때도 version을 고정하고 내용을 review한다. catalog 이름이 익숙하다는 이유만으로 third-party Task에 repository token과 registry credential을 함께 넘기지 않는다.

Kaniko는 과거 실습과 현재 선택을 구분한다

원래 장에서는 daemonless image builder 예시로 Kaniko를 사용했다. 당시 학습 흐름을 이해하는 데는 의미가 있지만, GoogleContainerTools의 Kaniko repository는 2025년 6월 archive됐다. 새 platform의 기본 builder를 고를 때는 그대로 복사하기보다 유지보수 상태를 다시 평가해야 한다.

BuildKit, Buildah, Cloud Native Buildpacks 같은 후보도 이름만 보고 안전하다고 결론 내릴 수 없다. 다음을 같은 조건에서 비교한다.

• rootless 또는 privileged 실행 요구
• cache가 tenant 사이에 공유되는 방식
• Dockerfile compatibility와 reproducibility
• secret mount가 image layer·log에 남는지
• SBOM·provenance·signature 지원
• 유지보수 release와 취약점 대응

builder 변경은 YAML 한 줄 교체가 아니다. cache, credential, base image pinning, output digest 검증까지 함께 시험한다.

direct deploy는 push CD이고 GitOps와 다르다

Tekton Task가 kubectl apply를 실행해 cluster를 바꾸는 것은 자동 CD가 될 수 있지만 OpenGitOps의 “pulled automatically” model은 아니다.

방식	배포 주체	cluster credential	desired state 이력
Tekton direct deploy	Pipeline이 cluster로 push	CI가 보유	Pipeline log와 적용 file에 분산될 수 있음
GitOps CD	Argo CD·Flux가 source에서 pull	GitOps agent가 보유	config repository commit·PR

GitOps 형태로 분리하면 CI의 마지막 output은 cluster 변경이 아니라 immutable image digest와 config repository 변경 PR이다.

source repository
  → Tekton CI
  → registry image@sha256
  → config repository PR
  → review·merge
  → GitOps agent
  → target cluster

이 구조에서도 CI가 config repository에 쓸 수 있는 branch와 path를 제한한다. 자동 PR의 author, source SHA, image digest, test result를 commit이나 PR metadata에 남긴다. merge 뒤 배포 성공은 Argo CD sync와 application smoke test로 별도 확인한다.

Kustomize 변경 방식은 base·overlay와 patches, Helm 구조는 Helm chart와 values 관리, Argo CD reconciliation은 Argo CD 적용 흐름으로 이어진다.

Trigger는 외부 입력을 받는 security boundary다

Tekton Triggers는 EventListener가 event를 받고 TriggerBinding으로 값을 꺼내 TriggerTemplate에서 TaskRun·PipelineRun을 만든다. 이 endpoint를 internet에 열면 단순한 자동 시작 버튼이 아니라 build resource와 credential에 접근하는 entry point가 된다.

최소한 다음을 확인한다.

1. provider webhook signature를 원본 body 기준으로 검증한다.
2. repository, event type, branch·tag 조건을 allowlist한다.
3. event의 commit SHA를 그대로 고정하고 임의 URL을 clone하지 않는다.
4. delivery ID로 replay·duplicate 실행을 제어한다.
5. payload 크기, rate limit, timeout을 둔다.
6. EventListener와 PipelineRun ServiceAccount 권한을 분리한다.
7. 외부 endpoint와 build Pod network를 필요한 방향으로만 연다.

webhook signature가 맞아도 repository 내부 code는 untrusted input일 수 있다. fork PR이나 임의 branch build에는 production secret을 전달하지 않는다.

Tekton과 GitHub Actions는 trust boundary로 고른다

Tekton은 cluster 안의 private network와 Kubernetes policy를 활용하기 좋지만 controller, upgrade, storage, quota, log 보존을 직접 운영해야 한다. GitHub Actions는 repository·PR workflow와 가깝지만 hosted 또는 self-hosted runner의 network 접근과 action dependency를 관리해야 한다.

선택 질문은 다음과 같다.

• build가 접근해야 할 source·registry·internal dependency는 어디에 있는가
• untrusted PR과 trusted release job을 어떻게 격리하는가
• cloud credential을 장기 secret 대신 OIDC short-lived token으로 바꿀 수 있는가
• runner·Pod image와 third-party action을 누가 review하고 pinning하는가
• queue, cost, log, artifact retention을 누가 운영하는가

두 도구를 섞을 수도 있지만 같은 test를 중복 실행하거나 credential boundary가 흐려지지 않게 stage owner를 정한다.

이번 학습에서 남긴 결론

처음에는 Task와 Pipeline을 연결해 build부터 deploy까지 한 번에 실행하는 것이 목표였다. 지금의 결론은 조금 다르다.

• Tekton의 가치는 Kubernetes 위에 build execution API를 제공하는 데 있다.
• CI의 신뢰 가능한 output은 mutable tag가 아니라 검증된 image digest다.
• Pipeline의 direct apply와 GitOps pull reconciliation은 다른 CD model이다.
• Trigger와 builder는 편의 기능이 아니라 높은 권한의 security boundary다.
• PR과 Git history가 있어도 agent·drift·prune 정책이 없으면 GitOps가 완성되지 않는다.

참고 자료

• Tekton: Tasks
• Tekton: Pipelines
• Tekton: Workspaces
• Tekton: Triggers and EventListeners
• GitHub Docs: Validating webhook deliveries
• GitHub Docs: OpenID Connect in cloud providers
• GoogleContainerTools: Kaniko repository
• moby: BuildKit