SSD Nodes Learn 🎉 VPS $5.50/월부터
가이드 Matt Connor작성자 Matt Connor

자체 호스팅 비밀 관리자 비교: OpenBao, Infisical, SOPS

단일 서버 환경에서 OpenBao, Infisical, SOPS, systemd credentials 중 무엇이 적합한지 비교합니다. 운영 복잡도와 보안 수준을 분석하여 실제 서비스 운영 시 고려해야 할 비용과 유지보수 요소를 정리했습니다.

자체 호스팅 비밀 관리자가 비밀번호 관리자와 다른 점

자체 호스팅 비밀 관리자는 프로세스에 자격 증명을 전달합니다. 비밀번호 관리자는 사람에게 자격 증명을 전달합니다. 그 외의 모든 차이점은 이 한 가지 차이에서 비롯됩니다. 비밀번호 관리자는 사람이 직접 조작하고 주의를 기울여야 잠금이 해제됩니다. 비밀 관리자는 아무도 깨어 있지 않은 03:00에 애플리케이션에 데이터베이스 비밀번호를 제공해야 합니다.

실패 모드는 중요한 차이를 보입니다. 잠긴 비밀번호 관리자는 불편할 뿐입니다. 마스터 비밀번호를 다시 입력하면 됩니다. 봉인된 비밀 관리자는 서비스 중단을 의미합니다. 봉인된 상태에서 재시작되는 모든 서비스는 자격 증명 없이 실행되어 계속 중단된 상태로 남습니다. Vaultwarden을 직접 운영하는 비밀번호 관리자로 사용하기는 사람과 관련된 문제는 잘 해결합니다. 하지만 기계와 관련된 문제는 해결하지 못하며, 애초에 그런 용도로 만들어지지도 않았습니다.

단일 서버를 위한 현실적인 선택지는 두 그룹으로 나뉩니다. OpenBao와 Infisical은 서비스 형태입니다. API, 데이터베이스, TLS(전송 계층 보안), 로그인 단계, 그리고 계속 유지해야 하는 프로세스가 포함됩니다. age를 사용하는 SOPS, systemd credentials, Docker secrets는 파일 형태입니다. 저장 시 암호화되고, 이미 실행 중인 무언가에 의해 복호화되며, 추가로 모니터링할 요소가 없습니다.

솔직한 답변을 먼저 드립니다. 한두 명이 사용하는 단일 서버라면 파일 기반 옵션이 대개 올바른 선택입니다. 제대로 봉인을 해제하지 않고 순환(rotation)도 하지 않는 OpenBao는 mode 600인 env 파일보다 못합니다. 이는 관리해야 할 움직이는 부품과 잘못 관리하기 쉬운 백업만 추가할 뿐, 수동으로 수행하던 것 이상의 순환 기능을 제공하지 않기 때문입니다.

600 모드의 env 파일이면 충분합니까?

대부분의 경우 충분합니다. 이 설정은 서버의 다른 사용자가 데이터베이스 비밀번호를 읽어가는 위협을 방어합니다. Unix 파일 권한은 네트워크가 활성화되기 전부터 이 역할을 수행합니다.

sudo install -d -m 750 -o root -g myapp /etc/myapp
sudo install -m 640 -o root -g myapp /dev/null /etc/myapp/env
sudoedit /etc/myapp/env

양쪽 측면에서 확인해 보십시오:

sudo -u myapp cat /etc/myapp/env
sudo -u nobody cat /etc/myapp/env

첫 번째 명령은 파일을 출력합니다. 두 번째 명령은 cat: /etc/myapp/env: Permission denied를 출력하는데, 이는 nobody 사용자가 myapp 그룹에 속해 있지 않고 파일에 world 권한 비트가 설정되어 있지 않기 때문입니다. 이것이 보안 모델의 전부이며, 실제로 유효한 방식입니다.

