SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor · 업데이트됨 2026-08-22

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

단일 서버 환경에서 OpenBao, Infisical, SOPS with age, systemd credentials 중 무엇을 선택해야 할지 비교합니다. 운영 복잡도와 보안 수준을 고려하여 내 서버에 가장 적합한 비밀 관리 솔루션을 결정하는 기준을 제시합니다.

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

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

실패 모드 또한 중요하게 다릅니다. 비밀번호 관리자가 잠기면 불편할 뿐이지만, 마스터 비밀번호를 다시 입력하면 해결됩니다. 비밀 관리자가 봉인되면 서비스 중단으로 이어집니다. 봉인된 상태에서 재시작되는 모든 서비스는 자격 증명 없이 실행되어 중단된 상태로 남습니다. Vaultwarden을 직접 운영하는 비밀번호 관리자로 사용하기는 사람과 관련된 문제를 잘 해결합니다. 하지만 기계와 관련된 문제는 해결하지 못하며, 애초에 그런 용도로 설계되지 않았습니다. 만약 이와 함께 사용한다면, 클라이언트가 이미 암호화하는 볼트 내용보다는 관리자 토큰과 백업 파일을 강화하는 것이 중요하며, Vaultwarden 강화 가이드에서 이 두 가지를 모두 다룹니다.

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

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

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

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

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가 잘못된 홈 디렉터리를 참조했기 때문입니다. systemd 유닛은 사용자의 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

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

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

OpenBao와 Vault 운영의 실제 비용

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

docker pull docker.io/openbao/openbao

apt를 통한 업그레이드 관리를 선호한다면 Debian 및 Ubuntu 패키지를 OpenBao 다운로드 페이지에서 찾을 수 있습니다. 서버는 리스너와 스토리지 백엔드를 포함하는 설정 파일이 필요합니다.

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개의 공유로 분할하며, 잠금을 해제하려면 그중 3개가 필요합니다. 이는 -key-shares 및 -key-threshold 플래그로 설정됩니다. 이 과정에서 공유 키와 초기 루트 토큰이 한 번 출력되며, 이후에는 다시 확인할 수 없습니다.

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

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

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

Infisical은 웹 인터페이스, 프로젝트, 환경, 사용자별 접근 제어 기능을 갖춘 비밀 관리 플랫폼입니다. 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이어야 하며, 그렇지 않으면 로그인 리다이렉트가 작동하지 않습니다.

실제로 필요한 것이 데이터베이스 자격 증명의 자동 만료가 아니라 소규모 팀을 위한 웹 인터페이스와 환경 간 분리라면, OpenBao보다 Infisical이 더 적합합니다. 이 경우 PostgreSQL, Redis, TLS 인증서를 직접 운영해야 하며, 이 모든 구성 요소를 직접 패치하고 백업해야 합니다.

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

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

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

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

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

저장소 자체 백업

여기에 나열된 모든 옵션에는 키가 필요하며, 해당 키가 없는 백업은 가치가 없습니다. 키가 어디에 있는지 기록해 두십시오.

env 파일의 경우 파일 자체가 비밀 정보이므로 백업 시 반드시 암호화해야 합니다. SOPS를 사용한다면 암호화된 파일은 공개된 장소에 두어도 되지만, ~/.config/sops/age/keys.txt에 있는 age 개인 키는 절대 분실해서는 안 됩니다. systemd 자격 증명의 경우 .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에서 복구 테스트를 수행하십시오.

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

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

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

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를 사용하십시오. 단, 봉인 해제(unsealing) 및 복구 훈련을 위해 매달 1시간 정도의 운영 시간을 예산에 반영해야 합니다.

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

FAQ

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

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

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

비밀번호 관리자는 사람이 직접 입력하는 자격 증명을 저장하며, 사용자가 직접 잠금을 해제합니다. 반면 비밀 관리 도구는 프로세스에 자격 증명을 제공하므로, 아무도 지켜보지 않는 새벽 3시에도 작동해야 합니다. 이 차이로 인해 결과가 달라집니다. 비밀번호 관리자가 잠기면 마스터 비밀번호를 다시 입력해야 하지만, 비밀 관리 도구가 봉인(seal)되면 봉인이 풀릴 때까지 재시작하는 모든 서비스가 멈추게 됩니다.

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

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

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

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

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