[レポート] AWS User Group Meetup in Berlin (2019.09.17.) 〜 S3 セキュリティとK8s × Spotinst

Ito ma

2019.09.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Guten Tag、ベルリンより伊藤です。

昨日、Berlin の AWS User Group Meetup に参加してきましたのでブログを書きます。

AWS からの連絡

イベント情報

2019年10月17日(木)にオンラインカンファレンス、 AWS Innovate - Machine Learning と AI エディションがあります！

会場提供

今回のホスト Architrave GmbH は、不動産に関わる膨大な資料を電子化・管理し、不動産所有者やサービス提供者へ利用可能にすることで、複雑なデータに価値を与える不動産テックのサービスを提供しています。

オフィスドッグも歓迎とのことで、今回は足元でボールをくわえて歩き回るわんちゃんに癒されながらセッションを拝聴でき、幸せな空間でした。

トークセッション: S3ベースのWebアプリをセキュアでプライバシー準拠させる

概要

スピーカーは、Guy Lifshitz (Mostly Secure)。

Abstract: The presentation will discuss design pattern and implementational strategies for making S3-based web applications secure and complaint with the recent privacy regulations. A real-world use case, using cryptographic access control scheme for user-centric data sharing will be presented and analyzed (SWOT).

S3ベースのWebアプリをセキュアにし、最近のプライバシー規制に準拠させるための設計パターンと導入戦略について触れていきます。

導入

クラウドのストレージというのは、本質的に攻撃を受けやすいもの。
直近のCapital Oneのキー漏洩の事例
- WAFの設定に誤りがあったとのことだが、さらに漏洩したWAFのIAMロールに 不用意にS3へのアクセスが付与 されており、データが抽出・コピーされてしまった
- 関連記事
- S3の欠陥ではなく、誤った設定をしてしまいやすい
GDPRを始めとする、世界的なデータ保護規制
- ユーザは、適切にデータ保護がされていないと思ったら申告することができる
- GDPR発足から約1年、これまでファイリングされたうち半分は申告によるもの
- 実際に申告する人がいる状況であり、遵守は必要

ユースケース: メディカルアシスタントアプリケーション

サービス概要と要件
- 患者とヘルスケア提供者をつなげる
- 短期のセキュリティデータ提供（X-レイの結果など）
- 長期のセキュアなデータ蓄積（EMR: 医療レコード）
- その他履歴がS3バックエンドで
- 2FA 認証
- 各種情報は HIIPAA、GDPR に準拠させ、AWS BAA を締結
S3 の要件
- 転送・保存で保護
- 認証ユーザのみにアクセス付与
- スケーラブル
- 全く外部にさらされることのないように
- 制限スコープを減らす

S3のネイティブツール

データアクセスコントロール
- IAMポリシーとバケットポリシー
- ACL (非常に複雑で管理が難しいので非推奨)
クエリ文字列認証/URLベース（短期データ、一時アクセス用）
- S3 署名付き URL (get/put)
- CloudFront 署名付き URL（CFエッジを使用するのでgetのみ、ただしIPなど様々な制限ができる）
- CF 署名付き Cookie (複数のオブジェクトアクセス) （クッキー生成が必要なので、サーバ側でやるより難しいかも）
暗号化オプション（SSE-S3, SSE-KMS, SSE-C, クライアント側）
- SSE-S3 は、CPU、ストレージなども全部無料でパフォーマンスにもほぼ影響しないので導入すべき
S3 API によるSSLアクセス
S3 CloudTrail イベント
VPC S3 エンドポイント
ハウスキーピング: バージョニング、ライフサイクルポリシー、MFAデリート、オブジェクトロック、インベントリー、Configルール、AWS Macie

導入オプションと比較

導入オプション1
- アプリレベルのユーザおよびアクセス管理
- オプションで外部IDPによるCognito統合
- SSE-Cによるサーバサイド暗号化
- バケットポリシー特定のアプリケーションロールにのみ
- データアクセスの一時URL（X-rayなど）
- SSL強化
- S3 CloudTrailイベントを異なるバケットへ
- CloudWatchロググループにCloudTrailログストリームを作成
- 特定のアクティビティを対象に、S3イベント名に基づいたCloudWatchメトリクスフィルタを設定
導入オプション2
- アプリレベルのユーザ管理
- IDベースキー（PKI）を使用したクライアントサイド暗号化
- SSL強化
- S3 CloudTrailイベントを異なるバケットへ
- CloudWatchロググループにCloudTrailログストリームを作成
- 特定のアクティビティを対象に、S3イベント名に基づいたCloudWatchメトリクスフィルタを設定
導入オプション3
- アプリレベルのユーザ管理
- KMS管理キーを使用したクライアントサイド暗号化
- SSL強化
- S3 CloudTrailイベントを異なるバケットへ
- CloudWatchロググループにCloudTrailログストリームを作成
- 特定のアクティビティを対象に、S3イベント名に基づいたCloudWatchメトリクスフィルタを設定

