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

HANDS LAB

HANDS LAB ENGINEERS BLOG

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

カテゴリー: AWS

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操作権限が付与されていれば今からでも手軽に設定できると思いますので実施してみてください。


Serverless Frameworkでバイナリデータを処理するアーキテクチャを構築したかった


こんにちは。AWSチーム百木田です。

サーバーレス、してますか?

この度、「クライアントから画像を受け取ったらLambdaでその画像の処理をする」ということがしたく、受け取る部分を昨年11月に発表されてできるようになったAPI Gatewayでのバイナリデータサポートを利用してやってみました。
そして何かツールを使って楽にデプロイしたいと思い、今回はServerless Frameworkを利用してやってみることにしました。

環境

  • OS(VM): CentOS Linux release 7.2.1511 (Core)
  • Node Version: 7.5.0
  • Serverless Version: 1.8.0

準備

Serverlessの定義ファイル作成

Serverlessのセットアップについては省略させていただきます。’serverless’コマンドが実行できる前提です。

‘serverless.yml’を作成します。

定義している内容は以下です。

  • LambdaからS3にデータを置くためのIAMロールを定義
  • POSTで受けてLambda処理を行うAPI Gatewayを定義
  • 画像を保存するS3 Bucketを定義

注)S3バケット名の部分は変更してください。

タイトルで「してみた」にできなかったのには理由があり、残念なことに肝心のバイナリデータサポートの設定は現時点でServerlessでは対応していませんでした。そのためプラグインを使用するか他の方法で設定する必要があります。今回は泥臭くデプロイ後にマネジメントコンソールで設定することにします。

Lambda実行コードを作成

Lambdaでの処理は受け取った画像データをS3にアップロードするという簡単なものにしました。

ここではデータを’/tmp’に一度保存していますがもちろん受け取ってそのままS3にあげちゃってもOKです。

デプロイ

バイナリデータサポートを設定

‘serverless deploy’するとS3バケットやAPI Gateway、Lambdaといったリソースが作成されているかと思います。その後、API Gatewayのマネジメントコンソールからバイナリサポートのバイナリメディアタイプに’image/jpg’などPOSTで受ける’Content-Type’に合わせた値を設定します。

バイナリサポート設定後のAPIをデプロイするために再度’serverless deploy’をします。再度デプロイしても手動で設定したバイナリサポートの設定は消えません。

これで設定は完了です。

実際に試してみる

お手軽に試すにはローカル端末から以下のコマンドを実行します。

‘Upload Sccessful’が表示され、S3の指定バケットにファイルが保存されています。

まとめ

今回はServerless Frameworkを利用しましたが他にもSAMApexLamveryなどツールが出ているので今後試していきたいと思います。Serverless Frameworkも順次アップデートされているので今後楽しみです。

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


Kinesis FirehoseがS3に出力したファイルを1レコードずつ読み込む


皆々様、お久しぶりのブログ更新です。

Kinesis FirehoseがS3に出力したファイルをPythonでモニャモニャしたいと思っていたところ以下のことでつまづいてしまいました。

1つのファイルに複数レコード出力されている場合、改行(区切り文字)がなく1レコードずつ読み込めない!

改行とか入っていて、1行ずつ読み込むんだろう・・・みたいな想像を勝手にしていたのでちょっとつまずいてしまいました。

AWSのデモデータをKinesisFirehoseに流すと実際のファイルはの中身は下記のようになります。

こういったJsonストリームデータをPythonで処理する時ってどうしたらいいんだろうと調べていたらjsonライブラリにJSONDecoderというのがあるのを見つけました。

下記サンプルです。

これを実行すると下記のように出力されました〜。

そうです、この記事・・・単にストリームデータの読み込み方についての記事です!KinesisFirehoseは完全に引きです!

でもストリームデータを扱うことは個人的には今後も増えそうなので今回調べておいてよかったです!

ではでは〜。


眠すぎる朝のPolly


テバサキワ
ハンズラボ 吉田です。

乗り継ぎ3時間待ちが非常に辛いです。。。
ここで寝たら日本に帰れないので書いています

img_1926

割とどうでも良いのですが、自分、ベガスでこの高さからダイブしました。
すっげーーー気持ちいい。次はスカイダイビングしてみたいです。

本題に移ります

続きを読む 眠すぎる朝のPolly


眠れない夜のAthena


ハンズラボの小林です。

現在、re:Inventに參加するためベガスに来ています。

ベガスと言えばカジノ!

昨日の夜、ルーレットをやってみたところ、大当たり!

これがビギナーズラックというものか。

、、、と思ったら夢か。

現在、こちらの時間で12月1日の午前3時30分。

明日も朝8時からKeynoteがあるし早く寝なければ!

しかし、カジノの興奮が覚めず眠れない、、、

そんな眠れない夜には「Amazon Athena」(S3へ簡易SQLが可能に)を試してみよう。

東急ハンズはユニケージ開発手法を使っていて、マスタや売上、在庫といった業務データをテキストファイルで管理しているのでAthenaとの親和性が高そうだ。

ただ気になるのはパフォーマンスだ。

Athenaの内部で、単にファイルを読み込んでいるだけだったらパフォーマンスは良くなさそうな気がする。

とりあえず簡単なデータで試してみよう。

カラムは1個で、数字の1〜1000というデータ。

Linuxサーバー上で↓のようなファイルを作り、S3にアップロード。

次にAthenaのコンソール画面からテーブルを作成。(簡単かな?)

①DB名、テーブル名、S3のディレクトリ名を入力

athena1

②次にファイルのフォーマットを指定。

athena2

③次にカラム定義。

athena3

④で最後に「Configure Partitions」

なんじゃこれは?明日も早いし調べてる時間もないからとりあえず無視。

athena4

これでテーブル作成。

athena5

おぉ、できた!

こういうのって、大体1回目は失敗するのに。こいつは簡単だな。

で肝心のパフォーマンスを確認。

athena6

結果は0.6秒。遅っ!

う〜ん、これ、ファイルとレコード件数が増えたらどうなってしまうんだろう、、、

ってことで、さっきと同様の1,000レコードのファイルを1,000個を作ってS3にアップロード。(カラム1個で数字がさっきの続きで1001〜100000)

コンソールに100,000件も出ないだろうから、今度は件数を取ってみよう。

athena8

結果は2.89秒。致命的に遅い、、、

う〜ん、ファイルを1個で同じ件数にしてみたらどうだろう。

athena7

結果は0.78秒。さっきより早くなったが、それでも遅い。

whereを付けて1件を検索したらどうだろう。

◆ファイル1,000個の方

athena9

結果は3.04秒。

◆ファイル1個の方

athena10

結果は0.83秒。

同じような結果だな。

時計を見ると4時40分。そろそろ眠気が襲ってきたので、今日はここまでとするか。

今夜も眠れなかったらスノーモービルを試してみるか。

おやすみなさい。