techlist.io
KREN
gitlab

GitLab Secrets Manager로 CI/CD 자격 증명 관리 (새 탭에서 열림)

ci-cdaccess-controlsecrets-managementaudit-logginggitlab-secrets-manageropenbaogitlab-pipelines

GitLab Secrets Manager는 CI/CD 자격 증명을 GitLab 내부에서 안전하게 관리하도록 지원하는 기능으로, GitLab 19.0에서 공개 베타로 제공됩니다. 비밀 값을 프로젝트·그룹 구조와 파이프라인의 브랜치·환경 조건에 따라 최소 범위로 제공해 유출 시 피해를 줄이고, 생성·변경·사용 이력을 감사 로그로 추적할 수 있다는 것이 핵심입니다. 기존 외부 보안 저장소와 달리 별도의 권한 체계와 운영 시스템을 추가로 관리하지 않아도 됩니다.

CI/CD 변수와 외부 보안 저장소의 한계

  • 개발자는 자격 증명을 .env, 설정 파일 또는 CI/CD 변수에 임시로 저장하기 쉽습니다.
  • 프로젝트나 그룹 수준의 CI/CD 변수는 값을 마스킹할 수 있지만, 기본적으로 여러 작업에 주입되어 최소 권한 원칙을 위반할 수 있습니다.
  • 파이프라인 접근 권한이 있는 사용자가 변수 값을 읽을 가능성도 있습니다.
  • 별도 Vault를 사용하면 비밀을 CI/CD 설정에서 분리할 수 있지만 다음과 같은 운영 부담이 생깁니다.
    • 별도 인증 방식 관리
    • GitLab과 다른 권한 모델 유지
    • 여러 시스템의 감사 로그 상관관계 분석
    • 조직·역할 변경 시 권한 동기화

GitLab Secrets Manager의 사용 방식

  • Secrets Manager는 OpenBao를 기반으로 GitLab에 통합된 네이티브 기능입니다.
  • .gitlab-ci.yml의 secrets: 키워드로 작업에 필요한 비밀을 선언합니다.
deploy:
  secrets:
    DATABASE_PASSWORD:
      gitlab_secrets_manager:
        name: db-password
  script:
    - deploy --password $DATABASE_PASSWORD
  • 기본적으로 비밀 값은 임시 파일에 기록되고, 해당 파일 경로가 작업 범위의 환경 변수로 전달됩니다.
  • 값 자체보다 파일 경로를 전달하면 하위 프로세스, 크래시 덤프, 텔레메트리 등에 비밀이 노출될 가능성을 줄일 수 있습니다.

기존 GitLab 권한 모델 활용

  • 그룹과 프로젝트 구조가 비밀의 격리 경계로 사용됩니다.
  • 사용자·그룹·역할별로 읽기, 생성, 수정, 삭제 권한을 설정할 수 있습니다.
  • 그룹 수준에서 만든 비밀은 하위 프로젝트들이 상속받아 공통 자격 증명을 한 번만 정의할 수 있습니다.
  • 사용자가 프로젝트에서 제거되면 해당 프로젝트의 비밀 접근 권한도 즉시 사라집니다.
  • 별도 보안 시스템에서 GitLab의 조직 구조와 권한을 다시 구성하고 동기화할 필요가 없습니다.

브랜치와 환경별 최소 권한 범위

  • 각 비밀은 해당 비밀이 필요한 작업에만 제공됩니다.
  • 접근 여부는 다음 작업 속성으로 결정됩니다.
    • 대상 환경
    • 실행 브랜치
    • 브랜치 보호 여부
  • 환경과 브랜치에는 와일드카드를 사용할 수 있습니다. 예를 들어 production/*과 같은 규칙을 지정할 수 있습니다.
  • 보호된 브랜치에서 production/* 환경으로 실행되는 작업에만 비밀을 제공하도록 조건을 조합할 수 있습니다.
  • 작업 실행 시 백엔드가 작업의 신원, 브랜치, 환경을 검증한 뒤 비밀을 반환합니다.
  • 작업 종료 후 비밀은 러너에 남지 않으며, 로그에서는 값이 마스킹됩니다.
  • 자격 증명이 유출되어도 접근 가능한 시스템 범위가 좁아져 회전, 조사, 복구에 필요한 작업이 줄어듭니다.

파이프라인과 연결된 감사 추적

  • 프로젝트·그룹 비밀의 생성, 수정, 삭제 이벤트가 GitLab의 기존 감사 로그에 기록됩니다.
  • CI/CD 파이프라인에서 비밀을 읽은 이벤트에는 원본 파이프라인 ID와 작업 ID가 포함됩니다.
  • 따라서 별도 CI 시스템, 보안 저장소, ID 제공자의 로그를 수동으로 조합하지 않고도 비밀 사용 경로를 추적할 수 있습니다.
  • 감사 로깅은 현재 self-managed 배포에서 제공되며, GitLab.com 지원은 공개 베타 기간 중 추가될 예정입니다.

공개 베타와 기존 도구와의 연계

  • GitLab.com 및 self-managed 환경의 Premium·Ultimate 사용자가 공개 베타에 참여할 수 있습니다.
  • GitLab Dedicated 지원은 추후 제공될 예정입니다.
  • 베타 기간에는 무료이며, 정식 출시 후에는 GitLab Credits를 통해 유료 제공됩니다.
  • HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager 통합도 계속 사용할 수 있어 기존 시스템에서 단계적으로 전환할 수 있습니다.

실무적으로는 광범위한 CI/CD 변수를 먼저 점검하고, 배포 환경·브랜치별로 필요한 비밀을 Secrets Manager로 이전하는 것이 좋습니다. 특히 운영 자격 증명은 보호된 브랜치와 특정 production/* 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.