トップ «前の日記(2015/08/27 (木) ) 最新 次の日記(2015/08/29 (土) )» 編集 RSS feed

HsbtDiary


2015/08/28 (金) [長年日記]

Windows 10 Insider Preview アカウントにした

リリース版が出た Windows 10 だけど、Insider Preview を使い続けることは設定から出来ると言えば出来るので、1週間くらい前に Fast Ring で有効にしてしまった。

早速、10525 が降ってきて known issue である Chrome 64 bit 版でひたすらクラッシュするという地雷(dev 版では既に修正済み)を踏んだり、無線LANアダプタが無効になったので有線LANに切り替えたりと色々起きているけど、それ以外はまあまあ使えてる。今日になって 10532 がリリースされたらしいので、インストールを実行して再起動されたけど 10525 のままだった。中々怪しい。

vault を触ってみた

vault という hashicorp が作っている秘匿情報を扱う次世代ソフトウェアを触ってみた

vault はクライアントであって、データストアを任意に設定するモデルなのかと思っていたけど、server と client が必要だった。バイナリ自体はどちらも同じで vault server と実行するとサーバーになる。server の url は client で

export VAULT_ADDR='http://127.0.0.1:8200'

というように指定する。とりあえず雑に試すなら vault server -dev と起動してからクライアントで操作する。

初期起動時はなんでも read/write できる、token をセットしたり、auth provider を設定するとパーミッション制限を入れることができる

$ vault write secret/hello value=world
$ vault read secret/hello
$ vault auth-enable github
$ vault write auth/github/config organization=ruby
$ vault write auth/github/map/teams/default value=root

default team を github に存在する開発者のチーム名とかにして、value を Developer とかにした上で vault で policy を適切に設定すると現実的な使い方になりそう。試してない。

データの保存先は vault server で設定する、mysql などをバックエンドにすると、mysql に対して一時的なトークン(結局はユーザーとパスワードの組)を発行することができる。expire(リース期間)という機能もあるので、オペレーションのフロー上、一時パスワードを発行する必要があるなら、今すぐ導入して使えばいいのでは、という気がしている。

バックエンドについては少し混乱しやすくて、バックエンドには

  • backends
  • Secrets backends

の2つがあって、1つ目の backends に指定できるのは http://vaultproject.io/docs/config/index.html にある etcd や mysql など。これには vault の generic type の mount(箱みたいなもん)に指定したデータやシステム設定自体が保存される。

一方の Secrets backends は http://vaultproject.io/docs/secrets/index.html にあるように上の backends と共有できるものもあるけど、出来ないものもある。出来ないものは何をするかというと、任意のデータではなく credential などを保存するストアとして vault と接続される、というイメージ。例えば、aws backends を mount すると vault から IAM を操作できるようになる。この辺、まだ MySQL ストアなどで試してないので具体的にどうなるのかは来週試す。

"-dev" ではなく、production で使う場合はどうするのか、と雑に AWS のサーバーで動かしてみた

backend "file" {
  path = "./v"
}

listener "tcp" {
  address = "your_wan_ip:8200"
  tls_disable = 1
}

こんな default.hcl を用意して sudo ./vault server -config=default.hcl で起動。あとはクライアントから vault init すると初期設定が投入される。この状態では vault はまだ seal という状態でデータを読むことができない。vault はシャットダウンすると seal 状態になって、unseal しない限りは見えなくなる。

unseal するためには init 時に生成されるキー5個の中から3つを選択して入力する。unseal したら、init 時に生成されている root 用のトークンを環境変数 VAULT_TOKEN に設定して、vault auth-enable github などを実行して、authentication backend の設定を行う。ここまでくるとクライアントで

vault auth -method=github token=your_github_token

を実行するだけで、github team に割り当てられた policy にもとづいて、vault への書き込み読み込みができるようになる。github の team と vault の policy とのマッピングの具体的な内容はもう少し検討が必要かな。

本番でまともに使うためには

  • TLS を有効にして https で接続できるようにする
  • github の team と vault の policy のマッピング
  • 入れるデータの選定(トークン, AWS の IAM 接続, mysql 接続, consul 接続)
  • アプリケーションからの取り出し方(vault-ruby)
  • 人間が使う時の使い方(パスワード発行はこうする...など)

という辺かなあ。インフラエンジニアだと、keepassX や秘蔵の excel ファイルの置き換えっすよ、ということで話は早そう。