문제는 그 이후에 발생하는 정보 유출입니다. EnvironmentFile=를 사용하는 systemd 유닛은 해당 값들을 프로세스 환경 변수로 복사하며, 프로세스 환경 변수는 읽기가 가능합니다.

[Service]
User=myapp
EnvironmentFile=/etc/myapp/env
ExecStart=/usr/local/bin/myapp
sudo cat /proc/$(pgrep -n myapp)/environ | tr '\0' '\n'

이 명령은 비밀 정보를 평문으로 출력합니다. /proc/<pid>/environ은 root와 해당 프로세스를 실행하는 사용자 모두가 읽을 수 있기 때문입니다. 보고서에 환경 변수를 포함하는 크래시 리포터 역시 동일한 정보를 확인하게 됩니다. 동일한 계정으로 실행되는 모든 도구도 마찬가지입니다. 이것이 바로 AI 에이전트에서 비밀 정보 제외하기가 환경 변수에서 비밀 정보를 제거하는 것부터 시작하는 이유입니다. 해당 파일을 전용 저권한 서비스 사용자와 함께 사용하여 "프로세스를 실행하는 사용자"가 root이 되지 않도록 하십시오.

age를 활용한 SOPS: Git에 커밋 가능한 암호화된 시크릿

SOPS(secrets operations)는 YAML 또는 JSON 파일의 값은 암호화하고 키는 평문으로 남겨둡니다. age는 별도의 키 서버 없이 단일 키 쌍을 사용하는 소형 암호화 도구입니다. 이 둘을 조합하면 코드와 함께 secrets.enc.yaml을 커밋할 수 있으며, git diff를 사용해도 어떤 설정이 변경되었는지는 알 수 있지만 그 값이 무엇으로 바뀌었는지는 읽는 사람이 알 수 없게 됩니다.

age는 Ubuntu 24.04 패키지에 포함되어 있습니다. SOPS는 포함되어 있지 않으므로 릴리스 페이지에서 .deb을 가져와야 합니다. 2026년 8월 기준으로 3.13.3 버전이 최신입니다.

sudo apt update && sudo apt install -y age
curl -LO https://github.com/getsops/sops/releases/download/v3.13.3/sops_3.13.3_amd64.deb
sudo apt install -y ./sops_3.13.3_amd64.deb
sops --version

키 쌍을 생성합니다. age-keygen은 개인 키를 파일에 기록하고 공개 키를 출력하므로, Public key: age1...로 시작하는 줄을 확인할 수 있습니다.

mkdir -p ~/.config/sops/age
age-keygen -o ~/.config/sops/age/keys.txt
chmod 600 ~/.config/sops/age/keys.txt
age-keygen -y ~/.config/sops/age/keys.txt

공개 키를 리포지토리 루트의 .sops.yaml에 저장하면 명령줄에서 매번 수신자를 지정할 필요가 없습니다.

creation_rules:
  - age: age1s3cqcks5genc6ru8chl0hkkd04zmxvczsvdxq99ekffe4gmvjpzsedk23c
sops encrypt secrets.yaml > secrets.enc.yaml
sops decrypt secrets.enc.yaml

path_regex가 없는 규칙은 모든 파일에 적용되는데, 처음에는 이 방식이 적합합니다. 나중에 규칙을 추가한다면 sops에 전달하는 파일과 일치하도록 작성하십시오. 규칙은 출력 방향을 재지정한 파일이 아니라 입력 경로를 기준으로 검사하기 때문입니다.

런타임에는 값을 하나의 프로세스에만 전달하십시오.

sops exec-env secrets.enc.yaml './myapp'

sops exec-env은 메모리에서 복호화하여 자식 프로세스 환경에 값을 설정하므로, 평문이 디스크에 기록되지 않습니다. 이전 섹션에서 언급한 환경 변수 관련 주의 사항은 해당 자식 프로세스에도 동일하게 적용됩니다.

