Dockerランタイム
Docker実行時にKeeper Secrets Managerからシークレットを取得
最終更新
Docker実行時にKeeper Secrets Managerからシークレットを取得
最終更新
Dockerコンテナの実行時にKeeperボルトからシークレットを動的に取得します
Keeper Secrets Manager機能の完全なリストについては、概要をご参照ください。
このページでは、Secrets ManagerとDockerランタイムとの連携について説明します。 この連携を利用するための必要条件は以下のとおりです。
Keeper Secrets Managerへのアクセス(詳細は、クイックスタートガイドをご参照ください)
KeeperアカウントのSecrets Managerアドオンの有効化
Secrets Manager強制ポリシーが有効化されたロールを割り当てられたメンバーシップ
シークレットを共有するKeeper Secrets Managerアプリケーション
アプリケーションの作成手順については、クイックスタートガイドをご参照ください
Keeper Secrets Manager(KSM)CLIツール
KSM CLIの設定手順については、こちらをご参照ください
Keeper Secrets ManagerはDockerランタイムと連携しているため、コンテナの実行時にボルトからシークレットを動的に取得できます。
ksm
コマンドを使用して、コンテナの起動時に環境変数を設定するため、環境変数をデプロイメントスクリプトにハードコーディングする必要はありません。この実装の実際の例を以下に示します。
公式のMySQL dockerを使用すると、ユーザーはMySQL rootパスワードを設定し、環境変数を使用してネットワークアクセス可能なユーザーを作成できます。MySQLインスタンスは、コンテナの実行時にプロビジョニングされます。
公式のMySQL Dockerfileは以下のとおりです。
標準実装では、ENTRYPOINTはコンテナのプロビジョニングを実行し、MYSQLを設定するために渡される環境変数を使用します。参照される環境変数は以下のとおりです。
MYSQL_ROOT_PASSWORD
MYSQL_USER
MYSQL_PASSWORD
MYSQL_DATABASE
以下の手順では、Keeperボルトに格納されたシークレットを使用してMySQLデータベースを初期化する方法を示します。
手順 1: シークレットを格納する2つのボルトの記録を作成します
Secrets Managerアプリケーションによって管理される2つの記録をボルトに作成します。一方の記録にはrootパスワードが含まれます。もう一方の記録には、通常のユーザー、パスワード、およびデータベースの値が含まれます。
ボルトの記録に表示されるUID記録を必ずコピーしてください。これらは、以下の手順3でボルトのシークレットを参照するときに使用します。
手順 2: デフォルトのMySQL dockerfileをベースとしたdockerfileを作成します
Keeper Secrets Manager CLI (ksm
) をインストールし、ksm exec
でENTRYPOINTをラップするdockerfileを作成します
以下のdockerfileでは、Keeper表記法を使用して4つの環境変数が置き換えられています。また、シークレットが格納されているボルトを示すSecrets Managerプロファイルも渡しています。
手順 3: dockerビルドを実行するシェルスクリプトを作成
docker buildを実行するには、以下のスクリプトでSecrets Managerのデバイス設定と、シークレットを含むボルトのrootユーザーのUID記録とネットワークユーザーのUID記録を渡します。
KSM CLI Dockerには、GLIBC (ほとんどのLinuxディストリビューション) とMUSL (Alpine Linux) の両方のCLIバイナリへのボリュームマウントが含まれています。ボリュームは、/cli
です。このディレクトリは、docker-composeのvolumes_from
またはコマンドラインdockerの-v
を使用して、別のコンテナにマウントできます。ksmの実行可能ファイルは、Linuxディストリビューションが使用しているCライブラリのバージョン別のディレクトリにあります。
/cli/glibc/ksm
- Ubuntu、Debian、Fedora、CentOSなどの標準GLIBCディストリビューションの場合。
/cli/musl/ksm
- Alpine Linuxの場合。
たとえば、CLIバイナリにアクセスする方法を示す簡単なフレームワークを以下に示します。
init
サービスは、CLI dockerをロードします。コンテナが起動し、CLIのスプラッシュ画面が表示されてから終了します。コンテナが停止しても、/cli
ボリュームには他のコンテナから引き続きアクセスできます。
main
サービスは、volumes_from
を使用して、CLI dockerのボリュームをディレクトリ/cli
にマウントします。command
でオーバーライドして、KSM CLIのGLIBCバージョンを実行します。command
は、CLIのexec
機能を使用しています。これにより、Keeper表記法を使用する環境変数がシークレット値に置き換えられます。CLIのexec
コマンドは、printenv
アプリケーションを実行しています。これにより、Keeper表記法に設定され、exec
コマンドによって値がシークレットに置き換えられた環境変数MY_LOGINが表示されます。
上記の例と同様に、カスタムDockerイメージを作成せずに、KSM CLI dockerを使用して、別のベンダーのDockerイメージのエントリポイントとコマンドをオーバーライドできます。
この例では、最初の2つの例を組み合わせます。
この例では、DockerイメージがDocker Hubリポジトリから切り離されて、イメージのDockerfileがGitHubに格納されていることを前提としています。
最初の手順は、ベンダーのDockerイメージがどのオペレーティングシステムのディストリビューションに基づいて作成されているかを判定することです。通常はタグ名で判定できます。たとえば、名前のイメージタグ名に「alpine」が含まれている場合は、Alpine Linuxディストリビューションであることがわかります。
イメージタグ名にディストリビューションが示されていない場合は、そのイメージのDocker Hubウェブページで、「サポートされているタグ (Supported tags)」セクションのタグ名をクリックします。すると、Dockerfileの内容が表示されます。FROMステートメントは、ベンダーがイメージ作成のベースにしたディストリビューションを示します。FROMステートメントで判明しない場合は、継承したFROMイメージのDockerfileをご確認ください。
MySQL 8.0.31は、タグ名にオペレーティングシステムのディストリビューションを示しません。MySQL Docker Hubページでは、8.0.31タグがGitHubリポジトリにリンクしています。このDockerfileから、ディストリビューションがOracle Linuxであることがわかります。
ディストリビューションをチェックする目的は、どのバージョンのlibcライブラリが使用されているかを確認することです。ほとんどのディストリビューションはGLIBCを使用していますが、一部 (主にAlpine Linux) はMUSLを使用しています。これは、KSM CLI Dockerイメージから正しいバイナリを選択するために必要です。間違ったバイナリを選択すると、exec /cli/musl/ksm: no such file or directory
またはexec /cli/glibc/ksm: no such file or directory
のようなエラーが表示されます。この例では、Oracle LinuxはGLIBCディストリビューションです。
次の手順では、ベンダーのDockerイメージのENTRYPOINTとCMDを指定します。Dockerfileには、ENTRYPOINTとCMDの両方、またはいずれか一方が記載されます。
このMySQL Dockerfileでは、ENTRYPOINTは["docker-entrypoint.sh"]
で、CMDは["mysqld"]
です。つまり、ENTRYPOINTはCMDの先頭に追加されるため、コンテナの起動時にdocker-entrypoint.sh mysqld
が実行されます。
docker-compose.yml
docker-composeは2つのサービスを使用します。
initサービスは、keeper/keeper-secrets-manager-cli
Dockerイメージボリュームをロードします。このイメージは起動して終了しますが、終了後もボリュームには引き続きアクセスできます。
mainサービスは、initサービスの後に実行されます。これは、docker-composeのdepends_on
ディレクティブを使用して実行します。このサービスには、KSM CLI exec
コマンドによって置き換えられる、表記法を使用した環境変数が含まれており、KSM CLIに必要なBase64でエンコードされた設定も含まれています。MYSQL_環境変数は、データベースをプロビジョニングするためにMySQL Dockerイメージによって使用されます。
また、mainサービスはvolumes_from
を使用して、initサービスからボリュームをマウントします。KSM CLI Dockerイメージには、ボリュームをエクスポートして、mainサービスコンテナにマウントされる場所が定義されています。バイナリは/cli
(libcバージョンとksm
バイナリ名が続きます)にマウントされます。
MySQLイメージはOracleディストリビューション (GLIBCディストリビューション) を使用するため、mainサービスは/cli/glibc/ksm
バイナリを使用します。
mainサービスは、MySQLイメージのENTRYPOINTとCMDをオーバーライドします。これは、entrypointとcommandを使用して実行します。エントリポイントは、KSM CLIのexec
コマンドを使用して、元のENTRYPOINT docker-entrypoint.sh
を実行します。commandは同じですが、docker-compose.yml
で設定する必要があります。設定しないと、サービスは単に終了します。
使用しているDockerイメージによっては、ENTRYPOINTとCMDのいずれか一方、またはその両方のオーバーライドが必要になる場合があります。
サービスが起動されると、initサービスが最初に実行され、コード0で終了します。これは、正常終了したことを意味します。その後、mainサービスが起動し、KSM CLIのexec
コマンドを実行してから、mysqld
によってdocker-entrypoint.sh
が実行されます。この時点で、環境変数はシークレットに置き換えられ、MySQLがプロビジョニングされ、mysqld
が動作しています。
このページに貢献できる素晴らしい例をお持ちであれば、Slackでメッセージを送信するか、またはメールでお知らせくださいsm@keepersecurity.com。