CodeanywhereでAWSにアクセスする場合にクレデンシャルの管理をどうしようか思案中。
aws configure で.aws配下に平文で置いておくのはなんだか気持ち悪いし、exportで環境変数都度設定するとミスしそうだし、履歴に残るから都度消したり手間かかるしなんか嫌だなーと思ってしまったのでHashiCorp社のVaultを試してみました。
インストール対象
今回は、CodeanywhereのUbuntu 14.04のBlankスタックにインストール
インストール
$ wget https://releases.hashicorp.com/vault/0.9.6/vault_0.9.6_linux_amd64.zip $ unzip vault_0.9.6_linux_amd64.zip $ sudo mv vault /usr/local/bin/
設定
設定ファイルを作成する。場所はお好みで。
$ sudo mkdir -p /etc/vault/ $ sudo vi /etc/vault/config.hcl
内容はこんな感じ。こちらもお好みで修正を。
公式ドキュメントはこちら。
https://www.vaultproject.io/docs/configuration/index.html
/etc/vault/config.hcl
backend "file" {
path = "/mnt/vault/data"
}
listener "tcp" {
address = "127.0.0.1:8200"
tls_disable = 1
}
vaultへの接続はhttpsになるけれど、tlsを無効にしているのでhttpでつながないといけない。
接続アドレスを変更するために環境変数を書き換える。
export VAULT_ADDR=http://127.0.0.1:8200
毎回打つのがめんどくさかったら、.bashrcとか.envrcとかに書いておく。
起動
$ sudo vault server -config /etc/vault/config.hcl
これだとフォアグラウンドのプロセスで動く。
バックグランドで動かしたい場合はこんな感じ。
標準出力をログファイルに出力するようにしてみた。
$ sudo vault server -config /etc/vault/config.hcl & > /var/log/vault &
初期化
まずはSeal/Unsealの基本的な考え方について
https://www.vaultproject.io/docs/internals/architecture.html
Encryption KeyはMaster Keyによって暗号化されていてMaster keyはkey Sharesに分割されている？
vaultが起動した時は、情報はSealされており、Unsealすることでアクセスができるようになる。
この時にMaster keyを何分割してそのうち、何個のKey Shareを使えばUnseal出るかを初期化する時に決める必要がある。
細かく分割すればするほどセキュリティは上がりそうだけど、個人利用且つ利用感のお試しをしたいのでひとまず、1にした。
$ vault operator init -key-shares=1 -key-threshold=1
-key-shares -key-threshold は省略可能で、指定しない場合の扱いはこんな感じ。
$ vault operator init # 下のパラメータを与えたのと同義 $ vault operator init -key-shares=5 -key-threshold=3
initを実行したらこんな感じの内容が出力される。
vault operator init Unseal Key 1: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Initial Root Token: aaaaaaaa-bbbb-cccc-eeee-ffffffffffff Vault initialized with 5 key shares and a key threshold of 3. Please securely distribute the key shares printed above. When the Vault is re-sealed, restarted, or stopped, you must supply at least 3 of these keys to unseal it before it can start servicing requests. Vault does not store the generated master key. Without at least 3 key to reconstruct the master key, Vault will remain permanently sealed! It is possible to generate new unseal keys, provided you have a quorum of existing unseal keys shares. See "vault rekey" for more information.
Unseal KeyとInitial Root Tokenを忘れないようにメモっとく。
これで利用準備が整ったので、Unsealしてアクセスできるようにする。
$ vault operator unseal
init した時に教えてもらったUnseal Key 1を入力するとこんな内容が出力される。
SealedがfalseになっているのでUnsealできた。
Key Value --- ----- Seal Type shamir Sealed false Total Shares 1 Threshold 1 Version 0.9.6 Cluster Name vault-cluster-54c90050 Cluster ID 27ca01b0-4994-3997-e9cd-4e0838866593 HA Enabled false
Unsealまで終わるとログインができるようになるのでRoot Tokenを使ってログインする。
$ vault login <Root Token>
こんな感じでログがでる。
Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token <Root Token> token_accessor ffffffff-ffff-ffff-ffff-ffffffffffff token_duration ∞ token_renewable false token_policies [root]
コマンドが無事通ればログイン完了。
$ vault secrets list Path Type Description ---- ---- ----------- cubbyhole/ cubbyhole per-token private secret storage identity/ identity identity store secret/ kv key/value secret storage sys/ system system endpoints used for control, policy and debugging
ユーザーIDとパスワードで認証する
ユーザーIDとパスワードで認証できるようにする。
Githubとかでも認証できるようだが、まずはお手軽そうなユーザーIDとパスワードの認証を試す。
ユーザー追加
まずはユーザーに割り当てる権限を用意するため、policy.hclというファイルを用意する。
~/policy.hcl
path "auth/token/lookup-self" {
policy = "read"
}
path "secret/*" {
policy = "write"
}
$ vault policy write secret-all ~/policy.hcl
secret配下全てに書き込み権限を与える設定
secretは階層構造になっているので、secret/a配下だけアクセスできるユーザーや
secret/b配下にしかアクセスできないユーザーを作ったりできる。
今回はお勉強用なので細かい制御はスキップ。
$ vault auth enable userpass $ vault write auth/userpass/users/ore password=foo policies=secret-all
これで ore という名前のユーザーが追加された。
追加したユーザーでログイン。
vaultのコマンドを見ているとログアウトに関するコマンドがパッと見つからなかった。
ひとまずログインをし直すことでユーザーを切り替えれたのでひとまずログアウトのことは忘れる。
$ vault login -method=userpass username=ore Password (will be hidden): Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token 2f137625-a0ce-790f-9180-658101969563 token_accessor 4f621a45-f65f-dbde-4335-368341c49b82 token_duration 768h token_renewable true token_policies [admins default] token_meta_username ore
パスワードを聞かれるので入力し、認証が通ると上記のようにトークンが発行される。
シークレットを追加
追加
$ vault write secret/a1 value=11
参照
$ vault read secret/a1 Key Value --- ----- refresh_interval 768h value 11
$値だけ取得したい場合はこちら
$ vault read -field "value" secret/a1 11
direnvと組み合わせてディレクトリごとに自動的にAWSのクレデンシャルを切り替える
やってみたけど、イケてない・・・もっとクールな方法があるはず。
要検討。
ディレクトリの作成
direnvで環境を切り替えたいディレクトリを作成。
$ mkdir -p /PATH/TO/TARGET_DIR
VaultにAWSのクレデンシャルの登録
今回はsecret配下にディレクトリ名毎のパスで階層を区切って登録する。
.envrcの内容をディレクトリ毎に都度書き換える対応をしていると事故しそうなのでディレクトリとsecretをマッピングするような形にした。
この辺はもっと詰めていけば良い方法があるはず。
まずは、クレデンシャルを登録。
vault write secret/PATH/TO/TARGET_DIR/AWS_ACCESS_KEY_ID value=AKI***************** vault write secret/PATH/TO/TARGET_DIR/AWS_SECRET_ACCESS_KEY value=****************************************
次に対象のディレクトリで.envrcを作成。
$ cd /PATH/TO/TARGET_DIR $ direnv edit .
以下の内容を追加。
DIR=`pwd` export AWS_ACCESS_KEY_ID=$(vault read -field "value" secret$DIR/AWS_ACCESS_KEY_ID) export AWS_SECRET_ACCESS_KEY=$(vault read -field "value" secret$DIR/AWS_SECRET_ACCESS_KEY) export AWS_DEFAULT_REGION=ap-northeast-1
これでこのディレクトリに入ったらvault経由でディレクトリ単位でクレデンシャルの環境変数が書き換わる。
vault経由でクレデンシャルを取得するためには、
- Unsealしてアクセス可能な状態にする。
- vaultにログインしてデータを参照可能にする。
という2段階の作業を行わないとクレデンシャルが利用できなくなり、平文でのクレデンシャルを保管するaws configureよりもセキュアになった気がする。
このままだとhistoryにクレデンシャルが残ったままなので対象となりそうなやつだけ抜き取って消す方が綺麗だけどめんどくさいので今回は全部削除。
$ history -c && history -w
まとめ
- クレデンシャルを平文で保管しないのでセキュアになった気がする。
今後しないといけないこと
- vaultにログインするためのベストな方法の検証。Githubとかで認証できるようにした方が良い？
- Vault Serverを都度立ち上げるのも面倒なので、スクリプト組むかcronの@rebootで起動するとかして自動起動させる。
- direnvとsecretの関連付けの最適な方法の検討。今回使った関連付けだとディレクトリとAWSのアカウントが1対1の関係で固定化されてしまう。
