This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed devops verify -

GitLab Secrets Manager ADR 004: Stateless Key Management Service

ADR-002에서는 Google의 클라우드 키 관리 서비스를 사용하기로 결정했습니다. 이를 통해 다양한 규정 준수 요구 사항을 더 쉽게 충족시킬 수 있게 될 것입니다.

이 ADR에서는 GitLab Secrets Management Service의 원하는 아키텍처를 설명하고, 상태가 없는 서비스로 만들어 지속적인 데이터 저장소 외에도 단명한 로컬 저장소와 연결되지 않은 아키텍처를 살펴보겠습니다.

맥락

결정

GitLab Secrets Management Service를 상태가 없는 응용 프로그램으로 만들어, 관계형 또는 NoSQL 데이터베이스와 같은 전체 데이터 저장소에 연결되지 않도록 합니다.

우리는 캐싱 목적으로 아마도 로컬 블록 저장소를 지원할 것입니다.

똑똑하게 복호화 비용을 관리하기 위해, 다중 계층 보호층 및 메모리 내 개별 인스턴스에 대한 대칭 복호화 키 캐싱을 구현해야 합니다. 캐시 TTL은 보호 계층에 따라 달라집니다. Google의 클라우드 KMS에서는 계층에 따라 하드웨어 또는 소프트웨어 키를 사용할 수 있습니다.

결과

  1. 모든 개인 키는 Google의 클라우드 KMS에 저장됩니다.
  2. 고수준의 보호를 제공하는 다중 계층 보호가 구현됩니다.
  3. 보호 계층은 GitLab Rails Service 측에서 조직별로 정의될 것입니다.
  4. 사용된 보호 수준에 따라 대칭 복호화 키가 메모리내 캐싱될 수 있습니다.
  5. 대칭 키 캐시의 유효 기간은 24시간을 넘을 수 없습니다.
  6. 최고 수준의 보호 계층은 하드웨어 보안 모듈을 사용하며 캐싱을 사용하지 않습니다.
  7. GitLab Secrets Management Service에 엑세스 제어 메타데이터가 저장되지 않을 것입니다.
  8. ID 분리는 GitLab Rails Service 측에서 발생할 것입니다.
  9. 복호화 요청은 조직의 공개 키로 서명될 것입니다.
  10. 서비스는 서명을 확인하여 복호화 요청자의 신원을 확인할 것입니다.

대안

관계형 데이터베이스나 NoSQL 데이터베이스, 둘 다 클라우드 제공 업체에 의해 자체 관리되거나 관리되는 것들을 사용하는 것을 고려했지만, 이는 서비스의 복잡성을 증가시키고 보안을 약화시킬 것으로 결론지었습니다.