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를 사용하고, 접근 범위와 감사 로그를 함께 관리하는 것이 좋다.

secrets-managementk8sterraformjwt+4

line2026년 6월 10일

레거시 프로젝트에서 AI 드리븐 프로젝트로 전환, AX 로드맵 (새 탭에서 열림)

AX는 AI 도구를 개별적으로 사용하는 데서 그치지 않고, 개발 사이클 전체를 AI 중심으로 재설계하는 전환 과정이다. 성공적인 전환을 위해서는 보안·컴플라이언스 기반을 먼저 마련하고, 팀 차원의 활용 표준화와 명세 기반 개발 자동화를 단계적으로 추진해야 한다. 특히 SDD와 사람의 승인 게이트를 결합하면 AI의 생산성을 활용하면서도 품질과 통제력을 유지할 수 있다. ## AI 드리븐 프로젝트와 SDD - AI 드리븐 프로젝트는 AI를 스펙 작성, 코드 생성, 테스트, 리뷰, 머지 등 개발 전 과정에 통합하는 방식이다. - 사람은 세부 구현보다 요구사항과 방향 설정, 품질 판단에 집중한다. - 핵심 방법론은 명세 주도 개발(SDD)이다. - 요구사항, 구현 범위, 예외 상황, 검증 기준을 먼저 정의한다. - AI는 명세를 바탕으로 계획을 세우고 코드를 생성·검증한다. - AI는 패턴 완성에는 강하지만 추상적인 의도 파악에는 한계가 있으므로, 명확한 스펙이 결과 품질을 좌우한다. ## 1단계: AI-Ready — 보안과 컴플라이언스 기반 AI 도입 전 민감 정보와 핵심 자산이 외부 모델에 노출되지 않도록 안전한 사용 환경을 구축한다. - API 키, DB 비밀번호, 내부 IP 등의 하드코딩을 제거한다. - Secrets Manager 같은 전용 서비스를 사용하고 런타임에 시크릿을 주입한다. - 이름, 이메일, 전화번호 등 PII는 AI에 전달하기 전에 마스킹하거나 토큰화한다. - 핵심 알고리즘과 경쟁력 있는 아키텍처는 별도 저장소에서 관리하거나 AI 접근 권한을 제한한다. - 초기에는 모든 시스템을 한 번에 이관하기보다 다음을 우선 적용한다. - 핵심 컴플라이언스 요건 선별 - 파일 시스템·네트워크 격리를 통한 샌드박싱 - 격리 상태에서 실제 정보가 노출되지 않는지 검증 - 기대 효과: - 코드와 프로젝트 맥락을 AI에 안전하게 제공 - 디버깅, 문서화, 반복 코드 작성 속도 향상 - 팀원들이 AI를 안전하게 활용하는 경험 축적 ## 2단계: AI-Assist — 팀 단위 활용 표준화 개인별로 제각각인 AI 사용 방식을 프로젝트 공통 워크플로로 통합한다. 이 단계에서 AI는 코드를 직접 작성하기보다 사람이 작성한 코드를 검토하고 보조한다. - 프로젝트 루트에 AI용 가이드라인을 작성한다. - 프로젝트 개요 - 코딩 컨벤션 - 아키텍처 원칙 - 도메인 용어집 - 코드 리뷰, 브레인스토밍, 작업 계획 수립 등에 사용할 표준 프롬프트와 스킬을 구축한다. - `superpowers`와 같은 플러그인을 활용해 다음 작업을 표준화할 수 있다. - `brainstorming` - `writing-plans` - `subagent-driven-development` - CI/CD와 AI를 연동해 PR 생성 시 자동 코드 리뷰를 수행한다. - 스타일 위반 탐지 - 잠재적 버그 확인 - 보안 취약점 점검 - 사람 리뷰어는 반복적인 지적보다 복잡한 비즈니스 로직과 정책 판단에 집중한다. - 측정 가능한 KPI: - 사람이 직접 남기는 반복 리뷰 코멘트 수 - 테스트 커버리지 변화 - 배포 안정성 및 테스트 통과율 - 기대 효과: - 팀 전체의 AI 활용 수준 상향 평준화 - 리뷰어의 인지 부하 감소 - 코드 품질과 컨벤션의 일관성 확보 ## 3단계: AI-Development — 명세 기반 개발 자동화 사람이 작성한 스펙이 AI를 통해 구현 계획, 테스트 계획, 코드, PR로 이어지는 자동화 파이프라인을 구축한다. - 전체 흐름은 다음과 같다. 1. 사람이 요구사항과 범위, 엣지 케이스, 검증 기준을 스펙으로 정의 2. AI가 구현 계획과 테스트 계획 작성 3. AI 서브 에이전트가 계획에 따라 작업을 순차적으로 수행 4. 코드 리뷰 후 PR 생성 및 머지 - 세 개의 Human Gate를 둔다. - **Human Gate 1:** 스펙 검토 및 승인 - **Human Gate 2:** 구현 계획과 테스트 계획 검토 및 승인 - **Human Gate 3:** 최종 코드 검토 및 승인 - AI가 프로젝트에 맞는 코드를 만들 수 있도록 도메인 지식을 구조화한다. - 아키텍처 원칙 - 비즈니스 로직의 예외와 특이사항 - 시스템 구성도 - 기존 스펙 및 기술 문서 - 지식은 전용 디렉터리, AI 커스텀 스킬, RAG 시스템 등을 통해 AI가 필요할 때 조회하도록 구성한다. - `/specs` 같은 디렉터리에 새 스펙 파일이 추가되면 CI가 이를 감지해 다음 단계를 실행하도록 이벤트 트리거를 설정한다. - CI 내부에 Approval Step을 배치해 사람의 승인 없이는 AI가 다음 단계로 진행하지 못하게 한다. - 초기에는 핵심 비즈니스 로직보다 테스트 코드나 보일러플레이트처럼 위험도가 낮은 영역부터 자동화를 적용하고, 신뢰가 쌓이면 AI의 담당 범위를 확대한다. ## 단계적 도입이 필요한 이유 - AI 활용 효과는 팀의 문서화 수준, 테스트 품질, 도메인 복잡도에 크게 좌우된다. - 처음부터 모든 구현을 AI에 맡기면 프로젝트 맥락을 이해하지 못한 코드가 생성될 수 있다. - 낮은 위험도의 테스트와 반복 코드부터 시작하면 품질을 검증하면서 팀의 신뢰를 확보할 수 있다. - 각 단계는 독립적으로도 효과가 있으므로 모든 단계를 한 번에 완료할 필요는 없다. 보안 기반을 먼저 확보한 뒤 프로젝트 규칙과 지식을 문서화하고, 자동 리뷰와 테스트 생성부터 시작하는 접근이 현실적이다. 이후 명확한 스펙과 사람의 승인 게이트를 중심으로 코드 생성 범위를 점진적으로 넓히는 것이 안전한 AX 전략이다.

