2021年2月

Habitify

今月の習慣も達成。

習慣 合計
本を読む 1,740 分
ブログを書く 1 回

f:id:enokawaa:20210228230613p:plain

https://www.habitify.me/

読書

今月は以下の 1 冊だけ。

約 1 ヶ月かけて『プロフェッショナルSSL/TLS』を読みきった。約 500 ページもあるので達成感がある。理解できていない部分が殆どだが、SSL/TLS に関する知識を体系的に学べた。

第 1 章から第 7 章は SSL/TLS の歴史や暗号技術、証明書についての詳細、ブラウザやプロトコルに対する攻撃の事例などが細かく説明されていた。

第 10 章では HSTS (HTTP Strict Transport Security) などを用いて SSL/TLS におけるセキュリティを大幅に改善する方法が手順も含めて記載されていてためになった。

第 11 章と第 12 章では OpenSSL コマンドを使った鍵や CSR の生成方法、証明書のテスト方法などが詳しく説明されていた。s_client コマンドは業務でも使っていたが、接続先のサービスが対応しているプロトコルや暗号スイートを確認できるオプションは知らなかった。

第 13 章から第 16 章は ApacheJava/TomcatIIS、Nginx での証明書の設定方法が詳しく説明されていた。最近はクラウドが主流になってきて、例えば AWS では CloudFront や ELB で証明書を終端するケースが殆どだが、Web サーバ側で終端するケースももちろん出てくるので学べてよかった。

この本を読み始めてから、Web サイトの証明書の内容を見たり、Chrome の Developer tool で HSTS のレスポンスヘッダあるかなーとか Cookie に Secure 属性ついてるかなーとかを意識して見るようになった。他にも、今日のインターネットが成り立っているのは IETF の方々や、ブラウザを開発する企業/団体、Web サーバを開発する企業/団体、その他ユーザを含む多くの人たちのおかげなんだなぁとしみじみ。感謝。

来月は 2 周目読もうと思う。

育児

月齢 3 ヶ月になった息子氏は表情が豊かになってきた気がする。じゃれると笑ってくれたり、意地悪するとギャン泣きしたり。かわいい。 首は少しずつすわってきているけどまだ自分で支えられていなさそうなので気をつけよう。

予防接種も一緒に行ってきた。かかりつけの小児科は新型コロナの影響で親は一人のみ付き添えることになっていて、1 回目は奥さんが付き添ったので今回はオレの番。 ギャン泣きする息子氏を想像すると「絶対爆笑するんだろうな〜」と高をくくっていたがその逆だったので自分でもビビった。

そこそこ遠くにも行けるようになってきて、最近は家族で IKEA に行った。外出先でのおむつ交換は色々戸惑った。あと授乳室は女性専用しかなかったので少し残念だったな。難しいかもだけど、男性も入れるといいなぁ結局フードコードでミルクをあげた。

初めての育児休業給付金も入った。本当にもらえるのかと疑心暗鬼だったけど、育休に入って 2 ヶ月ちょいで振り込まれた。新型コロナの影響で遅れる可能性もあるのかな〜と思ってたけど無事入金されて安心。色々動いてくださったヘイシャ労務の方に感謝。

そろそろ息子氏が誕生して 100 日。はやくく喋れるようになってくれないかな〜(気が早い)と思いつつ、今の息子は今だけなので、今この時間を大切にしたい。

2021年1月

育休に入って 1 ヶ月が経った。少しだけ自分の時間も作れるようになったので、毎月末に日記ならぬ月記を付けようと思う。

習慣付け

エンジニアとしての基礎を身に付けるために読書を始めた。もともと読書は苦手で、本を読むスピードも遅いし、なにより続かない。辞書的に読む方が多かった。読書に限らず、何かしらの習慣を続けるのが苦手だ。

ということで、毎日 30 分だけ本を読む時間を設けることにした。形から入るタイプなので、Habitify という習慣と目標を管理するアプリケーションを利用した。 Habitify には月額や年額のサブスクリプションプランもあるが、買い切りプランもあって、当時 6,100 円だったので購入した。

