Vault Architecture

HashiCorp Certified: Vault Associate 2024 (w/ Hands-On Labs)
이민석's avatar
Aug 13, 2024
Vault Architecture

Vault Paths란

Vault에서 모든 요소는 path-based입니다.

  • The path prefix tells vault which component a request should be routed.

  • Secret engines, auth methods, and audit devices are “mounted” at a specific path. Otfen refereed to as a “mount”.

  • Path available are dependent on the features enabled in Vault, such as Auth Methods and Secret Engines.

  • System backend is a default backend in Vault which is mounted at the “/sys” endpoint.

  • Vault component can be enabled at ANY path you’d like using the -path flag. Each component does have a default path you can use as well.

  • Vault has a few System Reserved Path which you cannot use or remove: auth/*, cubbyhole/*, identity/*, secret/*.

    auth/* : Endpoint for auth method configuration

    cubbyhole/* : Endpoint used by the Cubbyhole secrets engine

    identity/* : Endpoint for configuration Vault Identity (entries and groups)

    secret/* : Endpoint used by Key/Value v2 secrets engine if running in dev mode

Vault Data Protection

Vault는 어떻게 데이터를 보관할까요?
어떻게 Vault가 데이터를 보호하고 아무도 데이터를 훔쳐가지 못하도록 할까요?

모든 Vault Data는 Vault Storage에 저장되며 암호화 됨을 알고 있을 겁니다.
이 때 Vault Storage의 Vault Data를 Encryption/Decryption할 때 쓰이는 Encrypytion Key*가 있습니다.

그리고 해당 Encryption Key*를 보호하기 위한 Master Key*가 있습니다.
또한 Encryption Key*가 기록되고 사용하기 위해서 Vault Node*의 In-MEM 장소에 Encryption Key*가 저장이 됩니다.

Master Key* : Encrypt/Decrypt the Encryption Key*.
- Create during Vault initialization or during a rekey operation.
- New written to storage when using traditional unseal mecahnism
- Written to core/master (storage backend) when suing Auto Unseal
Encrpytion Key* : Encrypt/Decrypt data written to Vault Storage.
- Encrypted by the Master Key
- Storaed alognside the data in a keyring on the storage backend.
- Can be easily rotated (manual operation)

Seal과 Unseal

Vault는 기본적으로 Sealed State*와 함께 실행되며 decrypt가 불가능합니다.
Sealed State*인 Vault에서는 거의 모든 작업이 불가능(no perations)하며, 오직 상태 확인 및 Unsealing만 가능합니다.
Unsealing Vault*라는 의미는 Vault Node*가 Encryption Key*를 Decrypt하기 위해서 Master Key*를 재구성(reconstruct)하는 것을 의미합니다. 이를 통해 궁극적으로 Vault Data*를 읽을 수 있게 됩니다.
Unsealing Vault* 이후, Encryption Key가 Vault Node의 In-MEM에 저장이 됩니다.

Sealed State* : Vault Node가 Encryption Key를 Decrypt 할 수 없는 상태입니다. 따라서 Vault Data 조회가 불가능합니다.
Unsealing Vault* : Master Key를 재구성하여, Vault Node가 Encryption Key를 Decrypt할 수 있게 만들어줍니다. 따라서 Vault Data 조회가 불가능합니다.

반대로 Sealing Vault*는 Encryption Key를 In-MEM에서 제거하여,
그 누구도 Vault Data 조회를 위해 Encryption Key를 사용하지 못하도록 하는 것입니다.

Vault Seal이 필요한 이유

기본적으로 Sealing*이 필요한 이유는 다음과 같습니다.

  1. 실수로 Key 조각이 노출된 경우

  2. 네트워크 레벨의 침입 및 위협이 감지된 경우

  3. Vault Node 내부에 Spyware나 Malware가 존재하는 경우

위와 같은 경우에도 Sealed Vaults는 그 값들을 안전하게 지킬 수 있습니다.

Vault Seal Options

  1. Key Sharding (Shamir)

  2. Cloud Auto Seal (integrated by KMS)

  3. Transit Vault Unseal (integrated by Several Other Vault Nodes)

Share article
RSSPowered by inblog