secrets-managementci-cdragsoftware-testing+3

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/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.

secrets-managementci-cdaccess-controlaudit-logging+3

cloudflare2026년 4월 14일

MCP 도입 확대: 더 단순하고 안전하며 비용 효율적인 기업용 MCP 배포를 위한 참조 아키텍처 (새 탭에서 열림)

Cloudflare는 기업 전반에 걸친 모델 컨텍스트 프로토콜(MCP) 도입을 안전하고 효율적으로 확장하기 위해, 자사의 보안 플랫폼(Cloudflare One)과 개발자 플랫폼을 결합한 참조 아키텍처를 구축했습니다. 이 아키텍처는 로컬 MCP 서버의 보안 취약성을 해결하기 위해 중앙 집중식 원격 MCP 서버 모델을 채택하고, 인증 및 데이터 유출 방지(DLP) 기능을 통합하여 거버넌스를 강화했습니다. 이를 통해 기업은 권한 확산이나 프롬프트 인젝션과 같은 위험을 관리하는 동시에, 토큰 비용을 절감하고 생산성을 높이는 에이전트 워크플로우를 구현할 수 있습니다. **원격 MCP 서버를 통한 가시성과 제어권 확보** - 로컬에서 호스팅되는 MCP 서버는 검증되지 않은 소프트웨어 사용과 공급망 공격의 위험이 크며, IT 관리자의 중앙 통제가 불가능하다는 단점이 있습니다. - Cloudflare는 사내 모노레포(Monorepo) 내에 중앙 관리형 MCP 플랫폼을 구축하여, 직원이 템플릿을 통해 승인된 인프라 위에서 원격 MCP 서버를 신속하게 배포할 수 있도록 지원합니다. - 모든 원격 MCP 서버는 Cloudflare의 글로벌 네트워크를 통해 배포되므로 전 세계 어디서든 낮은 지연 시간으로 접근이 가능하며, 관리자는 모든 사용 내역에 대한 가시성을 가집니다. **Cloudflare Access 기반의 강력한 인증** - 내부 자산에 접근하는 MCP 서버를 보호하기 위해 Cloudflare Access를 OAuth 제공자로 통합하여 권한이 부여된 직원만 접근할 수 있도록 제한합니다. - 단일 로그인(SSO), 다요소 인증(MFA)뿐만 아니라 IP 주소, 위치, 기기 인증서와 같은 컨텍스트 기반의 속성을 검증하여 보안 수준을 높입니다. - 공개된 리소스(문서, 레이더 등)와 내부 프라이빗 리소스에 대한 접근 권한을 명확히 분리하여 운영합니다. **MCP 서버 포털을 통한 중앙 집중식 거버넌스** - 직원이 사용 가능한 모든 MCP 서버를 쉽게 찾을 수 있도록 'MCP 서버 포털'을 제공하여 검색성(Discovery) 문제를 해결합니다. - 포털 내에서 중앙 집중식 로깅과 데이터 유출 방지(DLP) 규칙을 적용하여 개인정보(PII) 등의 민감 데이터가 외부로 유출되는 것을 차단합니다. - 사용자 역할에 따라 도구 노출 범위를 다르게 설정하는 정책을 시행할 수 있습니다. (예: 재무팀은 읽기 전용 도구만, 엔지니어링팀은 읽기/쓰기 도구 모두 노출) **비용 절감과 보안 감지 기술** - 모든 API 엔드포인트를 개별 도구로 정의할 때 발생하는 토큰 비용 문제를 해결하기 위해, 에이전트가 코드를 생성하여 API와 상호작용하는 '코드 모드(Code Mode)'를 도입하여 컨텍스트 창 최적화를 달성했습니다. - Cloudflare Gateway를 활용한 '섀도우 MCP(Shadow MCP)' 감지 기능을 통해 조직 내에서 승인되지 않은 원격 MCP 서버가 사용되는 것을 식별하고 통제합니다. - 포털, 원격 서버, 인증 시스템이 모두 Cloudflare의 동일한 물리적 네트워크 노드 내에서 작동하므로 보안 검사 과정에서 발생하는 네트워크 지연을 최소화합니다. 기업이 MCP를 성공적으로 도입하려면 개별 사용자의 로컬 실행에 의존하기보다는, 인증과 거버넌스가 결합된 중앙 관리형 원격 아키텍처를 구축하는 것이 필수적입니다. 이를 통해 보안 리스크를 관리하는 동시에 AI 에이전트 운영에 드는 비용 효율성까지 확보할 수 있습니다.

secrets-managementcloudflareci-cdmodel-context-protocol+4