アイキャッチ編集__2_

2019-02-05 NoOps Meetup Tokyo #4

2019/02/05 に開催された NoOps Meetup Tokyo #4 のイベントレポートです。

●イベント概要
NoOps = No "Uncomfortable" Ops

NoOps Japanでは 「システム運用保守の"嬉しくないこと"をなくそう!」 をテーマに、 NoOpsを実現するための技術・設計手法・開発運用保守サイクル・ツールや考え方・事例などを共有していきたいと考えています。

NoOps Meetup Tokyo #4 では、業界の第一人者のみなさんに登壇いただき、それぞれの視点でのNoOpsをお話いただきます。

■オープニング

岡 大勝さん

●テーマ
システム運用の 嬉しくないこと をなくそう

#3のおさらい
・光り輝くTBD(仮)
  サービスの開発チームがどう対応しているか
  Opsチームはない
  全ては"サービスチーム"に存在し、自身の役割に集中

・Serverlessの自動化と自動回復のためのアーキテクチャ
  デモで障害を起こして、自動回復
  自動回復のためのアーキテクチャ
  分散トレーシングの実装

・公募LT

●コミュニティの活動
・知の共有
・ものづくり
  コネクタ、モニタリングのユーティリティなど
  ちょっと足りないをOpen HackでOSS公開

●コミュニティの行動指針
・オープン、フェア、フラット
・共感駆動のSRCAサイクル

●サポーター
敷居高いので、個人スポンサー精度を検討中

●NoOpsのライフサイクル
・Observability
・Configurability
・Resiliency
・Safety
セッションをタグ付けしていきます!

■Cloud Native BuildpackでToil減らしていこう

草間 一人さん

●NoOpsってなに?
・調べてみた -> PaaSじゃん
・参加した -> PaaSじゃん

●x年前
・webサービスやりたい、と言われた
・一人で、WindowsAzure(当時)で立てた
 -> PaaSすごい
 -> CloudFoundryの本家に転職
・PaaSはNoOpsの備えるべき機能を持っている

●Docker/k8s
・Dockerfile書くの大変

●CaaSのワークフロー
・docker build
・docker push
・k8s manifestの作成
・kubectl apply
 -> Dockerfileひどいですね
  -> Toilですね

●PaaSの例:CloudFoundry
・cf push 一発で出来上がり
 ->Buildpackがうまいことやってくれている

●Buildpack
 detect: デプロイされたアプリは何か?
 compile: アプリ向けの準備
 -> コンテナイメージ

・detect
 ・bash
 ・言語ごとのBuildpackを順にチェック
  -> マッチしなかったら exit 1 のチェイン

・compile
 ・bashでも行けるけど、ちょっと複雑だからrubyとかが多い
 ・良い感じにコンテナイメージを作る

・release

●これでdocker image作れば良いんじゃない?
-> Cloud Native Buildpack
・CloudFouundry, Herokuの独自仕様をOCI準拠でまとめた

●デモ
・pack build jacopen/testapp
・docker run ...
 -> Dockerfileなんていらなかったw
・pack build jacopen/testapp --publish
 -> docker push まで動く
・ファイルを変更して pack build jacopen/testapp
 ※良い感じにキャッシュが効くようになった

●pack CLI
・lifecycleのリファレンス実装がそのまま使われている
・対応Platform
 CloudFoundry
 Heroku
 knative

●Cloud Native Buildpackによって持たらされるもの
・Dev
  アプリに注力できる
  言語にかかわらず一貫した操作
・Ops
  継続的に運用できる

●こんなときどうしますか
・ベースイメージに脆弱性があったら?
・パッケージに脆弱性が含まれていたら?
 -> 開発者に任せると、後回しになってしまう
・DockerfileをOpsが管理?
 -> やっぱり生産性は下がる
-> BuildpackをOpsが更新すればOK

●まとめ
・PaaSのノウハウが凝縮されているのがBuildpack
・ライフサイクルまで含めて技術選定

■シンプルに考えよう Zero Trust Network

吉松 龍輝さん

●自己紹介
・Windowsのデバッグ環境を持っていて、エスカレーションしていた
・MSに3回入社していますw

●Zero Trust Networkの定義
・JKDで話が出た
・境界線(Perimeter) vs Zero Trust
 「ネットワークのどこに置くのか」は価値がないと考える

●このセッションのゴール
ネットワーク構成を読むのが苦手でもZero Trust Networkを理解できる

