5

プライベート VPC で、AWS 上の Mesosphere を使用してテスト クラスターをセットアップしました。公開されている Docker イメージがいくつかありますが、これは簡単にデプロイできます。ただし、ほとんどのサービスはプライベート イメージであり、Docker Hub プライベート プランでホストされており、アクセスするには認証が必要です。

Mesosphere はプライベート レジストリ認証に対応していますが、完全に理想的とは言えない方法でこれを実現しています。.dockercfg ファイルへの HTTPS URI をすべての Mesos/Marathon タスク定義で指定する必要があります。

タイトルが示すように、質問は基本的に次のとおりです。.dockercfg ファイルを AWS 内でホストして、アクセスを Mesos マスターとスレーブのみにできるだけ厳密に制限できるようにするにはどうすればよいですか?

4

4 に答える 4

13

Mesos のドキュメントはこれに関してかなり貧弱なので、この wiki スタイルで回答し、この回答を随時更新します。

うまくいくはずの戦略

S3 でホストする (ネットワークベースのアクセス制限あり)

S3 で .dockercfg ファイルをホストします。セキュリティを強化するには、それを独自のバケットに配置するか、シークレットの保存専用のバケットに配置することを検討する必要があります。これは、Mesos だけが S3 バケットを見ることができるように実際に S3 バケットをロックダウンするように機能するセキュリティ ポリシーを作成する上で、いくつかの興味深い課題を提示しますが、それは実行可能です。

Mesos タスク構成:

{
  ...
  "uris": ["https://s3-eu-west-1.amazonaws.com/my-s3-bucket-name/.dockercfg"]
  ...
}

S3 バケット ポリシー (VPC エンドポイントを使用):

注:このポリシーにより、許可されたプリンシパルは何でも実行できます。これは、運用にはあまりにも雑ですが、テスト クラスターでデバッグするときに役立つはずです。

{
  "Id": "Policy123456",
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "Stmt123456",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::my-s3-bucket",
      "arn:aws:s3:::my-s3-bucket/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-my-mesos-cluster-vpce-id"
      }
    },
    "Principal": "*"
  }]
}

上記の S3 バケット条件にプラグインするための VPCE ID を提供するために、VPCE 構成も必要です。(VPC エンドポイントを使用しない場合は、代わりに VPC ID で一致させることができると思いますか?)

これが機能しているかどうかを確認するには、Mesos UI (DCOS を使用している場合、これはきれいな DCOS UI ではありません) に移動し、アプリの名前のタスクがアクティブ タスク リストまたは完了タスク リストに表示されるかどうかを観察します。

 （まだ）うまくいかない魅力的な戦略

S3 でホストする (署名付き URL を使用)

この S3 バリアントでは、ネットワーク ベースのアクセス制限を使用するのではなく、代わりに .dockercfg ファイルへの署名付き URL を使用します。

Mesos タスク構成は次のようになります。

{
  ...
  "uris": ["https://my-s3-bucket/.dockercfg?AWSAccessKeyId=foo&Expires=bar&Signature=baz"]
  ...
}

残念ながら、上記の S3 署名付き URL 戦略は Mesos-1686により機能しません。Mesos-1686は、ダウンロードされたファイルがクエリ文字列を含むリモート ファイル名を正確に保持し、「.dockercfg?AWSAccessKeyId=foo&Expires=bar&Signature=baz」のようなファイル名になることを観察します。Docker クライアントは、正確に「.dockercfg」という名前が付けられていない限りファイルを認識しないため、認証資格情報を確認できません。

.dockercfg ファイルを各スレーブに直接転送する

.dockercfg を各 Mesos スレーブに SCP することができます。これは簡単な修正ですが、次のことを行います。

  • 事前にすべてのスレーブを知る必要があります
  • 新しいスレーブがクラスタに追加されてもスケーリングしない
  • スレーブへの SSH アクセスが必要です。スレーブは、独自の VPC 内でプロビジョニングされます (したがって、IP アドレスは多くの場合 10.0.[blah] の範囲にあります)。

これは、スレーブ上で実行され、.dockercfg ファイルを適切な場所にプルする Chef などの構成管理ツールで自動化された場合、より実行可能な運用アプローチに変わる可能性があります。

これにより、次のような構成になります。

{
  ...
  "uris": ["file:///home/core/.dockercfg"]
  ...
}

'core' は CoreOS ベースの Mesos スレーブのデフォルト ユーザーであり、.dockercfg は規則により、Docker を使用したい現在のユーザーのホーム ディレクトリにあると予想されます。

更新:これは最も信頼できるアプローチであるはずですが、まだそれを行う方法を見つけていません。Marathon に関する限り、アプリは依然として「展開中」フェーズで永遠にスタックしています。

キーストア サービスを使用する

ユーザー名とパスワードを扱っているので、AWS Key Management Service (または極端な場合は CloudHSM でさえも) は良いアイデアのように思えますが、私の知る限り、Mesos にはこれに対するサポートが組み込まれておらず、個々のキーを処理していません。変数ですが、ファイルです。

 トラブルシューティング

選択したソリューションをセットアップした後、.dockercfg ファイルは正常にプル ダウンされているが、アプリはまだ「展開」フェーズで停止していることに気付く場合があります。これらのことを確認してください...

.dockercfg が Mesos Docker バージョンに適した形式であることを確認してください

ある時点で、「auth」フィールドの形式が変更されました。指定した .dockercfg がこの形式と一致しない場合、docker プルは警告なしで失敗します。クラスタ スレーブの Mesos Docker バージョンが期待する形式は次のとおりです。

{
  "https://index.docker.io/v1/": {
    "auth": [base64 of the username:password],
    "email": "your_docker_registry_user@yourdomain.com"
  }
}

アプリにポート 80 を使用しないでください

Web アプリをデプロイしようとしている場合は、ホスト ポート 80 を使用していないことを確認してください。ドキュメントのどこにも書かれていませんが、Mesos Web サービスにはポート 80 が必要です。それは永遠にハングアップします。洞察力のある読者は、他の理由の中でもとりわけ、これが Mesosphere の「Oinker」Web アプリが代わりにポート 0 という少し変わった選択にバインドする理由であることに気付くでしょう。

于 2015-07-02T09:15:10.430 に答える
2

私が見た多くのプロジェクトでは、あなたが言及した S3 アプローチを使用しています。それでもあなたの指摘は有効であり、コミュニティでそれについて議論する必要があります/議論します.

于 2015-06-29T06:16:42.433 に答える