www.habitify.me

2021/01/01 から始めてるけど、今のところは継続できている。

f:id:enokawaa:20210131221657p:plain

毎日 15 時くらいに本を読むようにしているのだが、夜になっても読むログをつけないと Habitify に煽られるのでよい。

併せて、今まで読んだ本を残してニヤニヤ振り返られるようにするために Notion で管理するようにした。まだ使いこなせていない感が否めないが、各ページに Markdown でメモも取れるので気に入っている。

www.notion.so

f:id:enokawaa:20210131222957p:plain

f:id:enokawaa:20210131223022p:plain

読書

今月は以下の 2 冊を読んだ。

DNSがよくわかる教科書』は本当によく分かった。いままですごく浅くしか知らなかった DNS の知識を深めることができた。DNS の構成要素であるスタブリゾルバーやフルリゾルバー、権威サーバーの違いから、権威サーバーの移行方法などを分かりやすく紹介している。業務でもよく使っている dig コマンドの細かなオプション(+norec など)についても説明しているのでありがたい。

『マスタリングTCP/IP 入門編(第6版)』は正直まだ理解が追いついていない部分が多い。単にオレの理解が足らないだけだと思うので、もう何周かじっくり読み返したい。

今は『プロフェッショナルSSL/TLS』を読んでいる。これもオレの理解が足らず理解するのに苦しみそうな予感。プロフェッショナル なので入門者向けではなさそう(買う前に調べろよ)。

本の読み進め方

以下のエントリを参考にした。

kentarokuribayashi.com

blog.shibayu36.org

複数の本を購入するのはお財布的に厳しかったので、まずは1 冊の本をざっくり読み進めることにした。今まで本を読む時に分からない部分があるとググって、本(物理)を読んで、またググって... みたいなことをしていた。正直読書が苦手なオレが 1 ヶ月に 2 冊の本を読み切れるとは思わなかった。

育児

今月で月齢が 2 ヶ月になり、最初よりもかなり慣れてきた。最初は夜泣きがひどかったが、以下の記事がとても参考になった。

www.hitomiwatanabe.com

必殺ダブルおくるみのお陰で、最近は規則的な睡眠時間になっている。

体重も 5kg まで増えて、毎日お風呂入れるたびに腰が痛い(お風呂担当)。けど可愛いし、抱っこできるのも今のうちかもしれないからいっぱい抱っこしよう。最近はよく笑うようになった気がする。可愛い。

アンテナ張り

育休前に育休中もエンジニアとしてアンテナは張り続けたいなー。とは思っていたが、無意識にアンテナを張っていた。主に Twitter。あと育休に入ってはてブのテクノロジー分野を頻繁にチェックするようになった。Twitter ではあまり RT しない派だけど、ブックマークはちょこちょこしている。

b.hatena.ne.jp

おわり

毎日日記書いてる id:inokara さんはまじですごい。

inokara.hateblo.jp

2020年振り返り

1 年すぎるの早いね。今年も振り返っていく。

enokawa.hatenablog.jp

2020年の目標

  1. Kubernetes を人に説明できるレベルまで理解する
  2. Go 言語で 1 つ OSS を公開する
  3. GCP を完全に理解する(ためにブログを5本以上書く)

1. Kubernetes を人に説明できるレベルまで理解する

社内で Kubernetes(EKS) を利用しているプロジェクトがあって、新規参加メンバーに対してトレーニングを行った。Kubernetes のドキュメントやKubernetes完全ガイド ベースで、ざっくりと理解してもらうレベルで説明できたと自負している。ただトレーニングを受けてもらったメンバーからのフィードバックをもらい忘れたので微妙かも。

2. Go 言語で 1 つ OSS を公開する

taskdiff という ECS Task definition の Diff ツールを公開した。達成でいいでしょう!

github.com

enokawa.hatenablog.jp

