sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

Service Catalog で作成したリソースに対してアクションを実行してみる

普段触らないサービスがだんだん気になってきている那須です。

AWS Service Catalog って皆さんご存知でしょうか? 超ざっくり言うと、CloudFormation を使って管理者が定義したリソースを一般ユーザがリソース作成に必要な権限を持たずに作成できる、そんなサービスです。 詳しくはクラスメソッドさんのブログをご参照ください。

dev.classmethod.jp

Service Catalog でリソース作成するブログはそれなりにあるんですが、Service Catalog で作成したリソースに対するアクションについて書かれたブログがあんまりないなーと思ったので、その話を書いてみます。

 

何ができるのか?

ドキュメントがあります。

docs.aws.amazon.com

セルフサービスアクションを使うことで、Systems Manager ドキュメントを実行して作成したリソースに対してアクションを実行できるんですね。 AWS から標準で提供されているドキュメントは、EC2 と RDS の起動/停止/再起動の 6 種類のアクションだけです(2019/1/17現在)
ただ、カスタムアクションとして自分で作成した Systems Manager ドキュメントも利用できるので、Systems Manager でできるアクションならだいたいのことは Service Catalog で作成したリソースに対して実行できそうです(バックアップ取得とか

 

どうやってやるの?

まずはアクションの定義

Service Catalog コンソールでサービスのアクションをクリック。 f:id:nasrinjp1:20190117104152p:plain

新しいアクションを作成しましょう。 f:id:nasrinjp1:20190117104208p:plain

ここでは EC2 インスタンスを開始するドキュメントを選択しました。 f:id:nasrinjp1:20190117104220p:plain

アクション名とバージョンを指定します。 f:id:nasrinjp1:20190117104232p:plain

パラメータを指定します。対象のインスタンス ID を指定するのはどのパラメータか?をここで選びましょう。 f:id:nasrinjp1:20190117104244p:plain

アクション実行の権限を決めます。 起動制約は推奨しないと書かれているので、ドキュメントの AssumeRole か IAM ロールのどちらかを決めます。 最後にアクションの作成を押して完了です。 f:id:nasrinjp1:20190117104256p:plain

次に作成したアクションを製品に関連付けましょう。 作成したアクションを選択してアクションの関連付けを押します。 f:id:nasrinjp1:20190117104307p:plain

製品とバージョンを選択してアクションの関連付けを押します。これで OK です。 f:id:nasrinjp1:20190117104319p:plain

一応確認してみましょう。作成したアクションをクリックします。 f:id:nasrinjp1:20190117104331p:plain

製品バージョンのところで製品名とバージョンが表示されていれば OK ですよ。 f:id:nasrinjp1:20190117104342p:plain

 

アクションの実行

Service Catalog 製品で起動したインスタンスがあります。今は停止していますね。 f:id:nasrinjp1:20190117105752p:plain

プロビジョニングされた製品名から対象のインスタンスをクリックします。 f:id:nasrinjp1:20190117105806p:plain

アクションから実行したいアクション名をクリックします。 f:id:nasrinjp1:20190117105818p:plain

アクションの実行を押しましょう。 f:id:nasrinjp1:20190117105832p:plain

インスタンスが起動しました! f:id:nasrinjp1:20190117105846p:plain

ログもバッチリ残ります。 f:id:nasrinjp1:20190117105901p:plain

 

どういう場面で使うの?

利用者視点だとこんな感じですかね。

  • いちいちリソース作成やアクションするのに管理者に申請書ベースで依頼して数日待つとか無理
  • 今すぐアクション実行したいのにパラメータとか知らねーよ!裏でいい感じにしてくれよ
  • 自分に関係あるリソースだけ表示してくれるように画面作ってほしい。フィルタのかけ方なんで知らないよ

ということで、クラウドの良さのひとつであるセルフサービスAWS アカウント管理者にではなく一般ユーザにも提供する、というのが Service Catalog セルフサービスアクションのポイントかなと思いました。

 

まとめ

忘れがちになりますが、AWS や他のクラウドサービスはセルフサービス型でサービス提供してくれるのがいいところなので、日本のような SI 業種の会社が多い環境であれば Service Catalog は案外必要とされるサービスなんじゃないかなーと思ってます。 どのようにサービスを提供するべきかはいろいろ案があるかと思いますが、本来のクラウドの思想を時々思い出して仕事しようと思いました。

AWS Security Hub のカスタムアクションで勘違いしてた話

あけましておめでとうございますー那須です。
今年もマイペースで記事を書いていきます。

Security Hub 知ってますか? 昨年の re:Invent 2018 で発表された新サービスで、セキュリティデータを収集して複数のアカウントのセキュリティ状況を一元的に見ることができます(雑ですまん

f:id:nasrinjp1:20190104192516p:plain
Security Hub 概要図

どんなふうに触ればいいのかは、クラスメソッドさんのブログを見てくださいませ。

dev.classmethod.jp

 

セキュリティ基準は何?

CIS (Center for Internet security) のベストプラクティスを基準にして AWS アカウントのセキュリティ評価をしてくれます。 CIS の中身は↓ここからいろいろ見てください。 AWS に限らず、Azure や GCPLinuxWindows といった観点でセキュリティのベストプラクティスを提供してくれています。

www.cisecurity.org

以前に勉強会で LT した時の資料も載せておきます。

 

今回お題のカスタムアクション

カスタムアクションは、Security Hub で検知した findings に対して実行できるアクションのことです。 例えば、ある finding についてメール送信したり Slack に通知したり、といった具合です。

Security Hub を調べててカスタムアクションを知った時、「お!これでセキュリティ基準にひっかかったらすぐに通知できて自動修正できるんちゃん?」って思いました。

 

よしやってみよう!

実際に動かして確かめてみました。

まず Slack の Webhook URL を準備します(画面はないです
そして↓このサンプルスタックで、CloudWatch イベント、Lambda ファンクション、その他もろもろを作成します。

github.com

これで準備 OK です。

最後に、カスタムアクションを作成して対象の findings を選択してカスタムアクションを実行します。

f:id:nasrinjp1:20190104195106p:plain
カスタムアクション作成

f:id:nasrinjp1:20190104195139p:plain
カスタムアクション実行

 

↑カスタムアクションを実行すると、このように Slack に通知されました。

f:id:nasrinjp1:20190104195311p:plain
Slack 通知結果

めでたしめでたし。。

 

え?自動でカスタムアクション実行してないやんって?

そうなんです。 カスタムアクション実行する方法はあるんですが、トリガーを設定する箇所がないんですよね。。
(実はあるけど私が見つけられてないだけやでって人がいればマジで教えてください)

なのでカスタムアクションの使いどころとしては、

  • どこかに通知する(マニュアルアクションなので用途は限られそう
  • 自動で修復する Lambda ファンクションに渡して手作業での運用を減らす(トリガーは手だけど修復作業は自動化

かなーと思ってます。

 

findings をトリガーにできるように期待しよう

手作業でカスタムアクションを実行するでもいいんですが、findings をトリガーにカスタムアクションを自動実行してくれると嬉しいですねー
そもそも私の使い方が根本的に間違ってる、という可能性はもちろんあります。。