【和訳】Docker Secrets Managementの紹介 #docker

本稿は
INTRODUCING DOCKER SECRETS MANAGEMENT(2017/2/9) の和訳記事です。

コンテナセキュリティ、Dockerセキュリティ、Secret Mnagement
コンテナは我々のアプリとインフラストラクチャの見方を変えます。 コンテナの中のコードが大きくても小さくても、コンテナアーキテクチャはハードウェアに対するそのコードの振る舞いを変化させます。すなわち、根本的にコードはインフラストラクチャから抽象化されているのです。 Docker社は、コンテナセキュリティは3つの主要な項目で構成されており、それらによってアプリが本質的に安全になると信じています。

安全なアプリを構築するための重要な要素は、他のアプリやシステムと安全に通信する方法を持つことです。そのためは、通常はアプリケーションの機密データとして参照される、証明書・トークン・パスワード・その他形式の機密データ情報が必要となります。 我々はDocker Secretsを紹介できることをうれしく思います。Docker Secretsは、コンテナセキュリティの一部であるTrusted Deliveryを強化するコンテナネイティブソリューションです。これはコンテナプラットフォームに機密データの配送方式を直接統合することによってセキュリティを強化します。
コンテナによって、いまやアプリケーションは複数の環境において、動的で持ち運び可能なものとなりました。 コンテナの登場によって、静的な環境向けに設計されている既存の多くの機密データ配送方式を不適切なものになってしまいました。 残念なことに、これはアプリケーションの機密データの誤った管理方法の増加につながってしまいました。GitHubのようなバージョンコントロールシステムにその機密データを組み込んだり、思いつきの一点物のシステムに組み込んだりといった安全でない自己流のソリューションが散見されます。

Docker Secrets Managementの紹介

我々は基本的に、機密データにアクセスするための標準的なインターフェースがあればアプリがより安全になると信じています。 また、良いソリューションは、セキュリティに対するベストプラクティスに従う必要があります。例えば、機密データの転送中の暗号化、および機密データの保存中の暗号化、最終アプリケーションによる処理時の意図しない情報漏洩の防止、そして、最小限の特権という仕組みを守ってアプリケーションが必要最低限の機密データにアクセスする仕組み、などです。
SecretsをDockerオーケストレーションに統合することにより、我々はこれらの原則に従って機密データ管理問題へのソリューションを提供できるようになりました。
次の図は、新しいタイプのオブジェクト「シークレット・オブジェクト」を安全にコンテナに配送するために、Docker Swarm Modeアーキテクチャがどう適用されるのかを表しています。

Dockerでいう機密データとは、パスワード、SSHプライベートキー、TLS証明書、その他、配慮が必要なデータです。 Swarmに対して機密データを追加する場合（docker secret createを実行します）、新しいSwarmをブートストラップする際に自動生成する内蔵の認証局を使用して、Dockerはその機密データを互いに認証されたTLS接続を経由して、Swarm Managerに送信します。

$ echo "This is a secret" | docker secret create my_secret_data -

一旦機密データがマネージャノードに達すると、暗号化せずにディスクに書き込まれることがないよう、256ビットキーを使用したNACLのSalsa20Poly1305を使う内蔵Raftストアに保存します。内蔵ストアへの書き込みによって、機密データは、その他のSwarmの管理データと同様の高い可用性が保証されます。
Swarm Managerが起動すると、機密データを含む暗号化されたRaftのログは、ノード固有のデータ暗号キーを使って復号されます。 このキーおよび他のクラスタと通信するのに使われるノード毎のTLS証明書は、アンロックキーというクラスタ全体の暗号化キーで暗号化することができます。アンロックキーもRaftを用いてクラスタ内に伝搬させていき、マネージャの起動に必要となります。
新しく作成した、あるいは起動したサービスに機密データにアクセスする事を許可したら、1つのマネージャノード（マネージャだけが保存した全ての機密データにアクセスできます）は既に確立しているTLS接続をその特定のサービスが走るノード専用に使用して機密データを送ります。 これは、ノードが自身で機密データを要求できないことを意味します。機密データが必要となるサービスに対してのみ、すなわち、マネージャからアクセスを許可されたときだけ、機密データにアクセスできます。

$ docker service create --name="redis" --secret="my_secret_data" redis:alpine

暗号化していない機密データは、/run/secrets/ にあるインメモリ・ファイルシステムのコンテナにマウントされます。
$ docker exec $(docker ps --filter name=redis -q) ls -l /run/secrets
total 4
-r--r--r-- 1 root root 17 Dec 13 22:48 my_secret_data

もしサービスを削除した場合、またはどこか別のところで再スケジュールした場合、マネージャはただちにすべてのノードに対して、機密データデータにアクセスする必要がなくなったこと、メモリから削除すること、ノードはアプリケーションの機密データに対してアクセスできなくなったことを通知します。
$ docker service update --secret-rm="my_secret_data" redis

$ docker exec -it $(docker ps --filter name=redis -q) cat /run/secrets/my_secret_data

cat: can't open '/run/secrets/my_secret_data': No such file or directory

機密データの生成や管理についてのさらなる情報、事例についてはDockerの機密に関する資料を参照下さい。この機能を実現するために、Docker社、コアエンジニアリングチーム、そしてLaurens Van Houtven (https://www.lvh.io/）にご協力いただきました。

Dockerによる安全なアプリケーション
Docker secretsは開発者およびIT運用チームがより安全なアプリを構築し、実行するために設計されました。 Docker secretsは、機密性の高いデータを安全に保ち、特定のコンテナが運用上やむなく機密データへのアクセスが必要な場合のみに使用する、コンテナ第一のアーキテクチャです。 Docker Composeでアプリと機密データを定義するところから、IT管理者がDocker Datacenterに直接Composeファイルをデプロイするまで、サービス、機密データ、ネットワークおよびボリュームはアプリケーションと共に安全に保たれます。
さらに学ぶためには：
• Docker Datacenter 1.13 における機密データ、セキュリティスキャニング、コンテンツキャッシュその他
• Dockerをダウンロードして 今日始めてみましょう。
• Docker DatacenterでSecretを試す。
• 資料を読む
• webinarに参加する