애플리케이션 시크릿

GitLab에서 액세스 토큰 및 자격 증명 등 다양한 시크릿을 암호화하여 저장하고 관리하는 방법을 설명합니다.

GitLab은 기능을 수행하기 위해 액세스 토큰 및 기타 자격 증명과 같은 다양한 시크릿에 접근할 수 있어야 합니다. 이러한 시크릿은 암호화되어 저장되며, 용도에 따라 다양한 데이터 저장소에 보관될 수 있습니다. 이 가이드를 통해 다양한 종류의 시크릿이 어떻게 저장되고 관리되는지 이해하세요. 애플리케이션 시크릿과 운영 시크릿 # 크게 보면 두 가지 종류의 시크릿이 있습니다: 애플리케이션 시크릿. GitLab 애플리케이션이 특정 기능이나 함수를 구현하는 데 사용합니다. 예시로는 암호화 서명을 생성하기 위한 액세스 토큰이나 개인 키가 있습니다. 이러한 시크릿은 암호화된 칼럼을 통해 데이터베이스에 저장됩니다. 보안 코딩 가이드라인: 저장 중 데이터 를 참고하세요. 운영 시크릿. 다른 시크릿을 읽고 저장하거나 애플리케이션을 부트스트랩하는 데 사용됩니다. 이러한 이유로 데이터베이스에 저장할 수 없습니다. 이러한 시크릿은 config/secrets.yml 파일의 Rails 자격 증명 으로 저장됩니다: 직접 설치(self-compiled)의 경우 직접 저장됩니다. Omnibus나 Helm과 같은 설치 프로그램을 통해 저장됩니다 (실제 시크릿은 쿠버네티스 시크릿 또는 Vault 와 같은 외부 시크릿 컨테이너에 저장할 수 있습니다). 애플리케이션 시크릿 # 애플리케이션 시크릿은 ActiveRecord::Encryption 을 사용하여 PostgreSQL에 저장해야 합니다: class MyModel < ApplicationRecord encrypts :my_secret end 최근까지는 ActiveRecord::Encryption 대신 attr_encrypted 를 사용했습니다. 현재 모든 칼럼을 새로운 Rails 네이티브 암호화 프레임워크로 마이그레이션하는 작업이 진행 중입니다( 에픽 15420 참고). 기존 attr_encrypted 속성 마이그레이션에 대한 지침은 attr_encrypted 에서 ActiveRecord::Encryption 으로 마이그레이션 을 참고하세요. 선례가 있더라도 애플리케이션 시크릿을 ApplicationSetting 으로 저장해서는 안 됩니다. 이 시크릿이 디코딩에 실패하면 전체 애플리케이션이 오작동할 수 있습니다. 다른 기능과의 결합도를 줄이기 위해 시크릿은 전용 테이블에 격리하세요. 경우에 따라 데이터베이스에 시크릿을 저장하는 것이 바람직하지 않을 수도 있습니다. 예를 들어, Rails 애플리케이션을 부트스트랩하기 위해 시크릿이 필요한 경우, 이니셜라이저에서 데이터베이스에 접근해야 할 수 있으며, 데이터베이스 연결 자체가 아직 준비되지 않은 상황에서 초기화 경쟁 조건이 발생할 수 있습니다. 이 경우에는 시크릿을 운영 시크릿으로 저장하세요. attr_encrypted에서 ActiveRecord::Encryption으로 마이그레이션 # attr_encrypted 젬에서 Rails 네이티브 ActiveRecord::Encryption 프레임워크로 모든 암호화된 속성을 마이그레이션하고 있습니다. 이 마이그레이션은 전환