이 과정에서 흔히 발생하는 문제는 두 가지입니다. systemd 환경에서 발생하는 Failed to get the data key required to decrypt the SOPS file 오류는 대부분 SOPS가 잘못된 홈 디렉터리를 참조했기 때문에 발생합니다. 유닛은 사용자의 HOME을 상속받지 않기 때문입니다. 유닛 파일 내 Environment=SOPS_AGE_KEY_FILE=/etc/sops/age.txt를 사용하여 경로를 명시적으로 설정하십시오. 또한 .sops.yaml을 수정한다고 해서 이미 존재하는 파일이 다시 암호화되지는 않습니다. 동료의 공개 키를 추가해도 새로운 파일에만 적용되므로, 기존 파일 각각에 대해 sops updatekeys secrets.enc.yaml을 실행해야 합니다. 이미 Ansible을 통해 설정을 관리하고 있다면, Ansible Vault로 동일한 값 암호화하기를 통해 별도의 도구 없이 같은 결과를 얻을 수 있습니다.

systemd credentials: 환경 변수에 노출되지 않는 비밀 값

Ubuntu 24.04는 systemd 255 버전을 포함하므로 별도의 설치가 필요하지 않습니다. systemd-creds는 호스트에서 비밀 값을 암호화하며, systemd는 이를 복호화하여 해당 서비스만 읽을 수 있는 전용 디렉터리에 배치합니다.

sudo systemd-creds setup
sudo install -d -m 700 /etc/myapp
echo -n 'hunter2' | sudo systemd-creds encrypt --name=db_password - /etc/myapp/db_password.cred
[Service]
User=myapp
LoadCredentialEncrypted=db_password:/etc/myapp/db_password.cred
ExecStart=/usr/local/bin/myapp

서비스는 $CREDENTIALS_DIRECTORY가 지정하는 디렉터리 내부의 db_password이라는 파일에서 값을 읽습니다. 이 값은 환경 변수에 포함되지 않으므로 /proc/<pid>/environ를 실행해도 유용한 정보가 나타나지 않으며, 평문이 루트 파일시스템에 기록되지도 않습니다.

유닛 파일에 적용하기 전에 파일이 정상적으로 복호화되는지 확인하십시오.

sudo systemd-creds decrypt /etc/myapp/db_password.cred -

어떤 키로 암호화했는지 파악해야 합니다. 백업의 유효 여부가 이 키에 달려 있기 때문입니다. 기본값인 --with-key=auto은 TPM2(Trusted Platform Module version 2) 칩이 존재하고 사용 가능한 경우 이를 활용하며, 그렇지 않으면 호스트 키를 사용합니다. 대부분의 VPS 인스턴스에는 TPM2가 없습니다.

systemd-analyze has-tpm2

no은 호스트 키가 사용되었음을 의미하며, 해당 키는 root만 읽을 수 있는 /var/lib/systemd/credential.secret에 저장됩니다. db_password.cred를 새로운 VPS에 복원하더라도 이 파일이 없으면 복호화가 불가능합니다. credential.secret을 백업에 포함하거나, 접근 가능한 곳에 평문으로 된 비밀 값을 별도로 보관하십시오.

Docker secrets: /run/secrets 하위의 파일

Compose는 호스트의 파일을 읽어 컨테이너 내부의 /run/secrets/<name> 경로에 마운트합니다.

services:
  app:
    image: myapp:latest
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_password
secrets:
  db_password:
    file: ./db_password.txt
docker compose exec app cat /run/secrets/db_password
docker compose exec app env | grep -i password

첫 번째 명령은 비밀 값을 출력합니다. 두 번째 명령은 DB_PASSWORD_FILE=/run/secrets/db_password만 출력하는데, 이것이 핵심입니다. 비밀 값은 컨테이너 환경 변수에 포함되지 않으므로 docker inspect 출력 결과에 나타나지 않습니다. 많은 공식 이미지가 이미 이러한 방식을 지원하며, Postgres 이미지는 POSTGRES_PASSWORD_FILE를 정확히 이런 방식으로 읽어 들입니다.

