AWSの話題を中心に、日々の業務やプログラミングの徒然を綴るエンジニアブログです。

HANDS LAB

HANDS LAB ENGINEERS BLOG

ハンズラボエンジニアブログ

12

作者別: YusukeKarakita

12月9日、10日開催!キッチンハッカソン2017の見どころを紹介!


こんにちは。百木田です。

すでに告知しておりますが2017年12月9日(土)、10日(日)と2日間に渡り、Oisix.daichiさんとハンズラボが共催でキッチンハッカソン2017を実施します!

Connpassイベントページ

テーマはその名の通りキッチン!

Oisix.daichiさんは食材を取り扱っており、ハンズは豊富なキッチン用品を取り扱っているということで、今回はキッチンをテーマにやってみようということになりました。
普段、キッチンに立つ方は、こんなのあったらいいのになー、を実現してみてください!料理をしない方でも、こんなアプリあったら料理するかも?とか、もしくは料理する方のお悩みを聞いて、それならこうできるのでは?とかをこのハッカソンで実現してみてください。
技術テーマは特に設けない予定なので、モバイルアプリ、Webアプリ、IoT、AI、ロボット、フィンテックなど、興味のあるものに挑戦してみてください!

会場はOisix.daichiさんの新オフィス!会社にキッチンだと!?




先日も関係者が集まり、そちらのオフィスにお邪魔してキックオフミーティングをしてきたのですが、とてもおしゃれな空間でテンションあがりました!
そしてなんと同じビルの1階にはキッチンが併設されており、料理ができるようになっているんです!
ミーティング後にキッチンを見学させていただいたのですが、その時も料理をしている最中で、会社の一室で本格的に料理をしている光景に驚きました。
写真はそのキッチンルームに併設されている作業スペースです!このスペースでハックしてもらう予定です!

Oisix.daichiさんの食材を使った手料理!

ハッカソン当日はそのキッチンでOisix.daichiさんのスタッフの方々が調理し、料理を振る舞っていただけるとのことで、そちらもハッカソンとともにお楽しみいただけます!

豪華審査員!嬉しい賞品も??

審査員にはOisix.daichi執行役員の奥谷孝司氏、数々のハッカソンを開催したり、大規模なコミュニティとなっているIoTLTのオーガナイザーでもあるdotstudio CEO 菅原のびすけ氏東急ハンズCIO(最高情報責任者)で弊社CEOの長谷川秀樹、他、など豪華メンバーを予定しているのでそちらもお楽しみに!!

優勝チームおよび優秀チームには、Oisix.daichiさんとハンズから、両社ならではの賞品を予定していますのでぜひ優勝目指してハックしてください!

詳細は申し込みページからご覧ください!

Connpassイベントページ


CodePipelineの進行状況をSlackに通知する


こんにちは。百木田です。
CI、回してますか?

CodePipelineで実行するステージの進行状況を手軽に見たいと思い、Slackに流れるようにしたので共有します。

ポイントとしては、CodePipelineからLambda functionを呼ぶのではなく、CloudWatchイベントでCodePipelineステージのステータスの変化を検知してLambda functionを呼び出します

今回はできるだけシンプルにするために、すでにCodePipelineは作成済みの想定で、すべてのステージにおけるSUCCEEDEDFAILEDのステータスを通知します。なのでCodePipelineに変更は必要ありません。
また、Slack Botを作成しトークンを発行して使っていますがIncomming Webhookでも同じようなことはできるかと思います。

Serverless Frameworkを使ってCloudWatchイベントの設定と、slackに通知するためのLambda functionをデプロイします。

環境

ディレクトリ構成

デプロイ

コードは記事の下の方に書いときます。上記のディレクトリ構成のように配置したらデプロイします。

デプロイできたらCodePipelineを動かしてみます。そうするとslackにこのような通知が来るかと思います。

いつの実行結果なのかをトレースできるようにCodePipelineの実行IDの前半7桁を表示しています。この辺はお好きにカスタマイズしてみてください。

まとめ

CloudWatchイベントの検知がリアルタイムじゃないので、CodePipelineの進行と通知にラグがあったり、前のステージの実行完了と次のステージの実行開始の通知が前後することなどもありますが、実行結果がわかればいいかなくらいの感じなので気にしないことにしてます。

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

以下、コードたち

status_notification.py

serverless.env.yml