3. GCP を完全に理解する(ためにブログを5本以上書く)

進捗ゼロ。まず目標の設定が良くなかった。ブログを n 本書く == 完全理解したというわけではないから、GCP の資格取得とかの方がよかったかな。GCP の資格したからといって完全理解というわけでもないけど。。。完全理解という言葉が抽象的すぎてが良くなかった。

2020年振り返り

2020 年はコンテナ技術周辺を深く学んだ年だった。プロジェクトで ECS や EKS を中心としたインフラの設計・構築・監視運用を行った。といっても、Docker や ECS、Kubernetes の使い方やトラブルシューティングなどを学んだだけで Docker や Kubernetes の内部実装に対して深く学んだという訳ではない。今後はそれらの内部実装なども理解できるようにしたい。具体的には、コンテナの高(低)レベルランタイムやそれらがどういう役割を担っているかとか理解できていないのでその辺り。

そう、社内で新しくチームを立ち上げた年でもあった。もともとは案件をガンガンこなすチームのリーダーだったが、CoE 的なチームを立ち上げた。具体的な業務内容としては、他チームからのヘルプ依頼を受け付けたり、インフラアーキテクチャのレビューを行ったり、各種標準化を行ったり、などなど。背景として、アイレットという会社がどんどん大きくなっていくなかで様々な課題があったため、それらの課題を解決するべく立ち上げた(抽象的でゴメンナサイ)。立ち上がりは上々といったところで、これから成果を出せていけそうな予感。

あと 11 月に息子が生まれた。かわいい。今月中旬から 1 年間、育児休暇を取得することに決めた。毎日家事と育児で仕事よりも大変だが、日々息子の成長が見れて楽しい。育休取得を快諾してくれた上司や、各種引き継ぎに協力してもらった方々には頭が上がらない。本当にありがたい。

2021年どうする

ほぼほぼ育児や家事に費やすと思う。仮に時間が作れたら、CPU やネットワーク、ストレージ、HTTP、DNSSSL/TLSDNSLinux などの基礎知識を身に付けたい。正直に言うと今は理解が浅すぎる。のでコツコツ時間を見つけて本を読んだり、写経したり、検証したりして知識を深めていきたい。例えば Docker や Kubernetes も内部では Linux の cgroups や namespaces を利用しているのでその辺りとか。

あと、職務経歴書を書きたい。これは転職のためというよりは今まで自分がやってきたことを記録するため。以前、とあるお客さんに職務経歴書を評価のタイミングで書くことを勧められた。自分が過去どういうことをやってきて、今季はこういうことができたとかを記録することで、自分の成長過程が見える的な話をしてくれた(少し記憶があいまい)。新卒でアイレットに入社して 約 5 年半も経っているので、時間を掛けて 5 年半を振り返って記録したい。

ということで

来年から本気だす。

ecscheduleでECSのScheduled Taskを管理する

Japan APN Ambassador Advent Calendar 2020 2 日目のエントリです。ecschedule で ECS の Scheduled Task を管理してみました。

github.com

songmu.jp

インストール

go get でインストールしました。

$ go get github.com/Songmu/ecschedule/cmd/ecschedule
$ ecschedule -help
Usage of ecschedule (v0.3.0 rev:HEAD):
  -conf string
        configuration
  -version
        display version

Commands:
  apply  apply the rule
  dump   dump tasks
  run    run the rule
  diff   diff of the rule with remote

Scheduled Task の dump

dump サブコマンドで既存の Scheduled Task を dump することが可能です。今回は既に存在する Scheduled Task を dump してみます。

$ ecschedule dump --cluster sample-cluster --region ap-northeast-1 > ecschedule.yaml
$ cat ecschedule.yaml
region: ap-northeast-1
cluster: sample-cluster
rules:
- name: batch
  scheduleExpression: rate(1 minute)
  disabled: true
  taskDefinition: batch:6
  launch_type: FARGATE
  platform_version: 1.3.0
  network_configuration:
    aws_vpc_configuration:
      subnets:
      - subnet-xxxxxxxxxxxxxxxxxx
      security_groups:
      - sg-xxxxxxxxxxxxxxxxxx
      assign_public_ip: ENABLED