(表左の項目は上から順にオプション1~3)

オプション2は、1に比べたらかなりセキュアだが、お金がかかる（CMK $1/月とはいえ、ユーザごとに鍵を用意していたら費用がかさむ）
オプション1は簡単で導入しやすいが、リソースの管理・監視が必要になる。

Q. 普通なら簡単なオプション1から導入して、そこからオプション3へ改編しようと動くのは難しいのではないか？

私たちの70%もの顧客が簡単なセキュリティからアプリケーション関連のセキュリティへ変更を行っている。それも、DevOpsで簡単に。もちろんオプション3の方がセキュアで高額になるけど、オプション1は管理が必要となるから。

まとめ

S3がダメな製品なのではなく、とても複雑で強力な製品であるがために、間違いが生じやすいもの。

(宣伝となりますが、)現在開発中のHibaはS3の設定、KMSの管理を皆さんの代わりに行います。

トークセッション: サーバーレスコンテナ〜ノードレスのKubernetesと仮想PodのAutoscaling

概要

スピーカーは、Yael Grossman (SpotInst)

Abstract: "Serverless Containers" or "Nodeless Kubernetes", is the future of Containers infrastructure.

Matching and scaling the right infrastructure to ever-changing micro-services deployments is a challenge. In this talk, we will review the evolution of Containers Auto Scaling in Kubernetes both Horizontal and Vertical, discuss the trade-offs, and introduce a new approach to deploy Serverless Containers in a "Nodeless" cluster. No Infrastructure or instances to manage, just Containers that can self-optimized themselves.

変わり続けるマクロサービスのデプロイに正しい基盤を割り当てたりスケールさせたりすることは、一つの挑戦課題でしょう。今回は、Kubernetesにおけるコンテナのオートスケーリングの進化とそのトレードオフ、そしてSpotinstのOceanを活用したサーバーレスコンテナの新しいアプローチを紹介します。

Spotinst とは

4年前に設立
顧客は中小から大企業まで、Zalando、Duolingoなども
各クラウドのスポットインスタンスを活用し、60-80%のコスト削減
- Azure: Low Priority VMs
- GCP: Preemptible VMs
- AWS: スポットインスタンス

導入

Kubernetes は下記のような構成（参考: PodとNodeについて）

Kubernetes のスケーリング

インフラの観点
- コンテナはvCPUとメモリによる駆動
- Podがリソース要件に応じてスケジュールされる
- Podリソースリクエスト: システムにより保証され、ノードにPodを割り当てるスケジューラにより使用されるリソース量
- Podリソース制限: Podが使用する可能性のある最大リソース量
- 誤った要件はスケジュールの失敗につながる
- yamlファイルで AZ要件、ポート制限、など下記のように指定

特定のメトリクス（CPU、メモリなど）が特定の閾値に達したらスケーリング
- これではちょうど満たしている条件で無駄にスケールしてしまう可能性が
- 条件に応じてスケーリングしていくと各ワーカーノードでリソースの空きができて無駄に

コンテナの観点
- リソース要件はスケジューラとAutoscalerで使用され、正確に特定することが大事
- 小さすぎるPodは、CPU枯渇、Out of memory エラー、ワークロードの排除、パフォーマンスやクラスター安定性を下げる
- 大きすぎるPodは、リソースの待機、お金の無駄
- 実際のリソース使用量を監視し、リソースリクエストと比較
- Podが再起動され、スケールアップ/ダウンのためクールダウン

Spotinst Ocean とは

3つの観点でのコンテナワークロードの最適化と自動化を行ってくれる。

料金モデル（スポットインスタンス、オンデマンド、RI）
インスタンスサイズ: Podをインスタンスにマッチさせる
コンテナ使用量: リアルタイム監視

立ち位置としては以下の通り。

ノードレス(といっても、ノードは使用しているわけだが、): ノード自体を管理する必要がない。VMを管理する必要がなく、インスタンスタイプやサイズを選ぶ必要もない。
各デプロイがどれくらいコンピュート、ストレージを使用しているか記録し、各コストを計算する（通常Kubernetesでコストを分割するのは難しいが、チームごとの計算ができる）
EKS AMIも使用可能
Spotinstは外部のSaaSなので、既存のクラスタも使え、移行などは不要
各クラウド（AWS, Azure, GCP）でスポットインスタンスと同様のサービスがあり、いずれもサポート
無料サインアップできる

Q. 複数クラウド間で利用可能なスポットインスタンスを探して、最適な(最安な)ものを使用するということもできるのか？

よくある質問だが、それは未対応。Spotinstの次の課題。

Q. Black Fridayなどスポットインスタンスがない時にはどうなる？

オンデマンドを使用する。ただし、オンデマンドが使用された場合にはSpotinstの課金対象とならない。Spotinstはスポットインスタンスを利用した分にだけ課金される。

Q. Fargate とどう競合する？

Spotinstではスポットインスタンスを利用するので、特に規模が大きくなった場合に圧倒的に安い。