gitlab2026년 8월 6일

GitLab Secrets Manager, ESO·Terraform·API 지원 추가 (새 탭에서 열림)

GitLab Secrets Manager가 External Secrets Operator(ESO), Terraform/OpenTofu, CLI, API를 지원하면서 CI/CD 외의 환경에서도 하나의 비밀 저장소를 사용할 수 있게 되었다. OpenBao 기반의 Vault 호환 인터페이스를 통해 Kubernetes, 인프라 코드, 외부 자동화가 동일한 방식으로 비밀을 조회하며, 인증에는 단기 JWT를 사용한다. 이를 통해 여러 저장소와 인증 모델, 감사 로그를 따로 관리해야 하는 부담을 줄일 수 있다. ### GitLab Secrets Manager의 통합 비밀 관리 - 기존에는 CI/CD, Kubernetes, Terraform마다 별도의 비밀 저장소를 사용하는 경우가 많았다. - GitLab Secrets Manager는 OpenBao를 기반으로 다음 환경에 동일한 저장소를 제공한다. - Kubernetes 워크로드 - Terraform 및 OpenTofu 실행 - OpenBao 또는 Vault CLI - GitLab CI/CD 작업 - 외부 자동화 시스템 및 스크립트 - Vault 호환 KV v2 API를 제공하므로 기존 Vault 생태계 도구와 연동할 수 있다. - 중앙 집중식 저장소를 사용하면 접근 정책과 감사 추적을 일관되게 관리할 수 있다. ### Kubernetes와 External Secrets Operator 연동 - ESO는 Vault provider를 통해 GitLab Secrets Manager에서 비밀을 가져온다. - Kubernetes 워크로드는 단기 JSON Web Token(JWT)을 사용해 OpenBao에 인증한다. - `SecretStore` 리소스에서 다음 항목을 설정한다. - `server`: GitLab Secrets Manager의 Vault 호환 서버 주소 - `path`: KV v2 마운트 경로 - `namespace`: 조직·그룹·프로젝트 계층을 나타내며 접근 가능한 비밀 범위를 제한 - `auth.jwt.path`: JWT 인증 경로 - `auth.jwt.role`: 사용할 인증 역할 - `secretRef`: Kubernetes Secret에 저장된 JWT 참조 - `ExternalSecret`은 원격 비밀과 Kubernetes Secret 사이의 매핑을 정의한다. - `remoteRef.key`: GitLab Secrets Manager의 비밀 경로 - `property`: 원격 비밀 내부에서 가져올 필드 - `secretKey`: Kubernetes Secret에 저장될 키 - `target.name`: 생성할 Kubernetes Secret 이름 - ESO는 대상 Secret을 생성하고 소유하며, 설정된 `refreshInterval`마다 값을 다시 조회한다. - 비밀이 교체되면 애플리케이션을 재배포하지 않아도 Kubernetes Secret에 변경 사항이 반영된다. ### Terraform과 OpenTofu에서 비밀 조회 - Terraform의 `.tfvars` 파일이나 상태 파일에 인증 정보가 기록되면 자격 증명이 유출될 위험이 있다. - GitLab Secrets Manager를 Terraform data source로 조회하면 비밀을 `.tfvars`나 CI/CD 변수에 직접 저장하지 않고 실행 시점에 가져올 수 있다. - 일반적인 흐름은 다음과 같다. - 외부 스크립트로 GitLab 프로젝트의 단기 JWT를 발급 - Terraform Vault provider에 서버 주소, namespace, 인증 경로, role, JWT 전달 - `vault_kv_secret_v2` data source로 원하는 비밀 조회 - 필요한 경우 `sensitive = true`로 출력값을 민감 정보로 표시 - Terraform 실행 시점에 인증이 이루어지므로 장기 자격 증명을 코드나 설정 파일에 남기는 일을 줄일 수 있다. ### OpenBao 및 Vault CLI 사용 - 기존에 Vault용 CLI나 스크립트를 사용 중인 팀은 별도의 클라이언트를 도입하지 않아도 된다. - `VAULT_ADDR`와 `VAULT_NAMESPACE`를 설정한 뒤, 발급받은 JWT를 JWT 인증 엔드포인트에 전달한다. - 인증 결과로 받은 OpenBao 토큰을 `VAULT_TOKEN`에 설정한다. - 이후 `vault kv get` 명령으로 KV v2 경로의 비밀을 조회할 수 있다. - Vault 호환 방식을 사용하므로 기존 운영 자동화와의 통합 비용이 낮다. ### Secrets Manager API를 통한 외부 자동화 - GitLab CI/CD, Kubernetes, Terraform에 포함되지 않는 외부 시스템은 Secrets Manager API를 사용할 수 있다. - 서비스 계정 또는 액세스 토큰으로 프로젝트별 액세스 토큰 발급 API를 호출한다. - API 응답에는 다음과 같은 연결 정보가 포함된다. - Vault 서버 주소 - namespace - KV 마운트 경로 - 비밀 경로 - JWT 인증 경로 - 인증 role - JWT - 외부 시스템은 이 정보를 이용해 단기 인증을 수행하고 필요한 비밀만 조회한다. - 하드코딩된 비밀번호나 별도의 변수 파일을 유지하지 않아도 되는 것이 장점이다. ### 실용적인 적용 권장 사항 - Kubernetes에서는 ESO의 `SecretStore`와 `ExternalSecret`을 사용해 자동 동기화와 비밀 교체를 구성한다. - Terraform에서는 비밀을 `.tfvars`에 넣기보다 실행 시점의 data source 조회 방식으로 전환한다. - 기존 Vault 자동화가 있다면 OpenBao/Vault CLI 호환 기능을 우선 활용한다. - 외부 서비스에는 장기 토큰 대신 프로젝트 범위와 역할이 제한된 단기 JWT를 사용하고, 접근 범위와 감사 로그를 함께 관리하는 것이 좋다.

openbaok8sterraformjwt+4

gitlab2026년 5월 21일

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

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:` 키워드로 작업에 필요한 비밀을 선언합니다. ```yaml 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/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.

openbaoci-cdaccess-controlsecrets-management+3