ecschedule.yaml に対象 ECS Cluster に存在する Scheduled Task が dump されました。

Scheduled Task の apply

該当の Scheduled Task が Disabled の状態となっているため、ecschedule で有効化してみます。

$ git diff
diff --git a/ecschedule.yaml b/ecschedule.yaml
index dd7be7b..31f021e 100644
--- a/ecschedule.yaml
+++ b/ecschedule.yaml
@@ -3,7 +3,6 @@ cluster: sample-cluster
 rules:
 - name: batch
   scheduleExpression: rate(1 minute)
-  disabled: true
   taskDefinition: batch:6
   launch_type: FARGATE
   platform_version: 1.3.0

ecschedule.yaml を変更して apply サブコマンドを実行する前に、diff サブコマンドで ecschedule.yaml と Scheduled Task の状態を差分確認してみます。

$ ecschedule -conf ecschedule.yaml diff -rule batch

以下の様に差分を出力してくれます。PR レビューに便利ですね。

f:id:enokawaa:20201129231810p:plain

差分が確認できたので apply します。

$ ecschedule -conf ecschedule.yaml apply -rule batch

差分が適用されました。

f:id:enokawaa:20201129232651p:plain

AWS マネージメントコンソールから Scheduled Task を見てみると、問題なく ENABLED となっていることが確認できました。

f:id:enokawaa:20201129233049p:plain

おわりに

簡単ですが、ecschedule を用いて Scheduled Task を管理してみました。とても便利ですね。個人的には dump 機能が好きです。「当初は AWS マネージメントコンソールや AWS CLI で作成したけど、後から IaC で管理したい」というケースに非常にマッチするのではないでしょうか。

ECS Service の Deployment は ecspresso で、Scheduled Task は ecschedule で管理すると最強なのでは説が僕の中で浮上しています。

ECS Task definitionのDiffツール taskdiff を作りました

業務で ECS の Task definition を更新する作業が多々あります。CI/CD パイプラインや CloudFormation、Terraform などで管理していれば Git で差分確認が可能ですが、手動更新だとそうはいきません。 ECS では Task definition の差分を確認する API は提供されていない(ハズ)ので、勉強も兼ねて Golang で taskdiff という CLI ツールを作成しました。

github.com

使い方

使い方はシンプルです。例えば sample-app:1sample-app:2 の差分を確認したい場合は以下のように実行します。

$ taskdiff sample-app:1 sample-app:2

f:id:enokawaa:20201021164659p:plain

taskdiff sample-app:1 sample-app:2 | less のようにパイプで less に渡す使い方を僕はよくやります。

Diff ライブラリ選定

Go で Diff を出力するライブラリはいくつかあったのですが、シンプルな kylelemons/godebug/diff を選びました。sergi/go-diff も見てみたのですが、僕が Go (というかプログラミングそのもの..)を殆ど理解できていないため、浅はかですがコード量がそこまで多くないライブラリを選びました。といっても kylelemons/godebug/diff も理解しきれていませんが。。今後の宿題です。

これからやりたいこと