●身近な境界線
・地理的な境界、国籍の境界
 ・パスポート
 ↓
・ネットワーク
 ・ID

●一般的に言われるセキュリティの境界
・韓国
  ↑
  海:密入国の監視
  ↓
・日本

・韓国:パスポートで認証
  ↑
  海:信頼関係によりビザを発行
  ↓
・日本:パスポートで認証

●境界をまたいで起こる問題
・悪意を持った行為が多い
 戦争、禁止薬物の密輸、スパイ活動
 -> これを防ごうというのが一般

●境界の中で起こる問題
・境界内の人だと安心したら騙された
 オレオレ詐欺

・うっかりやらかした
 タバコの不始末

-> 質が違う(起こるまでのプロセスが違う)

●Zero Trustとは 防犯・防災意識を持つ こと
・「誰か見てるぞ」の注意書きとか
・「誰も信用しない」は対策が多すぎてキリがない
 -> なにか起こるかもしれない

●セキュリティパッチの公開から攻撃開始までの時間軸
・一日で攻撃が広がる
 -> 一日以内にパッチを当てる

●NoOps的な対処の例
・PaaS:ベンダーがやってくれる

●セキュリティの各要素の関連性
・ネットワークはセキュリティ要素の一つに過ぎない
・イメージのハーデニング、ポリシーの強制適用などがポイント

■Zero Trust Network アーキテクチャ

伊藤 悠紀夫さん


●中東で崖につくられた城
 ネットワークで言えばFirewall
 -> この城は後々陥落する
  内部から崩壊

●境界セキュリティ
・基本方針
 ・外部アクセスは信頼しない
 ・内部アクセスは信頼する
・主な課題
 ・内部アクセスは性善説前提
 ・最近の攻撃は内部から発生
-> 最近のアプリケーションは様々な場所に展開されている

●Zero Trustアーキテクチャ
・基本方針
 ・ネットワークは常に敵意あり
 ・脅威は内部と外部に、常に存在
 ・誰がどこからアクセスしているかをチェック
・信頼度スコア
 ・複数の信頼指標によるアクセスコントロール
  ・ID/PWで認証 10 point
  ・デバイス認証 10 point
  :
・トラフィックのセキュリティ化
 全トラフィックが認証済み、暗号化
・双方向のSSL通信で保護

●Zero Trust Securityアーキテクチャ
・ユーザやデバイス情報に応じたアクセス - ネットワーク費依存
・全アクセスに対して 認証・認可・暗号化
-> クラウドからオンプレ はどう担保するの?

●MS Azure Active Directory 条件付き VPN
・VPNプロファイル選択
-> MSアカウントでログイン
-> 2要素認証

●サービスメッシュ間のセキュリティは?
Istioの可視化ツール AspenMeshもあるよ

■Elastic Stackでマイクロサービス運用を楽にするには?

大谷 純さん

●内容
・だいぶ宣伝入ってますw
・Kibana、ログだけじゃないし、監視系の話もできないとなぁ
 -> 入門 監視 にインスパイアされましたw
・マイクロサービスで起きた障害の原因究明は
 まるで殺人ミステリーのようだ
 ->マイクロサービスには調査のための監視が必須ですね

●いろいろやってます
・Beats
・Logstash
・Elasticsearch
・Kibana

●監視ポイント
・外形監視
・メトリック
 ・サーバー、アプリケーション
・ログ
・アプリのリリースタイミング
・分散トレーシング

●Elasticだと
・外形監視.死活監視 -> Heartbeat
  Elasticの社内向けにつくったのがスタート

・メトリック -> Metricbeat
  統計情報も取れるよ

・ログ -> Filebeat

・アプリのリリースタイミング
  Kibanaの機能で埋め込める

・分散トレーシング
  APMもあります
  MLでアラート挙げられるけど、有償ですw
  処理内のどこで時間がかかっているか見れます

■前回の様子

■感想

Cloud Native Buildpackすてきですね!早速現場で試してみようと思います!

Zero Trust Networkのお話を伺って、Security Online Day 2018 でのお話の多くが、この考え方をベースにしているんだな、と理解できました。

Elasticのプロダクトはまだまだ活用しきれていないところが多いので、いろいろ試してみようと思います。入門 監視 はまだ読めてないのですが、お話を聞いていると The DevOps Handbook と重なる部分がたくさんありそうで楽しみです!

ありがとうございました!


いつも応援していただいている皆さん支えられています。