Ansibleのlookupを使って秘密鍵を配備する

SHU-METAL DEATH。 現在、首都高で渋滞にハマっているので、Ansibleの小ネタシリーズのストックをはきだしています。

Ansibleでサーバの構成管理を行う時、サーバに秘密鍵を配備する場合があります。 この時、秘密鍵を変数化した上でvaultで暗号化する方法が一般的に知られています（Ansible Vaultを利用して秘密情報を暗号化する）。 しかし、vaultパスワードの設定やパスワードファイルの指定が意外とメンドクサイ。 今回はvaultを利用しない方法を紹介します。

構成管理とバージョン管理

秘密鍵を暗号化しない方法を説明する前に、構成管理とバージョン管理について整理しておきます。

Ansibleなど構成管理ツールを利用するメリットのひとつは、サーバの設定を設定ファイルなどで定義し、そのファイルをバージョン管理できることです。 リポジトリでバージョン管理しておけば、変更履歴を追うことができます。 また、特定のリビジョンの設定ファイルを取得すれば、ある時点でのサーバを復元することもできるわけです（必要にならないことを祈りますが...）

ところが、AWSのアクセスキーや秘密鍵など、バージョン管理に含めることが御法度な情報もあるのが現実です。 Admin権限を持ったAWSのアクセスキーなどがGitHubなどで漏洩すると洒落になりません...。 プライベートリポジトリとはいえ、鍵を扱うのは慎重になるべきです。

原則として、バージョン管理システムにAWSのアクセスキーや秘密鍵を登録すべきではありません。 しかし、すべての情報をバージョン管理するメリットが大きいことも事実です。 このような背景から、Ansibleでは、vaultによる暗号化をサポートしており、機密情報は暗号化して管理できるようになっています。

lookupプラグインで秘密鍵をコピーする

現実問題として、秘密鍵やAWSのアクセスキーなどは別の管理方針となっていることも多いと思います。 例えば、秘密鍵を.sshディレクトリに、AWSのアクセスキーを.awsディレクトリに保存する、などのルールがあるでしょう。 また、サーバにアクセスするためにはそれらの鍵は必要なので、わざわざバージョン管理システムで多重管理する必要もありません。

このような場合、ローカルファイルをlookupプラグインする方法が有効です。 ローカルファイルを参照し、秘密鍵をサーバに作成するならば、copyモジュールとlookupプラグインを利用して次のように記述できます。

- name: private key for slave server
  copy: dest=~/.ssh/slave.pem mode=600 
        content="{{ lookup('file', '~/.ssh/slave.pem') }}"

まとめ

vaultによる暗号化とローカルファイルのlookupは、どちらが良いかは状況によるでしょう。 どうしてもバージョン管理で管理したい事情があるのであれば、valutによる暗号化一択となります。 しかし、秘密鍵のやりとりを含め、別途管理しているのであれば、lookupでローカルファイルにアクセスする方がベターだと思います。

なお、なんでもlookupした場合、破綻の音しか聞こえないのでご注意ください...。