AWS

JAWS DAYS 2018 レポート

JAWS DAYS 2018

内容の正当性は保証できません。こういう雰囲気でした。

スライドとか公開されたら更新します。

概要

JAWS DAYS 2018レポート
日時: 2018年3月10日10時から
URL: https://jawsdays2018.jaws-ug.jp/

以下敬称略

コンテナでウェイウェイ (仮)

by @keisuke69 西谷圭介

なぜコンテナなのか?

  • パッケージング
  • 配布
  • イミュータブルインフラストラクチャー

ユースケース

  • マイクロサービスアーキテクチャ
  • 非同期ジョブ実行(バッチコンピューティング)
    • 柔軟にスケール
  • 継続的インテグレーション、デプロイ
    • 開発テスト本番まで一貫したイメージを利用

Amazon Container Service

  • レジストリ
    • Amazon ECR
  • コントロールプレーン
    • Amazon ECS
      • 年間アクティブユーザ+450%
      • 毎週数百万ものインスタンスで数億コンテナが起動
      • 2015年のGA以来50以上の機能がリリース
      • Task: コンテナ群の実行単位
      • Service: Taskの数を指定
      • IAM Role: Taskごとに割当可能
      • TaskごとにENIを自動割当
      • Task内はlocalhostを共有
    • AWS Fargate
      • ECSと一緒に使う
      • ECSのTaskでコンテナイメージを指定して実行
      • インスタンス管理不要
      • タスクに割り当てたリソース分の料金が掛かる
      • CPUとメモリを秒単位で課金
      • Fargateで難しいもの
        • WindowsContainer
        • GPU
        • docker execのようなインタラクティブなデバッグ
        • SpotやRIベースの価格モデルの適用
        • Taskレベルのメトリクス
      • Lambdaの方がいい場合
        • イベントドリブン
        • ミリ秒単位のコンピュート
        • ランタイムの管理をしたくない
        • 分散バッチコンピューティング
      • EKS
      • Masterの管理運用をEKSでサポート (マネージド、Multi-AZ)
      • EC2の管理は必要になるが、Fargateでのサポートも予定

Our ECS Journey

by @calvinfo Calvin French-Owen

Segmentで様々なAPIを一つにまとめるサービスを運用している。
ECSは2015年から運用

ECSは次の理由から使っている。

  • 効率がいい
  • 複数の環境間での実行
  • コードにできる

dev-opsはコンテナに有利

どのAWSのサービスを使うか?

  • Lambda: 関数が必要でgolang, node, java, python, c#
  • Fargate 上記以外でコンテナがどう実行されるか制御しなくていい
  • EKS: 上記以外でKubernetesか?
  • ECS: 上記以外

ECSはノードにエージェントが入り、ECS APIから制御される。

Terraformで環境構築を行っている。
https://github.com/segmentio/stack

本番ではCPUとメモリでスケールさせている。
CIでイメージをビルドしている。
git push -> docker build (circle ci) -> (ECR) -> ECS <- task udpate (Slack)

CloudWatchとDatadog/Statsdを使ってモニタリングしている。
1log group per service

「AWS Technical Evangelists Special talk session -スペシャルトークセッション AWSとユーザーコミュニティが生み出すNo borderな未来-」

登壇者のトークっセッション

Jeff Barr / Randall Hunt / Julio Faerman / Channy Yun / 亀田 治伸

Q. 新サービスや新機能が多い。どうキャッチアップすればよいか?
A. すべてキャッチアップは不可能。自分の好きなものから始めるといい。
A. 好奇心を持つ。土台を築く

Q. AWS認定のために何をどう勉強すればいいか?
A. アソシエイトの試験は簡単。AWS使ったことなくても合格できる。一方でプロフェッショナルは難しい。ネットワークはアソシエイトでも特に難しい。時間は掛かるがドキュメントを読むといい。アーキテクチャを学ぶのにいいことは使用事例を見ること。
A. 本を読んで定義を固める

Q. プログラミング言語はどうすればいいか?
A. Python, JavaScript。ただし問題解決のためのツールでしかないので必要に応じて。

Q. 5年後、10年後もプロフェッショナルでいるためには?
A. 特定のサービスやプロダクトにこだわりすぎると、新しいサービスとかに目を向けられなくなってしまう (初期のサービスは成熟したものに比べて完成度が低い)。
A. 今起きていることを理解する。何が流行るかわからないから。