이 기능의 성격을 명확히 이해해야 합니다. Swarm 모드 외부에서는 어떤 계층에서도 암호화가 이루어지지 않습니다. ./db_password.txt는 호스트상의 일반 텍스트 파일이며, 유일한 보호 수단은 파일 모드와 소유자 설정뿐입니다. Compose는 누구나 읽을 수 있는 파일도 별다른 경고 없이 마운트하므로, 파일 모드와 소유자는 직접 설정해야 합니다. 일반 env_file 단축 설정과 비교한 장단점은 Compose 환경 파일 및 secrets 가이드에서 확인할 수 있습니다.

OpenBao와 Vault 운영의 실제 비용

OpenBao는 2023년 HashiCorp가 Vault의 라이선스를 Business Source License로 변경한 이후, Linux Foundation에서 포크(fork)한 HashiCorp Vault의 파생 프로젝트입니다. OpenBao는 MPL 2.0(Mozilla Public License)을 유지합니다. 2026년 8월 기준으로 2.6.2 버전이 최신입니다. 아래 내용은 대부분 Vault에도 동일하게 적용되는데, 이는 포크 과정에서 동일한 명령어 인터페이스를 유지했기 때문입니다.

docker pull docker.io/openbao/openbao

apt를 통한 업데이트 관리를 선호한다면 OpenBao 다운로드 페이지에서 Debian 및 Ubuntu용 패키지를 이용할 수 있습니다. 서버는 리스너(listener)와 스토리지 백엔드(storage backend)를 포함한 설정 파일이 필요합니다.

listener "tcp" {
  address       = "127.0.0.1:8200"
  tls_cert_file = "/path/to/full-chain.pem"
  tls_key_file  = "/path/to/private-key.pem"
}

storage "raft" {
  path = "/path/to/raft/data"
  node_id = "raft_node_1"
}

그런 다음 한 번 실행합니다.

bao operator init

기본적으로 루트 키를 5개의 공유(share)로 분할하며, 잠금을 해제하려면 그중 3개가 필요합니다. 이는 -key-shares 및 -key-threshold 플래그로 설정합니다. 이 과정에서 공유 키와 초기 루트 토큰이 한 번 출력되며, 이후에는 다시 확인할 수 없습니다.

이제 대부분의 비교 자료에서 생략하는 부분을 다룹니다. 재시작된 서버는 잠긴(sealed) 상태입니다. OpenBao는 루트 키를 메모리에만 보관하므로, 재시작 후에는 누군가 임계값만큼의 공유 키를 제공하기 전까지 자체 스토리지를 복호화할 수 없습니다. 따라서 커널 업데이트나 OOM(Out of Memory) 킬(kill)이 발생하면 서버가 잠긴 상태가 되어 애플리케이션이 로그인할 수 없게 됩니다.

1인용 VPS 환경에서 Shamir 분할 방식은 보안상 이점이 없습니다. 5개의 공유 키가 모두 같은 사람의 동일한 비밀번호 관리자에 저장되기 때문입니다. 자동 잠금 해제(Auto unseal)는 키를 신뢰할 수 있는 장치나 서비스로 옮깁니다. 대규모 클라우드 환경에서는 관리형 키 서비스가 그 역할을 하지만, VPS에서는 보통 보호 대상 데이터와 같은 디스크에 키 파일이 위치하게 됩니다. 이는 보안 수준을 실질적으로 낮추는 대신, 재부팅 후 서버가 스스로 복구되도록 만드는 트레이드오프입니다. 이 거래의 의미를 명확히 이해하고, 어떤 방식을 선택했는지 기록해 두어야 합니다.

Infisical: UI, 데이터베이스, 그리고 직접 관리하는 마스터 키

Infisical은 웹 인터페이스, 프로젝트, 환경, 사용자별 접근 제어 기능을 갖춘 비밀 관리 플랫폼입니다. Docker Compose를 사용하여 직접 호스팅하는 과정은 다음과 같이 간단합니다.

