vault의 핵심 컨셉
https://learn.hashicorp.com/tutorials/vault/getting-started-intro?in=vault/getting-started
- credentials 세트를 관리
- credentials : username, password, api tokens, TLS certificates 등 identity확인
- vault의 핵심 : 중앙에서 관리, 모든 정보를 암호화 (vault 내부 및 client 모두)
- 특징
1. 저장을 plaintext로 해도 저장된 위치가 노출될 뿐, 중요 정보는 암호화되어있음
2. 정보들 위에 access control (api token, database credential 등)을 뿌려서, 조직내 아무나 github의 소스코드에 접근하는것이 아닌, access control로만 접근할 수 있도록 함
3. 모든 정보에는 audit trail(감사 로그)이 있음. 이걸로 어떤 credentials가 어떤 웹서버에 접근했는지 알 수 있음
- vault가 app에게 credential를 주는 과정
- app은 보안에 취약하다고 가정
- app을 신뢰할 수 없음 -> dynamic secret 발급 : 만료 기간이 짧은 credential -> 로깅시스템에 기록됨
- 모든 credential은 각각의 client에 모두 unique함
- named keys를 생성해서 client에게 전달 (ex- SECRET_SERIAL_NUMBER 등) -> 암호화 할 수 있는 high level api 제공 (encrypt, decrypt, sign, verify 기능 제공) / 만료 시간으로 제한
----
vault 구성요소
https://www.joinc.co.kr/w/man/12/vault
아키텍처
storage backend : 암호회된 데이터를 저장하는 공간 (ex- s3)
barrier : vault와 stroge backend간 통신이 있을 때 barrier를 지나야함. 프록시 역할을 하며, vault에서는 암호회된 데이터만 밖으로 나올 수 있게 한다. barrier가 unsealed 상태여야만 vault가 접근할 수 있음
secret engine : secret의 관리를 책임짐. 데이터를 db나 file system에 저장, 생성, 암호화함.
audit device : 모든 접근 로그는 로깅됨
auth method : vault에 접근하는 클라이언트를 인증하고, client token을 리턴함. (ex-jwt, github)
client token : 세션 id같은 토큰. http 헤더에 토큰을 적재
secret : vault에서 관리하는 비밀 객체. 일정 주기가 만료되면 폐기됨.
seal/unseal
vault 서버 초기화 시 상태는 sealed -> unsealing 과정 필요 -> unsealing을 위해서는 unseald-key가 필요 -> unsealed 상태가 되면 barrier 안에 있는 vault의 모든 기능과 구성요소에 접근 가능
봉인 API를 호출하면 메모리에 있는 마스터 키가 폐기되고 이를 복원하기 위해서는 봉인해제 과정이 필요. 봉인에는 루트 권한이 있는 단일 작업자만 필요. 이렇게 하면 침입이 감지되었을 때 Vault 데이터를 빠르게 잠가 피해를 최소화할 수 있음.
key
SSS(shamir Secret Sharing) -> unsealed-key -> master-key -> encryption-key
오른쪽부터
1. encryption-key : secret을 암/복호화
2. master-key : encryption-key를 암호화
3. unsealed-key : master-key를 암호화
4. SSS(shamir Secret Sharing) : unsealed-key는 SSS알고리즘으로 분할 보관
encryption-key는 secret을 안전하게 암/복호화함. secret들은 storage backend에 보관되며, secret에 접근하기 위해서는 REST API를 사용함. REST API는 Create, Register, Rotate, Destroy 등의 명령어를 제공하고, secret을 제어할 수 있음. REST API를 사용하기 위해서는 토큰 인증과 토큰에 상응하는 정책 인가 작업이 필요함
seal/unseal ssh 과정 -> https://www.joinc.co.kr/w/man/12/vault 블로그의 2.11
사용자는 identifier / authentication을 요청하고 요청 성공 시 토큰을 반환함
-----
https://yenoss.github.io/2020/05/24/vault-01-secret-kv.html
key sharing
- vault는 최초 서버가 실행되면 5개의 key를 주고 서버를 sealling해둔다. sealling된 상태는 데이터 넣고 빼는(결국 encrypt,decryption) api자체가 불가하다.
- unseal을 해야하는데 그러기위해선 5개의 key중에 3개의 key를 입력해야한다. 이러한 방식은 shamir 비밀키 공유 알고리즘을 이용하며, 5개중 최소 3개가 있어야 master key를 만들수 있게된다.
- materkey가 있어야 비로소 encryption key를 만들 수 있다.
- 더 해서, key rolling도 지원해준다. key rolling을 통해 사용자는 특정 주기로 새로운 마스터키를 생성해 사용함으로 보다 안전한 운영이 가능하다.
certification issuing
- SSL을 위한 cert를 발급해준다. 특정 secret engine으로 제공해주며 , 필요한 정보를 저장하고 있어 최종적으로 사용자는 몇 가지 설정만 해두면 아주 손쉽게 cert를 발급받을 수 있다.
----
ui로 접근해서 vault 사용해보기
https://ttubeoki.tistory.com/40
vault -v
vault server -dev
vault status
export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN=""
vault status
----
aws kms를 이용한 auto unseal
https://blogs.halodoc.io/vault-auto-unseal-via-aws-kms/
---
aws kms vs vault
https://www.g2.com/compare/aws-key-management-service-kms-vs-hashicorp-vault
https://stackshare.io/stackups/aws-kms-vs-vault
AWS Key Management Service 및 Vault는 기본적으로 각각 "데이터 보안 서비스" 및 "비밀 관리" 도구로 분류됩니다.
AWS Key Management Service에서 제공하는 일부 기능은 다음과 같습니다.
- 중앙 집중식 키 관리
- AWS 서비스와 통합
- 모든 애플리케이션에 대한 암호화
반면 Vault는 다음과 같은 주요 기능을 제공합니다.
- 보안 비밀 저장소: 임의의 키/값 비밀을 Vault에 저장할 수 있습니다. Vault는 이러한 비밀을 영구 저장소에 쓰기 전에 암호화하므로 원시 저장소에 대한 액세스 권한을 얻는 것만으로는 비밀에 액세스할 수 없습니다. Vault는 디스크, 영사 등에 쓸 수 있습니다.
- 동적 비밀: Vault는 AWS 또는 SQL 데이터베이스와 같은 일부 시스템에 대해 온디맨드로 비밀을 생성할 수 있습니다. 예를 들어 애플리케이션이 S3 버킷에 액세스해야 하는 경우 Vault에 자격 증명을 요청하고 Vault는 요청 시 유효한 권한이 있는 AWS 키 쌍을 생성합니다. 이러한 동적 비밀을 생성한 후 Vault는 임대 기간이 만료되면 자동으로 해당 비밀을 취소합니다.
- 데이터 암호화: Vault는 데이터를 저장하지 않고 암호화 및 해독할 수 있습니다. 이를 통해
---
sealing/unsealing
루트권한이 있는 단일작업자만 -> 침입이 감지됐을 때 vault 데이터를 잠금
수동 sealing/unsealing
unsealing
- Seal API 호출
- Vault 서버 재시작
- Vault 저장소에서 복구할 수 없는 오류가 발생
sealing
- 터미널에서 vault operator unseal 명령을 입력 후 봉인해제 키를 차례로 입력
- Unseal API 호출
- WebUI에서 키를 차례로 입력
자동 unsealing (auto unseal)
봉인 해제 키가 아닌, recovery key(복구키)이용
Shamir 봉인을 사용한 초기화 프로세스에서 봉인해제 키가 생성되는 것처럼 자동 봉인해제로 초기화하면 복구 키가 생성됨
복구 키는 마스터 키를 해독할 수 없으므로 AutoUnseal 메커니즘이 작동하지 않는 경우 Vault를 봉인해제하기에 충분하지 않음.
API를 통하여 Vault 노드를 봉인하는 것도 여전히 가능. 이 경우 Vault는 재기동하거나 봉인해제 API가 사용될 때까지 봉인된 상태로 유지되는데, 이 때 봉인해제를 위해서는 봉인해제 키 대신 복구 키가 필요.
AutoUnseal을 지원하는 프로바이더는 HSM(Hardware Security Module) 이나 클라우드 서비스의 KMS 등이 있음.
demo
https://learn.hashicorp.com/tutorials/vault/autounseal-aws-kms?in=vault/auto-unseal
vault status : 초기상태는 sealed
vault operator init -format=json : unsealed됨
vault operator seal : sealed됨
vault operator unseal $VAULT_RK_1 : status에서 unseal progress의 상태가 1/3이 됨 (threshold는 3)
vault operator unseal $VAULT_RK_2 : status에서 unseal progress의 상태가 2/3가 됨 (threshold는 3)
vault operator unseal $VAULT_RK_3 : unsealed됨
'mlops, devops' 카테고리의 다른 글
타사 로그 파이프라인 / 모니터링 지표 수집 시스템 (0) | 2023.01.10 |
---|---|
실행중인 docker container에 restart 옵션 추가 (0) | 2022.05.18 |
fastapi context 주입 (0) | 2022.04.01 |
service 생성 후 systemd에 등록 (0) | 2022.04.01 |
로깅 시스템 및 로그 설계 (0) | 2022.03.21 |