サービスをスケールさせるために〜AWSとAWS利用者の技術

by 荒木 靖宏

サービスをスケールさせるためにユーザがやることは?

  • 新機能追加
    • AWS Media Services: メディア配信に必要な物すべて提供
  • 面倒のアウトソース
    • Inter-Region VPC Peering: インターネットに出ないリージョン間のVPC Perring
    • Direct Connect Gateway: Direct Connectを使う時別のリージョンから使える
  • 地理的な拡大
    • DynamoDB Global Tables
    • 大阪ローカルリージョン
    • Ningxia: 中国に二つ目のリージョン
    • Paris: ヨーロッパに4つ目のリージョン
    • 冗長化した100GbEのネットワーク
    • トランジットセンター: 東京に2箇所、大阪に1箇所ある。サーバ等はなく、DX、Tier1 ISP等の接続を担う
    • カスタムのルーター / SDN を導入
    • C5インスタンスはカスタムのKVMを使っていてハードウェアのパフォーマンスをフルに引き出せる
    • Everything fails, all the time. Werner Vogels
    • セキュリティ、運用、開発も、攻撃や運用ミスを防ぐのは難しい。自動で検知対応できないといけない
    • 障害を前提に
      • AutoScaling
        • 可用性も良くなる   * Automatic Feedback Control
        • アクセスログを継続的に解析、集計し、不審な挙動のIPアドレスをブロック対象として動的にWAFの設定を変更する
    • 問題が発生しても修正、テスト、デプロイが即座に可能なプロセスを整備する
    • テストケースの生成を自動化する
    • Game-day Testing
      • 実際の本番環境で、異常事態の対応を訓練
      • トラブルが起きたときしかトラブルシュートしなくて、いざトラブルが起きたときにスムーズに対応できるか?
        • 設定をデタラメに設定したりイーサネットケーブルを抜いたり
    • Error Injection
      • Netflix Simian Army: Mon-Thuesに障害を常時注入。四半期に一度はリージョンを飛ばす
        • Chaos Monkey
        • Chaos Gorilla
        • Chaos Kong

クラウド自体を進化させるのは事業者の役割
木曽コンポーネントの提供は事業者だけができること
AWS製のマネージドサービスも登場している

クラウドを知り、使い方を深めるのはサービス提供事業者
クラウドの限界を知り、それを前提として設計するのが現実

コンテナを守る技術 2018

by @pottava 中丸 良

オフィシャルのコンテナイメージでも脆弱性は普通にある。

安心のための3つの問いかけ

  1. アプリケーションの詳細な挙動を把握できているか?
  2. セキュアな構成、設計ができているか?
  3. セキュリティポリシーをテストする仕組みがあるか?

アプリケーションの詳細な挙動を把握できているか?

コンテナ以前はホストごとの管理が基本: 複数のサービスが同居の場合どうしても穴が大きくなる
ECSはTaskごとにENIがあるから、TaskそれぞれにセキュリティグループとIAMRoleが適用できる。

セキュアな構成、設計ができているか?

ホストまで管理したいが、コントロールプレーンは管理したくない場合はECS / Batchを使う
ECSのaws vpcモードを使う。

アプリケーションだけでいいならFargateを使う。
ECSタスク定義はDockerのセキュリティオプションも数多く使える。

セキュリティポリシーをテストする仕組みがあるか?

  • 都度スキャン
    • コードベースが変わるたび
  • 定期スキャン (サービス横断)
    • 新しく発見された脆弱性などの影響
  • 実行時スキャン(アプリ実行中に攻撃やポリシー違反がないかをモニタ)
    • コンテナだけではなくホストも

コンテナの守り方

コンポーネント

守りやすい環境を整える
セグメントを分け、攻撃対象・艦戦範囲を限定にする

  • クラスタを分割
    • 役割、顧客、ビジネス、環境別
  • ネットワークを分割
    • ホストとコンテナ