curl -o docker-compose.prod.yml https://raw.githubusercontent.com/Infisical/infisical/main/docker-compose.prod.yml
curl -o .env https://raw.githubusercontent.com/Infisical/infisical/main/.env.example
docker compose -f docker-compose.prod.yml up -d

마지막 명령을 실행하기 전에 .env 파일을 수정하십시오. 두 가지 값을 직접 설정해야 하며, 그중 하나는 설정 후 절대 변경해서는 안 됩니다.

openssl rand -hex 16
openssl rand -base64 32

첫 번째는 16바이트 16진수 문자열인 ENCRYPTION_KEY입니다. 이는 PostgreSQL 내부에서 비밀을 암호화하는 데 사용되는 키이므로, 이 키를 분실하면 완벽한 데이터베이스 백업본도 암호문 덩어리에 불과하게 되며, 실행 중인 인스턴스에서 이 값을 변경하면 기존 비밀을 복호화할 수 없게 됩니다. 두 번째는 세션용으로 사용되는 32바이트 base64 문자열인 AUTH_SECRET입니다. SITE_URL는 프로토콜을 포함하여 실제로 접속할 절대 URL이어야 하며, 그렇지 않으면 로그인 리다이렉트가 정상적으로 작동하지 않습니다.

실제로 필요한 것이 팀을 위한 웹 인터페이스와 환경별 분리라면, 만료 기한이 있는 데이터베이스 자격 증명보다 Infisical이 OpenBao보다 더 적합합니다. 이 경우 PostgreSQL, Redis, TLS 인증서를 직접 운영해야 하며, 이 모든 구성 요소에 대한 패치와 백업은 사용자의 책임입니다.

비밀 관리 서비스가 중단되었을 때 애플리케이션이 재시작되면 발생하는 일

이 질문은 비밀 관리 서비스를 단일 서버에 두는 것이 적절한지 결정하는 기준이 됩니다. 파일은 네트워크가 시작되기 전에도 읽을 수 있지만, 서비스는 그렇지 않습니다.

서버를 재부팅하면 애플리케이션과 OpenBao가 동시에 시작됩니다. 애플리케이션이 데이터베이스 비밀번호를 요청하지만 OpenBao는 아직 봉인된 상태이므로 요청은 실패합니다. systemd는 사람이 직접 unseal 공유 키를 입력할 때까지 애플리케이션을 반복해서 재시작합니다. 시스템이 고장 난 것은 아니지만, 정상적으로 작동하는 것도 아닙니다.

이를 해결하는 정직한 방법은 두 가지입니다. 첫째, 유닛 간의 순서를 지정하고 애플리케이션이 재시도하게 만드는 것입니다. After= 비밀 관리 서비스를 의존성으로 설정하고, Restart=on-failure와 함께 API에 과도한 부하를 주지 않을 만큼 충분히 긴 RestartSec=를 적용합니다. 둘째, 부팅 시점이 아닌 배포 시점에 비밀을 가져오는 것입니다. 비밀을 mode 600 파일이나 systemd credential로 렌더링하여, 실행 중인 시스템이 API가 아닌 파일에 의존하도록 구성합니다.

토큰 만료는 더 느린 주기로 발생하는 동일한 문제입니다. OpenBao 토큰과 리스는 유효 기간(TTL)을 가지므로, 갱신을 수행하지 않는 장기 실행 프로세스는 배포와 무관한 시점에 접근 권한을 잃게 됩니다. 해당 시점에 아무런 변경 사항이 없기 때문에 이러한 장애는 원인을 파악하기 매우 혼란스럽습니다.

저장소 자체 백업

여기에 제시된 모든 옵션에는 키가 존재하며, 해당 키가 없는 백업은 아무런 가치가 없습니다. 키가 어디에 저장되어 있는지 반드시 기록해 두십시오.