git diff のように差分がある行の前後 n 行だけ表示できたらもっと UX 上がりそうだなと思ったので、挑戦したいですね。(色も付けたいな... テストも書いてはみたものの、これで良いのかが分かりません。圧倒的にインプットが足りてないので様々なプロダクトのソースを読んだりして、テスト含めちょこちょこ改善していきます。

モチベーション

「自分が欲しいと思ったツールを作りたい」というのが強いです。実際業務でけっこう使っていて我ながら「便利だなぁ」と思う時もあります。だんだんと愛着も湧いてきたので、コツコツ育てたいと思います。

まとめ

taskdiff という ECS Task definition の Diff ツールを作成しました。ツッコミとかあれば GitHub の Issue やブコメTwitter のリプ or DM でいただけると嬉しいです。

github.com

【2020年版】自宅の作業環境を整えた

コロナ禍で在宅ワークがメインになり、自宅の作業環境を整えたのでログとして残しておきます。 例の給付金と、僕が在籍するアイレットで環境設備補助金も出たので最高です。

www.iret.co.jp

Before

もともと大雨の時や家族の体調が悪い時、大幅に寝坊した時 など 1 ヶ月に数回は在宅で仕事していたため、ある程度作業環境は整えていました。

f:id:enokawaa:20200625184356j:plain

f:id:enokawaa:20200625184321j:plain

アイテム 名前 コメント
チェア オカムラ Baron 元同僚の id:y13i さんから譲り受けた最高
デスク DJテーブル/DODAI 高さが結構辛い
モニター Dell プロフェッショナルシリーズ P2419HC 23.8インチ ワイド USBーC モニター USB-C 給電最高
キーボード Apple Magic Keyboard - 英語(US) 会社から借りパク
マウス Designer Bluetooth® Mouse 特に無し
PC スタンド Bestand ノートパソコンスタンド 目線が上がるのでよい

オカムラ Baron は最高です。 id:y13i さんには感謝しかないです。モニターは引っ越し祝いで上司からもらいました。感謝しかないです。 これだけでも割と良い作業環境なのですが、デスクが DJ 用で結構高さがあるんですよね。それが辛くてデスクを新調することにしました。

After

憧れの昇降式デスクにチェンジしました。

f:id:enokawaa:20200625213908j:plain

f:id:enokawaa:20200625213937j:plain

アイテム 名前 コメント
デスク IKEA BEKANT 昇降式
キーボード PFU Happy Hacking Keyboard Professional2 墨 英語配列 会社用で使ってた
マウス Apple Magic Mouse 2 - シルバー 会社の後輩から借りパク
USB 充電器 Anker PowerPort I PD 適当に
ヘッドホンハンガー audio-technica ヘッドホンハンガー AT-HPH300 audio-technica のヘッドホン使ってるので合わせた
ワイヤレス充電器 1 Anker PowerWave 10 Pad AirPods
ワイヤレス充電器 2 不明 クラウドネイティブさんノベルティ
パームレスト MMTT ウッドパームレスト タイピングがラク

慢性腰痛持ちで、今年の 4 月に急に強く痛みだしたので昇降式デスクにしました。ちょこちょこスタンディングで仕事すれば少しは良くなるかなと。FlexiSpot も検討したのですが、組み立てが楽そう && 奥行きなどサイズ感がベストだったので IKEA に決めました。

実際にスタンディングで仕事をしているのか?

購入する前に「昇降式デスクを買ったとして本当にスタンディングで仕事するのか?」と考えたのですが、スタンディングしたのは最初の一週間くらいでした。 もちろん個人差はあると思いますが、昇降式デスクの購入を検討している方の参考となれば幸いです。昇降機能の有無で値段に結構差があるので。

昇降式デスクにしてよかったこと

今回購入した BEKANT は天板裏に収納スペースがあり、そこに電源タップや USB 充電器を収納しています。 ケーブルの抜き差しや、収納作業の際に最高の高さにすれば中腰くらいで作業ができるのでラクです。個人的には今のところそれくらいしか良かったことが見当たらないですね。。

f:id:enokawaa:20200625213957j:plain
天板裏

余談

僕の所属するアイレットでは DocBase という情報共有ツールを利用しているのですが、コロナ禍でもポジティブにいこうぜということで俺のデスクというタグで自分の作業環境を晒してみました。始めたきっかけは「俺のデスクを自慢したい!」とかではなく、単純に「他のメンバーのデスク環境を見てみたかったから」でした。思いのほか反響があり様々なメンバーが俺のデスクシリーズを公開し、いま DocBase を見たら 14 件メモ( DocBase の記事の単位 )が公開されていました。小さいムーブメントが起きて面白いですね。他にも派生( ? )して自己紹介のメモも公開されたりしています。

EKSにPrisma Cloudを導入する

EKS に Prisma Cloud を導入してみたのでメモとして残しておきます。

www.paloaltonetworks.jp

Prisma Cloudとは

Palo Alto Netoworks 社が提供する SaaS 型のセキュリティ製品です。 Palo Alto Netoworks 社が Evident.io 社、RedLock 社、Twistlock 社、PureSec 社を買収し、そのうちの Twistlock と PureSec の機能が Prisma Cloud に統合されました。 今回は Twistlock の機能である Defender を EKS にデプロイします。

www.paloaltonetworks.jp

blog.paloaltonetworks.com

Defenderのインストール

公式ドキュメントを参考に進めていきます。

docs.paloaltonetworks.com

EKS や Kubernetes 環境は事前に用意しておいて下さい。 今回は以下のエントリで記載した方法で EKS Cluster を用意しました。

enokawa.hatenablog.jp

0. Prisma Cloudのフリートライアル申し込み

以下のページよりフリートライアル( 30 日 )を申し込みます。

marketplace.paloaltonetworks.com

Activate のメールが送信されるので、Activate Link をクリックしアカウントし、ページに従って進めます。

1. Console’s API addressを控える

Compute > System > Downloads > Path to Console で内容をコピーしておきます。 ついでに後ほど利用する twistcli もインストールしておきます。

f:id:enokawaa:20200608215928p:plain

2. Console’s service addressを控える

Compute > Manage > Defenders > Deploy > DaemonSet の「The name that clients and Defenders use to access this Console」の内容をコピーしておきます。 といってもテキストを選択することができないのですが。。確証は無いですが、おそらく 1 の手順で控えた URL と同じ FQDN です。

f:id:enokawaa:20200608215601p:plain

3. defender.yamlの生成

EKS へデプロイする defender.yamltwistcli で生成します。

$ twistcli defender export kubernetes \
--address https://xxxxx.cloud.twistlock.com/xxxxxxxxx \ # 1 で控えた Console’s API address
--user enokawa@example.com \ # Prisma Cloud アカウントのメールアドレス
--cluster-address xxxxx.cloud.twistlock.com # 2 で控えた Console’s service address

パスワードを求められるので、Prisma Cloud アカウントのパスワードを入力します。はい。401 が出ました。

Please provide Console credentials: 
Enter Password for enokawa@example.com: # Prisma Cloud アカウントのパスワードを入力
Status: 401 Unauthorized
GET https://xxxxx.cloud.twistlock.com/xxxxxxxxx/api/v1/version failed.
Error: invalid credentials

ソースは見つけられなかったのですが、この認証には Access Keys を用いる必要があるみたいなので作成します。 Settings > Access Keys > + Add New > で Name を入力して Create します。Access Key ID と Secret Key が表示されますので控えておきます。CSV でのダウンロードも可能です。

f:id:enokawaa:20200608221458p:plain

再度 twistcli を実行します。

$ twistcli defender export kubernetes \
--address https://xxxxx.cloud.twistlock.com/xxxxxxxxx \ # 1 で控えた Console’s API address
--user XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX \ # Access Key ID
--cluster-address xxxxx.cloud.twistlock.com # 2 で控えた Console’s service address
Please provide Console credentials:
Enter Password for XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX: # Secret Key
defender daemonset written successfully to /path/to/your/directory/defender.yaml

正常に defender.yaml が生成されました。

4. defender.yamlのデプロイ

事前に twistlock Namespace を作成しておく必要がある必要があります。

$ kubectl create namespace twistlock
namespace/twistlock created

デプロイします。

$ kubectl create -f defender.yaml
clusterrole.rbac.authorization.k8s.io/twistlock-view created
clusterrolebinding.rbac.authorization.k8s.io/twistlock-view-binding created
secret/twistlock-secrets created
serviceaccount/twistlock-service created
daemonset.apps/twistlock-defender-ds created
service/defender created

デプロイが完了しました。全てのノードで twistlock-defender-ds DaemonSet が起動していることが分かります。

$ kubectl get daemonset/twistlock-defender-ds -n twistlock
NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
twistlock-defender-ds   3         3         3       3            3           <none>          2m28s

$ kubectl get pods -n twistlock -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP           NODE                         NOMINATED NODE   READINESS GATES
twistlock-defender-ds-7lxmx   1/1     Running   0          3m    10.0.3.94    ip-10-0-3-94.ec2.internal    <none>           <none>
twistlock-defender-ds-7nqmc   1/1     Running   0          3m    10.0.5.16    ip-10-0-5-16.ec2.internal    <none>           <none>
twistlock-defender-ds-npwm5   1/1     Running   0          3m    10.0.4.245   ip-10-0-4-245.ec2.internal   <none>           <none>

5. Prisma Cloudを確認

実際に Prisma Cloud 上に浮かび上がってきているかを確認しましょう。 Compute > Defenders > Manage > Defenders で、DaemonSet が表示されました。

f:id:enokawaa:20200608224106p:plain

DaemonSet をクリックすると、Filesystem や Network の状況が確認できます。

f:id:enokawaa:20200608230203p:plain

サンプルアプリケーションのデプロイ

このままじゃつまらないので、サンプルアプリケーション( ゲストブック )をデプロイして Prisma Cloud の挙動を確認してみます。

docs.aws.amazon.com

手順通りに流します。

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-master-controller.json
replicationcontroller/redis-master created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-master-service.json
service/redis-master created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-slave-controller.json
replicationcontroller/redis-slave created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/redis-slave-service.json
service/redis-slave created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/guestbook-controller.json
replicationcontroller/guestbook created
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/examples/master/guestbook-go/guestbook-service.json
service/guestbook created
$ kubectl get services -o wide
NAME           TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)          AGE    SELECTOR
guestbook      LoadBalancer   172.20.59.58     xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0123456789.us-east-1.elb.amazonaws.com   3000:32530/TCP   78s    app=guestbook
kubernetes     ClusterIP      172.20.0.1       <none>                                                                    443/TCP          116m   <none>
redis-master   ClusterIP      172.20.101.101   <none>                                                                    6379/TCP         115s   app=redis,role=master
redis-slave    ClusterIP      172.20.60.151    <none>                                                                    6379/TCP         95s    app=redis,role=slave