serverless.yml

※ detailのセクションを消すと、すべてのステータスが検知対象になります。


Cognitoユーザープールから発行されたアクセストークンの署名チェック


こんにちは。百木田です。

アプリケーションの認証にCognito User poolsを使用する場合、API Gatewayを使用していればCognito User pools Authorizer機能を使って、Cognito認証済みユーザーからのリクエスト以外は拒否するといった制御できるのですが、自前サーバーでアクセストークンを使ったアクセスコントロールをしたい場合、トークンの有効性や改ざんされていないかなどの検証機能を用意する必要が出てくるかと思います。

今回は、署名チェックするための公開鍵作成(Node.js)から署名チェック(Go)までの手順をまとめましたので共有させていただきます。

環境

流れ

  • アクセストークンから公開鍵を作成
  • 作成した公開鍵を使って署名チェック

やっていきます。

トークンから公開鍵を作成(node.js)

JSON Web Token (JWT) Setをダウンロードする

(公式)ID トークンとアクセストークンの署名を確認する

<リージョン名>、<CognitoユーザープールID>を環境に合わせて入れます。
ここでダウンロードした情報をもとに公開鍵を作っていきます。

モジュールをインストール

公開鍵作成に必要なモジュールをインストールします。

公開鍵作成スクリプトを作成

スクリプトはこちらの記事を参考にさせていただきました。
Node.jsでAWS Cognito User Pools のアクセストークンを検証する

3行目のaccessTokenは公開鍵を作成したいユーザープールから発行されたものにします。

実行して出力された公開鍵をファイルに保存します。

作成された公開鍵はこんな感じになっているかと思います。

これがユーザープールの公開鍵として利用できます。

公開鍵を使ってトークンを検証する

今度は作成した公開鍵をもとに、サーバーに送られてきたアクセストークンが正当なものかをチェックします。

コードはこちらの記事を参考にさせていただきました。
【Go言語】GoでJWT(JSON Web Token)を使うサンプル

tokenStringに検証するトークンを入れます。

実行する。

有効なトークンであれば上記のような出力になるかと思います。

トークンの無効性を確認してみる

こちらのサイトでトークンのエンコード・デコードができるので、試しに内容を書き換えた(改ざんした)トークンを検証してみます。

RSA公開鍵暗号アルゴリズムを選択します。

左側にアクセストークンをいれると、右側にデコードされたトークンの中身が表示されます。

右側のトークンの内容を書き換えると左側にエンコードされたものが表示されます。
それを先ほどの署名チェック(validationCheck.go)のtokenStringに入れて再度実行するとInvalid tokenと出力されるかと思います。

有効期限が切れたトークンでも同様に無効の結果となります。

まとめ

ちょっとつらかったですができました。これをいい感じでアプリに埋め込むといいのではないでしょうか。


東急ハンズでAmazon Chimeを導入した時に調べたこと


こんにちは。百木田です。

今年の2月にリリースされたAmazon Chimeをこの度、東急ハンズの会議に使ってみることになりました。

以下がChimeを採用したいくつかの理由です。

  • シンプルな操作
  • 最大100人がビデオミーティングに参加可能
  • 主催側から参加者をミュート可能

Chimeを本格的に利用することになり、いろいろ調べたのですがまだまだナレッジが少なく試行錯誤したので、わかったことを残しておこうと思います。

Chimeアカウントとユーザー

Chimeにはアカウントユーザーという単位が出てきます。イメージ的にはアカウントは会社やチームなどのグループで、ユーザーは個人に紐づくものです。

ChimeユーザーはAmazon.co.jpのアカウントと紐付いていて、AWSアカウントを持っていなくても使用できますが、AWSコンソールからChimeアカウントとChimeユーザーを紐付けることでユーザー管理をすることができるようになるなど便利に利用できます。

以下がChimeアカウントの種類です。

少し補足するとこんな感じ。

Amazonアカウント

・ AWSアカウントで管理されていない単独のアカウント(ユーザー)。

チームアカウント

・ AWSのChimeで作成したアカウントにユーザーを招待できる。

エンタープライズアカウント

・ 自社のドメインをAWSアカウントのChimeへ登録する必要あり。
・ そのドメインのメールアドレスでChimeにログインすると自動的にアカウントにユーザーが追加される。

ちょっとややこしいです。整理するために図にしてみました。