env 파일의 경우 파일 자체가 비밀 정보이므로 백업 시 반드시 암호화해야 합니다. SOPS를 사용하는 경우 암호화된 파일은 공개된 장소에 두어도 무방하지만, ~/.config/sops/age/keys.txt에 위치한 age 개인 키는 절대 분실해서는 안 됩니다. systemd 자격 증명(credentials)의 경우 .cred 파일과 함께 /var/lib/systemd/credential.secret를 백업하십시오. Infisical을 사용한다면 PostgreSQL 덤프를 생성하고 ENCRYPTION_KEY를 별도의 장소에 보관하십시오.

raft 저장소를 사용하는 OpenBao는 자체 스냅샷 기능을 제공합니다.

bao operator raft snapshot save backup.snap
bao operator raft snapshot restore backup.snap

스냅샷에는 암호화된 저장소 데이터가 포함되어 있으므로, 새로운 서버로 복구할 때도 bao operator init에서 생성한 unseal 공유 키가 필요합니다. 공유 키를 아무 곳에도 저장하지 않은 상태에서 스냅샷만 객체 저장소로 복사하는 야간 작업은 사실상 아무것도 백업하지 않는 것과 같습니다. 실제 운영 환경에서 사용하기 전에 일회용 VPS에서 복구 테스트를 반드시 수행하십시오.

감사 로깅: 누가 어떤 비밀 정보를 읽었는가

파일 시스템은 감사 추적 기능을 제공하지 않습니다. 파일 모드와 소유자는 누가 비밀 정보를 읽을 수 있는지만 알려줄 뿐, 실제로 누가 읽었는지는 알려주지 않습니다. 경로에 대한 감시(watch)를 설정하는 auditd이 가장 유사한 대안이지만, 이는 파일이 열렸다는 사실만 보고할 뿐 어떤 값이 사용되었는지는 알려주지 않습니다.

OpenBao는 명시적으로 활성화한 감사 장치(audit device)에 모든 요청을 기록합니다.

bao audit enable file file_path=/var/log/openbao_audit.log

이 로그와 관련하여 서버 운영 시 반드시 알아두어야 할 두 가지 사실이 있습니다. 요청과 응답에 포함된 대부분의 문자열은 HMAC-SHA256과 솔트(salt)를 사용하여 해시 처리되므로, 로그 자체에 평문이 포함되지 않더라도 이미 알고 있는 값을 로그와 대조할 수 있습니다. 정수와 불리언 값은 그대로 기록되므로, 숫자 형태의 비밀 정보는 이러한 해싱을 통한 보호를 받지 못합니다.

다음은 운영상의 주의 사항입니다. OpenBao는 활성화된 감사 장치가 요청을 기록할 수 없는 상태가 되면 요청에 응답하지 않으며, 장치에 차단 방식의 오류가 발생하면 문제가 해결될 때까지 요청이 대기 상태로 멈춥니다. /var/log의 디스크가 가득 차면 설계상 비밀 정보 API가 중단됩니다. 감사 로그를 위한 별도의 공간을 할당하고, 첫 장애가 발생한 뒤가 아니라 운영 첫날부터 logrotate 규칙을 적용하십시오.

어떤 셀프 호스팅 비밀 관리자를 사용해야 합니까?

장비 수와 인원수를 고려하여 선택하십시오.

  1. 장비 1대, 인원 1명: root 소유이며 서비스 사용자가 읽을 수 있는 모드 600의 env 파일을 사용합니다. 프로세스 환경에서 값을 분리해야 할 때는 systemd credentials를 추가하십시오.
  2. 장비 1대, 인원 2~5명, 설정이 이미 git에 있는 경우: age를 사용하는 SOPS를 선택합니다. 각 인원에게 키 쌍을 부여하고, .sops.yaml에 복호화가 허용된 모든 공개 키를 나열합니다.
  3. 장비 여러 대, 설정 저장소 1개, 만료되는 자격 증명이 필요 없는 경우: 여전히 age를 사용하는 SOPS가 적합합니다. 호스트마다 수신자 키를 하나씩 할당하면, 호스트 키를 탈취당해도 해당 호스트의 파일만 복호화할 수 있습니다.
  4. 장비 여러 대, 여러 팀이 존재하며 유효 기간이 있는 데이터베이스 자격 증명이 실제로 필요하고, 누군가 읽을 수 있는 감사 추적이 필요한 경우: OpenBao를 선택하십시오. 단, 봉인 해제 및 복구 훈련을 위해 매달 1시간 정도의 운영자 시간을 예산에 반영해야 합니다.