ブラウザで動作確認までできました。

f:id:enokawaa:20200608231549p:plain

Rader

Twistlock の代表的な機能である Radar をスクショ祭でお届けします。

docs.paloaltonetworks.com

俯瞰的に Pod を視認することが可能です。

f:id:enokawaa:20200608232041p:plain

Docker image や Namespace が確認できたり。

f:id:enokawaa:20200608232145p:plain

Docker image の脆弱性も確認可能です。

f:id:enokawaa:20200608232617p:plain

Host OS で起動しているプロセスの一覧も確認できました。

f:id:enokawaa:20200608233208p:plain

そのプロセスが起動している Host や起動ユーザも確認できたり。

f:id:enokawaa:20200608233632p:plain

Host OS で起動している Docker や Kubernetes のバージョンも確認可能。kernel の CVE も確認できました。親切に Amazon Linux Security Center へのリンクも記載されています。嬉しいですね。 Docker image やホストだけではなく、コンテナランタイムの脆弱性にもいち早く気付けそうです。

f:id:enokawaa:20200608233926p:plain

他にも多くの機能が

今回は Twistlock の機能を中心に紹介しましたが、Prisma Cloud には他にも AWS や Azure、GCP、Alibaba Cloud などのクラウドアカウントを追加も可能で、アカウントの設定内容なども横断的に監視することが可能です。 複数のクラウドアカウントを管理していて、かつ Host や Kubernetes、Lambda などの FaaS をまとめていい感じにセキュリティを俯瞰したいというニーズにはマッチしそうです。