グループミーティングをホストするにはPro Editionを付与したChimeユーザーが必要です。主催者によってミーティングがホストされると、Chimeユーザーを作成していない人でもミーティングIDを教えてもらうことでミーティングに参加することができます。

ポートと通信帯域の要件

通常のビデオミーティングをする場合は以下のそれぞれのIPアドレス:ポートに対するアウトバウンド通信を許可してあげる必要があります。

IP Address

  • 52.54.62.192/26
  • 52.54.63.0/25
  • 52.54.63.128/26
  • 52.55.63.128/25

Ports

  • TCP/443
  • UDP/16384:17383
  • UDP/3478

ポートの要件はこちらに記載されています。
hosts-ports-and-protocols-needed-for-amazon-chime

各機能を利用する上で必要な通信帯域はこちらに記載されています。
what-are-the-bandwidth-requirements-for-amazon-chi

料金体系

各ユーザーエディションごとの料金は公式サイトに記載されているとおりです。

ユーザーはAWSコンソール上からエディションをGrantさせたりRevokeさせたりできるのですが、課金されるのはProエディションをGrantさせてた期間の日割り計算になります。
なので1ユーザーを1ヶ月のうち合計20日間ProエディションをGrantさせていた場合、

という計算になります。
なお、課金は1ユーザーごとになるため、2ユーザー以上利用した場合はユーザー数分の課金が発生します。

AD連携

AWSのAD Connectorを利用することでChimeのAD連携をすることができます。しかしながらAD連携するにはAD Connectorがバージニアリージョンにある必要があります。

まとめ

以上となります。Chimeの使用感や問題点、会議する上で工夫したこと、考慮した方がいいことなどあるのですが、そちらは別の機会に書ければと思っています。
Chime自体、登場したばっかりでまだまだ改善の余地がありますがフィードバックをしつつ、アップデートに期待したいと思います。
ありがとうございました。


IAMポリシーで自分の所有リソース以外の操作を制限する


こんにちは。百木田です。

先日、こんなことがありましたね。
Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。

人間が関わっている以上、人的ミスはどうしても避けられないので工夫してミスを減らしましょうという教訓ですね。

今回のブログでは新しい技術は使ってないですが、そんなニュースもあったので人的なミス防止に関連する共有です

AWSを導入している企業であればAWSの機能や技術を検証するために、
サービス提供しているアカウントから分離された検証用アカウントを利用している場合も多いかと思います。
本番環境ではユーザーに適切な権限を付与し、事故を防止していることと思いますが、検証環境では事故の影響が小さかったり、検証するために必要な権限が多い or 不明確であったりということもあり、それぞれのIAMユーザにAdministrator権限に近い権限を付与しているといったこともあるかと思います。

自分が操作しているリソースのすぐとなりに他の人が検証で使用しているリソースがある場合、そういった権限を持っていれば少しコンソール操作をしくじっただけでリソースが消え、両者、冷や汗状態です。

基本的に私はしくじる側の人間だと思っているので、そんな環境でコンソール操作するのはめちゃくちゃイヤなわけで、寝ぼけながら操作しても自分以外の管理するリソースを操作すること無いようにしたかったわけです。
(入社した月にそんなことやらかした時にはもうあれですね。)

今回はEC2インスタンスの[開始/停止/再起動/削除]操作を制限するポリシーを設定します。

設定方法

  1. 操作制限を書いたIAMポリシーを作成
  2. 自分の使用しているIAMユーザーに対して作成したIAMポリシーを付与
  3. 自分が管理しているEC2インスタンスにタグ付け
      Ownerというタグネームに対して自分のIAMユーザー名を設定
      

作成したIAMポリシーは以下です。

「操作するEC2インスタンスのOwnerタグと、現在使用しているIAMユーザー名が異なる場合はActionの操作を拒否」という内容です。
また、どのユーザーでも同じポリシーが使用できるようにユーザー名の部分は変数を指定しています。

試してみる

Ownerタグに自分のIAMユーザー名が設定されているインスタンスは操作できます。

そうでないリソースは操作時にエラーが出るようになりました。

CLIで試しても同様にエラーとなります。

まとめ

権限を少し工夫するだけで安心して作業できるようになりました。
現在お使いのIAMユーザーにIAM操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。


12
  • IT酒場放浪記 記事一覧
  • エンジニア募集中!