スケールアップよりスケールアウト: 被害を最小限に全滅を避ける
インスタンスハードニング、堅牢化: ホワイトリストの導入 (NIST 800-167(), パッチ管理等
セキュリティ製品のインストール: AWS Inspectorとか

docker-bench-securityイメージ: Docker用ホストを本番で動かす場合のベストプラクティス等の確認
これをLambdaでスケジュールしてRun Commandで実行。CloudWatch Logsに出力してアラートを出す。
これはAWS公式のおすすめ。

ECSエージェントおすすめ設定
ECS_DISABLE_PRIVILEGED=true
SecuirtyOptionを使いたい時
ECS_SELINUX_CAPABLE=true
ECS_APPARMOR_CAPABLE=true

リソース制約

  • ulimits (--ulimit)で上限を決める
  • memoryを指定してそれを超えたらコンテナを落とす

READ ONLY

  • マウントしたディレクトリ以外を書き込み禁止に
    • readonlyRootFilesystem
  • マウントしたディレクトリを書き込み禁止に
    • mountPoints.readOnly
    • volumesFrom.readOnly
  • AppArmorでパスベースのアクセス制御
    • dockerSecurityOptions

ルートユーザは使わない

  • 適切なユーザで作成
  • システムコールに正しく権限チェックが掛かるように

実行ファイルの管理

  • 利用するバイナリだけをイメージに入れる。
  • 静的なリンクにしておく (ldd/straceで確認)
  • suid, sgidがセットされたバイナリは無効にする

通信を制限する

  • どこと通信するのかをまず把握
  • links, networkMode, disableNetwork

システムコールを制限する

  • seccompを使う(ただしECSでは使えない)

Build
CI
コードの静的解析、イメージの解析・ポリシーテスト

  • Static Application Security Testingツールを利用
  • dockerイメージのポリシーを定義 & チェック
  • GoogleCloudPlatform/container-structure-test
    • コンテナのあるべき姿をポリシーとして定義、テスト可能
    • ファイル、パーミッション等のテストができる
    • ENTRYPOINTやCMD、環境変数、ポートなどのメタデータが正しいか確認できる
  • 自動化
    • Jenkins等でビルド、解析等をする。
      • TwistLock等を使う

定期的な解析

  • 自前では難しい
  • おすすめはaqua (商用ツール)
    • ECRのイメージ解析
      • 脆弱性チェック
      • 設定不備、秘密情報の混入確認
    • 実行時防御
      • 攻撃検知、ポリシー違反のチェック
      • ポリシーの自動生成
    • IAM, KMS、秘密情報管理
  • NeuVector
    • 実行時脆弱性スキャン & ポリシー違反チェック

秘密情報の扱い

  • 環境変数使っても色んなところから見えたり消せなかったりする
  • SSM Parameter Store & KMS & IAM Roleを使ってパスワード情報を保存しよう

AWS Japan SA Lightnings!

by 浅野佑貴 / 藤原吉規 / 福井厚 / 江川大地 / 塚越啓介 / 桐山隼人 / 畑史彦 / 大村幸敬

Save on Cost

by 浅野佑貴

RI購入 / コンパーチブル変換デモ

AWS Lambda@Edgeでできること!

by 藤原吉規

Lambda@Edgeでの画像リサイズデモ

  • リサイズ済み画像がなければ生成 & 保存する

Serverless ASP.NET Core 2.0 Applications

by 福井厚

デモ

  • LambdaファンクションでASP.NET Core Web APIアプリケーションを動かす

Amazon Aurora Storage クイズ

by 江川大地

インスタンスとストレージでコンポーネントが分かれている。

Happy Amplify

by 塚越啓介

  • AWS Amplifyで認証を使う。
  • JavaScriptのライブラリ
  • ライブコーディング

みんなクラウドセキュリティ

by 桐山隼人

  • AWS GuardDuty
    • 攻撃の検知
    • ホワイトリスト・ブラックリストIPアドレスを設定できる
    • さまざまなセキュリティ企業と連携している

Amazon Polly, AWS CodeBuild, AWS CodeCommitで自動プレゼンと/を自動ビルド

by 畑史彦

remark.js + Amazon Polly + CodeCommit + CodeBuildで、スピーチ音声を自動生成し、それを発表するデモ。

いまCloudFormationで知るべき10のこと

by 大村幸敬

  • YAML使おう。見やすい
  • JSON/YML変換にcfn-flipを使おう (オフィシャル)
  • Cross Stack Reference: 更新頻度と役割分担によってスタックを分ける (ネットワーク、セキュリティグループ…等)
  • Systems Manager Parameter Store: 変数を入れておく場所として使う。システムのパラメータ (ユーザ名とか) を集中管理
  • Drift Detection: テンプレートと実環境の差分(Comming soon)