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)