목차
- 패스워드가 평문으로 올라가 있던 그날의 기억
- Ansible Vault란 뭔가요? — 쉽게 풀어보기
- 왜 Ansible Vault를 써야 하나요?
- Ansible Vault vs 다른 비밀 관리 방법 비교
- Ansible Vault 기본 사용법 — 실전으로 바로 익히기
- 1단계: 암호화된 파일 만들기
- 2단계: 기존 파일 암호화하기
- 3단계: 암호화된 파일 보기/편집
- 플레이북에서 Ansible Vault 파일 활용하기
- 플레이북 실행 시 패스워드 입력
- 실제 플레이북 예시
- 멀티 Vault ID 사용하기 (Ansible 2.4+)
- CI/CD 파이프라인에서 Ansible Vault 자동화하기
- GitHub Actions에서 사용하기
- GitLab CI에서 사용하기
- ⚠️ 실제 삽질 경험과 주의사항
- 삽질 1: 패스워드 파일 끝에 개행 문자 문제
- 삽질 2: 파일 권한 설정 잊기
- 삽질 3: 암호화된 파일을 복호화 후 커밋
- 삽질 4: 패스워드 변경 후 팀원과의 공유
- 프로젝트 디렉토리 구조 모범 사례
- ansible.cfg 설정
- 검증: 제대로 작동하는지 확인하기
- 암호화 상태 확인
- 보안 검사 체크리스트
- 자주 묻는 질문 (FAQ)
- Q. Vault 패스워드를 잊어버리면 어떻게 되나요?
- Q. Ansible Vault로 암호화한 파일을 Git에 올려도 정말 안전한가요?
- Q. Ansible Vault와 HashiCorp Vault는 어떻게 다른가요?
- Q. 암호화된 파일을 복호화 없이 diff로 비교할 수 있나요?
- 마무리 — 자동화 보안은 습관이에요
Ansible Vault를 활용한 민감 정보 안전 관리 및 자동화 보안 강화
패스워드가 평문으로 올라가 있던 그날의 기억
인프라 자동화를 처음 시작했을 때 저도 이런 실수를 했었거든요. GitHub에 Ansible 플레이북을 올려놨는데, 나중에 보니까 DB 패스워드가 그냥 평문으로 변수 파일에 박혀 있는 거예요. 다행히 프라이빗 레포였지만... 식은땀이 쫙 흘렀습니다. 혹시 이런 경험 있으신가요?
자동화를 하다 보면 어쩔 수 없이 민감 정보를 어딘가에 저장해야 해요. API 키, DB 패스워드, SSL 인증서 개인키, 클라우드 자격증명... 이런 것들을 플레이북과 함께 관리해야 하는데, 그냥 평문으로 두면 보안 사고의 씨앗이 됩니다. Ansible Vault(앤서블 볼트)는 바로 이 문제를 해결하기 위해 Ansible이 기본 제공하는 암호화 도구예요.
13년 동안 인프라를 운영하면서 직접 써보고 정리한 Ansible Vault 실전 가이드를 공유해 드릴게요. 단순한 기능 소개가 아니라, 실제 운영 환경에서 어떻게 쓰는지, 어디서 삽질하는지까지 솔직하게 담았습니다.
▲ Ansible Vault가 플레이북 실행 흐름에서 어떤 역할을 하는지 보여주는 전체 아키텍처 개요도
Ansible Vault란 뭔가요? — 쉽게 풀어보기
Ansible Vault는 Ansible에 내장된 암호화 기능으로, 민감한 데이터를 AES256 알고리즘으로 암호화해서 안전하게 저장할 수 있게 해줍니다. 쉽게 말해, 중요한 정보를 금고(Vault)에 잠가두고, 플레이북 실행 시에만 열쇠(패스워드)로 꺼내 쓰는 방식이에요.
왜 Ansible Vault를 써야 하나요?
- Git 저장소에 민감 정보가 노출되는 사고 예방
- 팀 협업 시 보안 정책 일관성 유지
- CI/CD 파이프라인에서 자격증명 안전하게 주입 가능
- 별도 외부 솔루션 없이 Ansible 자체 기능으로 해결
- 암호화된 파일도 Git으로 버전 관리 가능 (이게 진짜 장점이에요!)
Ansible Vault vs 다른 비밀 관리 방법 비교
| 방법 | 장점 | 단점 | 적합한 환경 |
|---|---|---|---|
| Ansible Vault | 별도 설치 불필요, Git 통합, 무료 | 중앙 집중 관리 어려움 | 소규모~중규모 팀 |
| HashiCorp Vault | 중앙 집중 관리, 동적 시크릿 | 별도 인프라 필요, 복잡 | 대규모 엔터프라이즈 |
| AWS Secrets Manager | 완전 관리형, IAM 통합 | 비용 발생, AWS 종속 | AWS 기반 환경 |
| 환경 변수 | 간단함 | 버전 관리 불가, 휘발성 | 임시/개발 환경 |
저는 홈랩이나 소규모 프로젝트에서는 Ansible Vault로 시작해서, 규모가 커지면 HashiCorp Vault와 연동하는 방식을 쓰고 있어요. 처음부터 무거운 솔루션 도입할 필요 없거든요.
Ansible Vault 기본 사용법 — 실전으로 바로 익히기
1단계: 암호화된 파일 만들기
가장 기본적인 사용법부터 시작해봐요. ansible-vault create 명령어로 처음부터 암호화된 파일을 생성할 수 있어요.
# 새 암호화 파일 생성
ansible-vault create secrets.yml
# 실행하면 Vault 패스워드 입력 프롬프트가 나옵니다
New Vault password:
Confirm New Vault password:
패스워드 입력 후 에디터가 열리면 이렇게 민감 정보를 입력하면 됩니다.
# secrets.yml 내용 (에디터에서 입력)
db_password: "SuperSecret123!"
api_key: "sk-abcdef1234567890"
aws_secret_key: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
저장하고 나면 파일이 암호화되어 저장돼요. 파일 내용을 cat으로 보면 이렇게 나옵니다.
$ cat secrets.yml
$ANSIBLE_VAULT;1.1;AES256
38653062373966613533626338363537333831626661316534333637626163623934
63396534653131646133366432393463376433333461303162646537323335333261
3437623961373265663365376666336237363430656636340a303839353332626163
...
이 상태로 Git에 올려도 안전하다는 게 핵심이에요. 🎉
2단계: 기존 파일 암호화하기
이미 만들어진 파일을 나중에 암호화하고 싶을 때는 encrypt 명령어를 씁니다.
# 기존 파일 암호화
ansible-vault encrypt group_vars/all/vault.yml
# 특정 문자열만 암호화 (Ansible 2.3+)
ansible-vault encrypt_string 'SuperSecret123!' --name 'db_password'
encrypt_string은 진짜 유용해요. 파일 전체를 암호화하지 않고, 변수 파일 안에서 특정 값만 암호화할 수 있거든요. 실제 사용 예시를 보면:
# group_vars/all/main.yml (일반 변수와 암호화 변수 혼재)
app_name: "myapp"
app_port: 8080
db_host: "db.internal"
db_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
38653062373966613533626338363537333831626661316534333637626163623934
63396534653131646133366432393463376433333461303162646537323335333261
3437623961373265663365376666336237363430656636340a303839353332626163
...
이렇게 하면 파일 전체가 암호화되지 않아서 Git diff도 깔끔하게 볼 수 있어요. 저는 이 방식을 더 선호합니다.
3단계: 암호화된 파일 보기/편집
# 내용 확인 (복호화해서 보기)
ansible-vault view secrets.yml
# 내용 수정
ansible-vault edit secrets.yml
# 패스워드 변경
ansible-vault rekey secrets.yml
▲ ansible-vault encrypt → Git 저장 → 플레이북 실행 시 복호화까지의 전체 흐름도
플레이북에서 Ansible Vault 파일 활용하기
플레이북 실행 시 패스워드 입력
Vault로 암호화된 변수를 사용하는 플레이북을 실행할 때는 패스워드를 제공해야 해요. 방법이 몇 가지 있습니다.
# 방법 1: 실행 시 프롬프트로 입력
ansible-playbook site.yml --ask-vault-pass
# 방법 2: 패스워드 파일 사용 (자동화에 적합)
ansible-playbook site.yml --vault-password-file ~/.vault_pass
# 방법 3: 환경 변수로 패스워드 파일 지정
export ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass
ansible-playbook site.yml
⚠️ 중요! 패스워드 파일은 절대 Git에 올리면 안 됩니다. .gitignore에 반드시 추가하세요.
# .gitignore
.vault_pass
*.vault_pass
.vault_password
실제 플레이북 예시
이렇게 암호화된 변수를 플레이북에서 쓰는 건 일반 변수랑 완전히 똑같아요. Ansible이 알아서 복호화해서 넣어줍니다.
---
# site.yml
- name: Deploy Application
hosts: webservers
vars_files:
- group_vars/all/main.yml
- group_vars/all/secrets.yml # 암호화된 파일
tasks:
- name: Configure database connection
template:
src: templates/db.conf.j2
dest: /etc/myapp/db.conf
mode: '0600'
# db_password 변수는 secrets.yml에서 복호화되어 사용됨
- name: Set API key environment variable
lineinfile:
path: /etc/myapp/env
line: "API_KEY={{ api_key }}"
create: yes
멀티 Vault ID 사용하기 (Ansible 2.4+)
이건 좀 고급 기능인데, 실무에서 정말 유용해요. 개발/스테이징/프로덕션 환경마다 다른 패스워드를 쓰고 싶을 때 Vault ID를 활용하면 됩니다.
# 환경별 다른 패스워드로 암호화
ansible-vault encrypt group_vars/dev/secrets.yml --vault-id dev@~/.vault_pass_dev
ansible-vault encrypt group_vars/prod/secrets.yml --vault-id prod@~/.vault_pass_prod
# 실행 시 여러 Vault ID 지정
ansible-playbook site.yml \
--vault-id dev@~/.vault_pass_dev \
--vault-id prod@~/.vault_pass_prod
처음엔 이게 뭔가 싶었는데, 실제로 멀티 환경을 관리해보니까 이게 없으면 정말 불편하더라고요. 강력 추천합니다!
CI/CD 파이프라인에서 Ansible Vault 자동화하기
자동화 보안 강화의 핵심은 CI/CD 파이프라인에서 Vault 패스워드를 안전하게 다루는 거예요. 제가 GitLab CI와 GitHub Actions에서 실제로 쓰는 방법을 공유할게요.
GitHub Actions에서 사용하기
# .github/workflows/deploy.yml
name: Deploy with Ansible
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install Ansible
run: pip install ansible
- name: Create vault password file
run: printf '%s' "${{ secrets.ANSIBLE_VAULT_PASSWORD }}" > ~/.vault_pass
- name: Run Ansible Playbook
run: |
ansible-playbook -i inventory/production site.yml \
--vault-password-file ~/.vault_pass
env:
ANSIBLE_HOST_KEY_CHECKING: 'false'
- name: Cleanup vault password
if: always()
run: rm -f ~/.vault_pass
GitHub Secrets에 ANSIBLE_VAULT_PASSWORD를 등록해두면 됩니다. 💡 팁: printf '%s'로 개행 문자를 제거하고, if: always()로 패스워드 파일 정리를 보장하는 것 잊지 마세요!
GitLab CI에서 사용하기
# .gitlab-ci.yml
deploy:
stage: deploy
image: willhallonline/ansible:latest
script:
- printf '%s' "$VAULT_PASSWORD" > ~/.vault_pass
- chmod 600 ~/.vault_pass
- ansible-playbook -i inventory/production site.yml \
--vault-password-file ~/.vault_pass
after_script:
- rm -f ~/.vault_pass
only:
- main
⚠️ 실제 삽질 경험과 주의사항
이 부분이 진짜 핵심입니다. 문서에는 없는 내용들이에요.
삽질 1: 패스워드 파일 끝에 개행 문자 문제
패스워드 파일을 만들 때 echo를 쓰면 끝에 개행 문자가 붙어요. 이게 패스워드 불일치 오류를 일으키는 경우가 있었습니다. 진짜 한참 헤맸어요 ㅎㅎ
# 잘못된 방법 (개행 문자 포함)
echo "mypassword" > ~/.vault_pass
# 올바른 방법 (개행 문자 제외)
printf '%s' "mypassword" > ~/.vault_pass
# 또는
echo -n "mypassword" > ~/.vault_pass
삽질 2: 파일 권한 설정 잊기
패스워드 파일은 반드시 소유자만 읽을 수 있게 권한 설정을 해야 해요. 안 하면 Ansible이 경고를 내거나 보안 감사에서 걸립니다.
chmod 600 ~/.vault_pass
삽질 3: 암호화된 파일을 복호화 후 커밋
편집하려고 ansible-vault decrypt로 복호화한 다음 그냥 커밋해버리는 실수. pre-commit 훅으로 방지할 수 있어요.
# .pre-commit-config.yaml
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.4.0
hooks:
- id: detect-private-key
# Vault 파일이 복호화된 상태로 커밋되는 것 방지
- repo: local
hooks:
- id: check-vault-encrypted
name: Check vault files are encrypted
entry: bash -c 'for f in $(git diff --cached --name-only | grep "vault"); do head -1 $f | grep -q "\\$ANSIBLE_VAULT" || (echo "$f is not encrypted!" && exit 1); done'
language: system
pass_filenames: false
삽질 4: 패스워드 변경 후 팀원과의 공유
패스워드를 변경(rekey)했을 때 팀원들한테 새 패스워드를 안전하게 전달하는 방법이 의외로 고민이에요. 저는 회사에서는 1Password나 Bitwarden 같은 팀 패스워드 매니저를 쓰고, 홈랩에서는 직접 암호화된 메시지로 전달합니다.
▲ CI/CD 파이프라인에서 Ansible Vault를 안전하게 활용하는 보안 모범 사례 구성도
프로젝트 디렉토리 구조 모범 사례
Ansible 보안을 제대로 하려면 디렉토리 구조부터 잘 잡아야 해요. 제가 실제로 쓰는 구조를 공유합니다.
ansible-project/
├── ansible.cfg
├── site.yml
├── inventory/
│ ├── production/
│ │ ├── hosts
│ │ └── group_vars/
│ │ ├── all/
│ │ │ ├── main.yml # 일반 변수 (Git 공개)
│ │ │ └── vault.yml # 암호화된 변수 (Git 공개 OK)
│ │ └── webservers/
│ │ ├── main.yml
│ │ └── vault.yml
│ └── staging/
│ └── group_vars/
│ └── all/
│ ├── main.yml
│ └── vault.yml
├── roles/
│ └── myapp/
│ ├── tasks/
│ ├── templates/
│ └── defaults/
│ └── main.yml
├── .gitignore # .vault_pass 포함
└── .vault_pass # 절대 Git에 올리지 마세요!
💡 팁: group_vars 안에 vault.yml 파일을 별도로 두는 게 좋아요. 일반 변수와 암호화 변수를 분리하면 관리가 훨씬 편해집니다. 어떤 값이 암호화되어 있는지 한눈에 파악되거든요.
ansible.cfg 설정
# ansible.cfg
[defaults]
inventory = inventory/production
vault_password_file = ~/.vault_pass
host_key_checking = False
[privilege_escalation]
become = True
become_method = sudo
검증: 제대로 작동하는지 확인하기
드디어 됐다! 싶을 때 실제로 잘 작동하는지 확인하는 방법들이에요.
암호화 상태 확인
# 파일이 암호화되어 있는지 확인
head -1 group_vars/all/vault.yml
# 출력: $ANSIBLE_VAULT;1.1;AES256 이면 정상
# 복호화해서 내용 확인
ansible-vault view group_vars/all/vault.yml
# 플레이북에서 변수가 제대로 로드되는지 확인 (--check 모드)
ansible-playbook site.yml --check --vault-password-file ~/.vault_pass
# 특정 호스트에서 변수 값 확인
ansible webservers -m debug -a "var=db_password" --vault-password-file ~/.vault_pass
보안 검사 체크리스트
- ✅ .vault_pass 파일이 .gitignore에 포함되어 있나요?
- ✅ .vault_pass 파일 권한이 600인가요?
- ✅ vault.yml 파일이 $ANSIBLE_VAULT로 시작하나요?
- ✅ CI/CD에서 패스워드 파일이 실행 후 삭제되나요?
- ✅ 팀 패스워드 매니저에 Vault 패스워드가 등록되어 있나요?
- ✅ pre-commit 훅으로 평문 커밋을 방지하고 있나요?
▲ Ansible Vault 도입 후 보안 체크리스트 항목별 검증 결과 대시보드 예시
자주 묻는 질문 (FAQ)
Q. Vault 패스워드를 잊어버리면 어떻게 되나요?
솔직히 말씀드리면... 복구 방법이 없어요. AES256 암호화라서 패스워드 없이는 복호화가 불가능합니다. 그래서 패스워드는 반드시 팀 패스워드 매니저에 백업해두는 게 필수예요. 저도 초기에 홈랩에서 패스워드 날려먹고 파일 다시 만든 경험이 있습니다 😅
Q. Ansible Vault로 암호화한 파일을 Git에 올려도 정말 안전한가요?
AES256 암호화를 사용하고 패스워드가 충분히 강력하다면 네, 안전합니다. 물론 패스워드 자체가 노출되면 의미가 없으니 패스워드 관리가 핵심이에요.
Q. Ansible Vault와 HashiCorp Vault는 어떻게 다른가요?
Ansible Vault는 파일 기반 암호화 도구고, HashiCorp Vault는 독립적인 비밀 관리 플랫폼이에요. 규모와 요구사항에 따라 선택하면 됩니다. Ansible에는 HashiCorp Vault와 연동하는 lookup 플러그인도 있어요. 이 부분은 다음 글에서 자세히 다룰 예정입니다!
Q. 암호화된 파일을 복호화 없이 diff로 비교할 수 있나요?
파일 전체가 암호화된 경우엔 어렵고, encrypt_string으로 값만 암호화하면 나머지 키 이름은 평문으로 보여서 어느 정도 파악이 가능해요. 그래서 저는 encrypt_string 방식을 더 선호합니다.
마무리 — 자동화 보안은 습관이에요
Ansible Vault를 처음 도입할 때 "이게 과연 필요한가?" 싶을 수 있어요. 근데 한 번이라도 민감 정보가 노출되는 경험을 하고 나면 생각이 달라집니다. 저처럼요 ㅎㅎ
정리하자면 Ansible Vault를 활용한 민감 정보 관리의 핵심은 이렇습니다.
- 모든 민감 정보는 Vault로 암호화해서 저장
- 패스워드 파일은 절대 Git에 올리지 말고, 팀 패스워드 매니저에 백업
- CI/CD에서는 환경 변수나 시크릿 저장소를 통해 패스워드 주입
- pre-commit 훅으로 실수로 평문 커밋하는 것 방지
- 멀티 환경이라면 Vault ID로 환경별 패스워드 분리
이 정도만 지켜도 자동화 보안 수준이 확 올라갑니다. 처음엔 좀 번거로워 보여도, 한 번 셋업해두면 그 다음부턴 자연스럽게 쓰게 되더라고요. 이거 진짜 편하거든요! ✅
다음 글에서는 HashiCorp Vault와 Ansible을 연동해서 동적 시크릿을 관리하는 방법을 다뤄볼 예정이에요. Ansible Vault만으로 부족함을 느끼시는 분들께 도움이 될 것 같습니다.
'IT > Cloud' 카테고리의 다른 글
| [Cloud] GitHub Actions 자체 호스팅 러너 보안 강화: 백도어 방지 및 2026년 최신 가이드 (0) | 2026.04.16 |
|---|---|
| [Cloud] 쿠버네티스 보안: RBAC 권한 오남용 방지 및 클라우드 계정 탈취 대응 전략 (0) | 2026.04.14 |
| [Cloud] AWS EC2 자동 복구 설정 가이드 (2026년) (2) | 2026.04.14 |
| [Cloud] Pulumi vs Terraform: 2026년 IaC 도구 완벽 비교 분석 (0) | 2026.04.09 |
| [Cloud] Terraform State 관리 보안: 1.7+ Remote Backend & 암호화 설정 가이드 (0) | 2026.04.09 |
| [Cloud] GitHub Actions OIDC로 AWS/GCP/Azure 클라우드 보안 강화 가이드 (2026년 최신) (1) | 2026.04.07 |