Vault/Terraform Enterprise

こんにちは。久しぶりの投稿です。 まだ生きてます。 HasiCorpの3製品Consul/Vault/Terraformに関して正式に認定を受けたのですが、Enterpriseの機能はドキュメントを読んだだけではややこしくてわかりにくいと思いましたので、Vault Enterpriseの機能に関して紹介します。

ところで・・・

Vault OSS

Vaultに関しては皆さん知ってますよね。え?知らない?

知らないという声が多かったような気がするので、機能を軽くおさらいします。

概要

Vaultは一言で言うとデジタル時代の金庫という認識で大丈夫。漏れると困る情報を保管しておくにはもってこい。

コンセプトを実現するために実装されている機能は大きく分けて次の3つです。

  • Secret Management
  • Authentication
  • Transit

最近はhelm chartが準備されていて、OSS版はkubernetes環境で気軽にお試しいただけます。

日本ではあまり事例がないようですが、海外では漏洩事件が発生した企業が続々利用しています。 ユースケースとして大きく取り上げているのはSecrets ManagementとData Encryptionですね。

Secret Engine

Secretは静的なものと動的なものがあります。静的なものはkey/valueとして扱われます。動的なものは特別にDynamic Secretと呼びます。これらの実装をSecret Enginsと呼びます。 いずれもVaultのstorageに保存される前にメモリ内で暗号化され、保存されている情報は暗号化された状態となります。

Dynamic Secretは様々な用途のものが用意されています。

Auth Method

AuthenticationはSecretのPolicyを設定したりRead/Writeするために必要なTokenを生成します。Vault Tokenを生成するために様々な方法が実装されており、Auth Methodと呼びます。

User/Pass認証、LDAP/GitHubやその他Cloud Providerなどを通してVault Tokenを生成する方法が実装されています。

TokenにはPolicyとTTL、利用回数など細やかな制限を定義することが可能となっています。

Transit

VaultのCaaS(cryptograpy as a service)/EaaS(encryption as a service)として実装されています。SecretはVaultのStorageに保存されず、安全にアプリケーションのEncryption/Decription実装を省くことができます。


ここから

Vault Enterprise

Enterpriseの主な機能。

  • Replication
  • Performance Standbys
  • Control Group
  • Sentinel

Replication

Disaster RecoveryとPerformance Replicaの2種類が存在します。いずれもVault ClusterのPrimary/Secondary構成をとりますが、それぞれ挙動が異なるためサービスのアーキテクチャやユースケースによってによって使い分け/組み合わせる必要があります。

  • Disaster Recovery
    SecondaryはPrimaryの完全な複製と考えてよく、Active/Standbyのステートをとります。Primaryが障害等で破壊された場合にSecondaryを昇格してPrimaryとして役割を果たすことができる構成。SecondaryはクライアントからのRequestを処理できない。
  • Performance Replica SecondaryはクライアントからのRequestを処理できるが、Tokenの情報はPrimary/Secondaryそれぞれ保持している。Persistentな情報は同期されているため、処理能力が足りない場合に選択する機能。

この比較表がわかりやす。

Performance Standbys

Vault ClusterはActive/Standby構成をとりますが、StandbyノードはClientからRequestを受けてもActiveノードに転送するだけでRequestは処理しません。Performance StandbysはRead Request(key/value secretsのGET、transit secretsのencryption/decryption)を処理できるStandbyです。あとは、わかるな・・・

Performance Standby

Control Group

特定のEndpoint(Path)に対してIdentity groupsごとに承認を要求する機能です。 機密データにアクセスするために上司の承認が必要な場合などに利用できます。

IntegrationとOperationgが大変そうなので、サービスとして利用する場合はユーザにはわかりやすいUXを準備してあげないと厳しそうな機能です!

Sentinel

HashiCorp Enterprise製品で利用できるPolicy as Codeです。OSS版ではACLのみPolicyを適用することが可能となっていますが、Enterprise版ではACLに加えRole Governing Policies(RGPs)/Endpoint Governing Policies(EGPs)を設定することが可能です。

  • Role Governing Policies
    TokenやIdentity entities/groupsなどに関連したPolicyを適用することが可能。
  • Endpoint Governing Policies VaultのEndpoint(Path)に関連したPolicyを適用することが可能。

ざっと気になる機能を説明してみました。もっとたくさん機能があるよ。 最近HashiCorpのDocumentが良くなって学習も捗るのでぜひ触ってみてください!

んではっ