Dockerランタイム

Docker実行時にKeeper Secrets Managerからシークレットを取得

機能

  • Dockerコンテナの実行時にKeeperボルトからシークレットを動的に取得します

Keeper Secrets Manager機能の完全なリストについては、概要をご参照ください。

前提条件

このページでは、Secrets ManagerとDockerランタイムとの連携について説明します。 この連携を利用するための必要条件は以下のとおりです。

概説

Keeper Secrets ManagerはDockerランタイムと連携しているため、コンテナの実行時にボルトからシークレットを動的に取得できます。

ksmコマンドを使用して、コンテナの起動時に環境変数を設定するため、環境変数をデプロイメントスクリプトにハードコーディングする必要はありません。この実装の実際の例を以下に示します。

例:MySQLネットワークユーザーアカウントのプロビジョニング

公式の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パスワードが含まれます。もう一方の記録には、通常のユーザー、パスワード、およびデータベースの値が含まれます。

MySQL DBのroot
MySQL DBのユーザー

ボルトの記録に表示されるUID記録を必ずコピーしてください。これらは、以下の手順3でボルトのシークレットを参照するときに使用します。

rootの記録のUID記録を取得
ユーザーの記録のUID記録を取得

手順 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イメージの使用

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が表示されます。

例: KSM CLI Dockerと他のベンダーのDockerイメージの併用

上記の例と同様に、カスタム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イメージのENTRYPOINTCMDを指定します。Dockerfileには、ENTRYPOINTCMDの両方、またはいずれか一方が記載されます。

このMySQL Dockerfileでは、ENTRYPOINT["docker-entrypoint.sh"]で、CMD["mysqld"]です。つまり、ENTRYPOINTCMDの先頭に追加されるため、コンテナの起動時に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サービスコンテナにマウントされる場所が定義されています。バイナリは/clilibcバージョンとksmバイナリ名が続きます)にマウントされます。

MySQLイメージはOracleディストリビューション (GLIBCディストリビューション) を使用するため、mainサービスは/cli/glibc/ksmバイナリを使用します。

mainサービスは、MySQLイメージのENTRYPOINTCMDをオーバーライドします。これは、entrypointcommandを使用して実行します。エントリポイントは、KSM CLIのexecコマンドを使用して、元のENTRYPOINT docker-entrypoint.shを実行します。commandは同じですが、docker-compose.ymlで設定する必要があります。設定しないと、サービスは単に終了します。

使用しているDockerイメージによっては、ENTRYPOINTCMDのいずれか一方、またはその両方のオーバーライドが必要になる場合があります。

結果

サービスが起動されると、initサービスが最初に実行され、コード0で終了します。これは、正常終了したことを意味します。その後、mainサービスが起動し、KSM CLIのexecコマンドを実行してから、mysqldによってdocker-entrypoint.shが実行されます。この時点で、環境変数はシークレットに置き換えられ、MySQLがプロビジョニングされ、mysqldが動作しています。

Dockerランタイムの例に貢献

このページに貢献できる素晴らしい例をお持ちであれば、Slackでメッセージを送信するか、またはメールでお知らせください[email protected]

最終更新