위 네 가지 경우 모두에 적용되는 원칙은 동일합니다. 명확하게 설명할 수 있는 요구 사항을 충족하는 가장 작은 도구를 실행하십시오. 비밀 관리자가 중단된 상태는 비밀 관리자가 비어 있는 상태와 구분할 수 없기 때문입니다.

FAQ

단일 VPS 환경에서 직접 호스팅하는 비밀 관리자가 가치가 있습니까?

OpenBao나 Infisical 같은 서비스를 의미한다면, 보통은 그렇지 않습니다. 한 대의 서버에서 한두 명이 운영하는 환경이라면, 600 권한의 env 파일이나 systemd 암호화 자격 증명만으로도 다른 로컬 사용자에 대해 동일한 수준의 보호를 제공합니다. 이 방식은 별도의 언실(unseal) 단계가 필요 없고 패치해야 할 추가 서비스도 없습니다. 비밀 관리 서비스는 여러 대의 서버와 여러 명의 사용자가 있거나, 수동 교체 없이 자격 증명을 만료시켜야 하는 실질적인 요구가 있을 때 비로소 가치가 생깁니다.

비밀번호 관리자와 비밀 관리자의 차이점은 무엇입니까?

비밀번호 관리자는 사람이 입력하는 자격 증명을 저장하며, 사람이 직접 잠금을 해제합니다. 비밀 관리자는 프로세스에 자격 증명을 제공하므로, 아무도 지켜보지 않는 새벽 3시에도 작동해야 합니다. 이 차이로 인해 결과가 달라집니다. 잠긴 비밀번호 관리자는 마스터 비밀번호를 다시 입력하게 만들지만, 잠긴 비밀 관리자는 잠겨 있는 동안 재시작되는 모든 서비스를 중단시킵니다.

재부팅 후 OpenBao가 잠기면 내 애플리케이션은 어떻게 됩니까?

애플리케이션이 비밀을 가져올 수 없어 시작에 실패하며, 누군가 언실 임계값(기본값은 5개 중 3개의 공유 키)을 제공할 때까지 systemd가 무한 재시작을 반복합니다. OpenBao는 루트 키를 메모리에만 보관하므로, 재시작할 때마다 다시 잠깁니다. 자동 언실(auto unseal) 기능을 켜거나(단일 VPS에서는 언실 키가 데이터와 같은 디스크에 저장된다는 점을 감수해야 합니다), 배포 시점에 비밀을 파일로 생성하여 부팅 과정이 API에 의존하지 않도록 구성하십시오.

SOPS로 암호화된 파일을 공개 저장소에 커밋해도 됩니까?

값은 암호화되어 있으므로 age 개인 키가 없는 사람은 내용을 볼 수 없습니다. 하지만 키 자체는 암호화되지 않습니다. 따라서 저장소를 보는 사람은 사용자가 STRIPE_SECRET_KEY와 SMTP_PASSWORD를 가지고 있다는 사실과 각 항목이 얼마나 자주 변경되는지 알 수 있습니다. 대부분의 프로젝트에서는 이러한 메타데이터가 허용되지만, 일부 프로젝트에서는 허용되지 않을 수 있습니다. age 개인 키는 저장소에 포함하지 말고, 수신자를 추가하거나 제거할 때마다 기존의 모든 파일에 대해 sops updatekeys을 실행하십시오.

#secrets#security#openbao#sops#systemd#self-hosting