Embed Size (px)
Citation preview
形式手法で捗る！インフラ構成の設計と検証
チェシャ猫 (@y_taka_23)
JAWS-UG Night in AWS Summit Tokyo 2016 (2016/06/03)
打倒、AWS 構成の秘伝のタレ化
AWS 構成検証、例えば
● awspec○ serverspec の拡張
○ テスト対象となる実際のリソースが必要
● IAM Policy Simulator○ AWS 提供、IAM のアクセス権限を検証
○ 実際には操作・課金せず確認できる
IAM 以外のサービスも
現物を使わずに検証したい
形式手法という手がありますよ？
形式手法って何だ？
● システムを厳密に定義・記述
● 仕様の正しさを数学的に保証
● テストと比較すると
○ テストケースの漏れが生じない
○ 一般的には学習・検証コストが高い
学習・検証コストが高い…
そこで Alloy Analyzer を使おう！
Alloy Analyzer のいいところ
● 形式手法の一種、モデル検査器
○ 関係論理を用いてシステムのモデルを定義
○ モデルが満たすべき条件を記述
○ モデルを自動で全探索して、条件を検査
● 軽量 (lightweight) 形式手法を標榜
● 発見した例を可視化
例えば EC2 インスタンス間の疎通
(https://gist.github.com/y-taka-23/89a98fdb2ba48710a39c)
Alloy による単純なモデリング
sig Instance { priIPs : some IP, secGrps : set SecurityGroup,}
sig SecurityGroup { inRules : set InboundRules, outRules : set OutboundRules,}
Alloy による単純なモデリング
sig Instance { priIPs : some IP, secGrps : set SecurityGroup,}
sig SecurityGroup { inRules : set InboundRules, outRules : set OutboundRules,}
各インスタンスに対して1 個以上の IP アドレスが存在
Alloy による単純なモデリング
sig Instance { priIPs : some IP, secGrps : set SecurityGroup,}
sig SecurityGroup { inRules : set InboundRules, outRules : set OutboundRules,}
各インスタンスに対して0 個以上のセキュリティグループが存在
もう少しモデルを作り込む
● セキュリティグループのルール内容
○ プロトコル (TCP, UDP, ICMP のいずれか)
○ ポート番号 (ICMP ならば存在しない)
○ CIDR と IP アドレスとの包含関係
● インスタンス間で通信可能な条件
○ インスタンスの IP アドレスと
ルールの IP アドレスとの包含関係
条件を満たす例を全探索
発見された具体例たち
発見された具体例たち
発見された具体例たち
もっと実用的な検証を！
● 通信の到達可能性 / 不可能性
● 冗長なセキュリティグループの発見
● 複数 AWS サービス間の連携
● 設定変更時の安全な作業フロー
まとめ
● インフラ設計に形式手法の力を
● Alloy Analyzer でお手軽検証
● アイデア次第で応用いろいろ
