やーまんぶろぐ

気が向いた時にだけ書くブログ

IAMで踏み台サーバのローカルユーザを一元管理を実行してみる

この記事の続きです。
yamano3201.hatenablog.jp

踏み台サーバのCloudFormationテンプレートでは実現できなかった、以下の要件に対応したいと思います。

  • ユーザアカウントごとにログインさせる
  • 可能な限りユーザアカウントの管理を減らしたい
  • sudo を使わせない

基本的には以下のサイトと同じです。
qiita.com

やってることは踏み台上にIAMユーザと同名のローカルユーザを自動作成して、アカウント管理を減らそうというものになります。
IAMユーザにはSSH公開鍵を登録できるので、それをローカルユーザの.ssh/authorized_keysとしてセットすることでSSHログインも管理できます。

事前準備

  • IAMユーザにsshパブリックキーを登録
  • iam list-users, iam list-ssh-public-keys, iam get-ssh-public-keyの権限を持ったIAMロールを用意(とりあえず前回作成されたIAMロールにIAMReadOnlyAccessポリシーを追加しました)

USER DATAに登録

オートスケールで自動で作成されるたびにスクリプトを流します。
スクリプトはリンク先bashスクリプトとほぼ同じなので割愛します。

USER DATA上でjqをインストールする必要があるのでご注意ください。

sudo yum install -y jq

前回作成したUSER DATAの下に、jqインストールとリンク先スクリプトを追加するとうまく動くと思います。

鍵の更新についても実装していますが、オートスケールによって毎回新規で作成されるので余分なところは削ってもよいかもしれないです。

configurationを作成してアタッチする

オートスケールのconfigurationは編集できないので、新しく作成しましょう。(コピーすると簡単です)
そこでUSER DATAを編集します。

初期ユーザであるec2-userではなく、各ローカルユーザでログインさせたい場合は鍵の登録は不要です。

最後にAutoScallingGroup側で新しいconfigurationをアタッチすれば完成です。

最後に

前回記事と合わせると、以下の要件を合わせた踏み台の作成が完成しました。

  • ログインの証跡を残す
  • 証跡はS3に保存
  • yum updateが定期的に走る
  • オートスケールする(可能であればログインするときだけ起動するようにしたい)
  • ユーザアカウントごとにログインさせる
  • 可能な限りユーザアカウントの管理を減らしたい
  • sudo を使わせない

yamano3201.hatenablog.jp

踏み台サーバのCloudFormationテンプレートを実行してみる

踏み台サーバの要件を洗い出してみたところ、ほとんどが提供されているCloudFormationのテンプレートでカバーできていることがわかったので、まずは実行してみることにしました。

基本的には以下のサイトと同じです。
dev.classmethod.jp

要件

  • テンプレートで実現できていること
    • ログインの証跡を残す
    • 証跡はS3に保存
    • yum updateが定期的に走る
    • オートスケールする(可能であればログインするときだけ起動するようにしたい)
  • テンプレートで実現できていなかったこと
    • ユーザアカウントごとにログインさせる
    • 可能な限りユーザアカウントの管理を減らしたい
    • sudo を使わせない

今回はテンプレートでほとんどの要件を満たしていることを確認しました。
実現できていないことに関しても対策を行ったので別の記事にしたいと思います。

※2017/11/16 追記しました。
yamano3201.hatenablog.jp

実行

リンク先から「Launch Quick Start(for new VPC)」を実行します。遷移先はオレゴンリージョンになってるので構築したいリージョンに変更しましょう。
docs.aws.amazon.com

詳細は以下を入力して実行しました。
f:id:yamano3201:20171115111419p:plain

for existing VPCのほうを実行するとなぜかAutoScallingGroupの作成でタイムアウトになって以下のエラーが出てしまいました。解析はしてないです。

Received 0 SUCCESS signal(s) out of 1. Unable to satisfy 100% MinSuccessfulInstancesPercent requirement

確認

  • ログインの証跡を残す
    • ec2-userでログインして/var/log/bastion/bastion.log を確認するとコマンド履歴が残っていることがわかります
  • 証跡はS3に保存
    • CloudWatchLogsにLinux-bastion-BastionStack-XXXX-BastionMainLogGroup-YYYY というロググループが作成されています。その下にインスタンスID名のLogStreamsが作成されています。オートスケールされるたびに同一のロググループに新しいLogStreamsが作成される形になります。
  • yum updateが定期的に走る
    • cronで実現していました。
$ crontab -l
0 0 * * * yum -y update --security
  • オートスケールする(可能であればログインするときだけ起動するようにしたい)
    • インスタンスを停止させると、インスタンスが削除されて新しいインスタンスが作成されました
    • ログインするときだけ起動すれば充分なので、夕方に削除されるスケジュールアクションを追加しました。

f:id:yamano3201:20171115111129p:plain

まとめ

これでほとんどがOKですね。次回は、テンプレートで実現できなかった部分をまとめたいと思います。

※2017/11/16 追記しました。
yamano3201.hatenablog.jp

RDSのread onlyのON/OFFをCLIで実行

こちらのAmazon RDS編 ~リードレプリカへの書き込み~ 記事を参考にread onlyのON/OFFをCLIで実行してみました。
recipe.kc-cloud.jp

パラメータグループのread_only のflagをONにすることで書き込みができなくなります。

read_only ON

$ aws rds modify-db-parameter-group --db-parameter-group-name XXXX --parameters 'ParameterName=read_only,ParameterValue=1,ApplyMethod=immediate'

反対にflagをOFFにすることで書き込みが可能になります。

read_only OFF

$ aws rds modify-db-parameter-group --db-parameter-group-name XXXX --parameters 'ParameterName=read_only,ParameterValue=0,ApplyMethod=immediate'

仮想環境(venv)の使い方 Python3 メモ

macで以下の環境で実行しました。

$ python3 -V
Python 3.5.1

Pythonの標準モジュールvenvを使うことで、プログラムごとに実行環境を分離できます。

$ python3 -m venv hoge
$ . hoge/bin/activate
(hoge) $ python -V
Python 3.5.1
(hoge) $ deactivate
$ 

バージョン番号を使わなくても、pythonコマンドで仮想環境に紐付けられたPythoランタイムを起動できます。

Pythonクローリング&スクレイピング -データ収集・解析のための実践開発ガイド- メモ

クローリング&スクレイピングに興味があったので読んでみました。
サンプルページも多く、非常に参考になりました。

クローリング・スクレイピングとは何か

まずは説明。

  • クローリング
    • Webページのハイパーリンクをたどって次々にWebページをダウンロードする作業
  • スクレイピング
    • ダウンロードしたWebページから必要な情報を抜き出す作業

Pythonではじめるクローリング・スクレイピング

Webページを取得する、正規表現で情報を抜き出す、データベースに保存する、という3つの処理を行います。

ここではゴリゴリに実装しています。

強力なライブラリ

ライブラリのメモ。

データベースへの保存についても書かれています。

実用のためのメソッド

ここではよい設計について書かれています。
キャッシュを使って更新されたデータだけを取得する方法、クロール先が変化した場合のメール通知などが書かれています。

クローリング・スクレイピングの実践とデータの活用

ここではAPIに対応しているサービスの情報取得について書かれています。
APIで取得するとスクレイピングが不要になるので、けっきょくこれが一番実用的だと思いました。

他にもデータ可視化についても書かれています。

フレームワーク Scrapy

Webサイトのクローリング・スクレイピングをするなら、以下のことができるScrapyというフレームワークを使うのがよいみたいです。

  • Webページからのリンクの抽出
  • robots.txtの取得と拒否されているページのクロール防止
  • XMLサイトマップの取得とリンクの抽出
  • ドメインごと / IPアドレスごとのクロール時間間隔の調整
  • 複数のクロール先の平行処理
  • 重複するURLのクロール防止
  • エラー時の回数制限付きのリトライ
  • クローラーのデーモン化とジョブの管理

Elasticsearchによる全文検索についても書かれていました。

クローラーの継続的な運用・管理

AWSでの運用・管理方法が書かれています。EC2上のcronで動かすくらいなら、PythonだしLambdaでいいんじゃないかと思いました。

メールによる通知をSESもあるのでクラウド化できそうですね。

クラウド活用としては画像の保存先としてS3が紹介されていました。

Vagrantによる開発環境の構築

一般的なVagrantの話。

英語で読み解く ドラッカー『イノベーションと起業家精神』 メモ

この本の中では「変化をチャンスと捉えて、その変化を活かして新しい価値を生むこと」をイノベーション、「そのイノベーションという手法を使って、新しい価値を生む事業を立ち上げる人がアントレプレナー(起業家)」としています。

著書「イノベーション起業家精神」を原文そのままで読むことで、ドラッカーの本当に伝えたかった意図に気づくことができる。というものです。

キーセンテンスがまとまっているので、非常に読みやすい作りになってました。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

The Practice of Innovation イノベーションを起こす

起業家精神は理論として実践でき、体系的に学ぶことができるものだとしています。その理論とは、変化を当然かつ健全なものと見ることで、以下の7つの変化の種があります。

  • The unexpected 予期していなかった結果
  • The incongruity 不一致、ギャップ
    • 不一致、ギャップを適した形に変えることでイノベーションを起こす。「アクションはまずは小さく、シンプルに、フォーカスを利かせて」が鉄則。
  • Innovation based on process need プロセスニーズ
    • 明確な目的があるプロセスの中で生まれるニーズ。既に存在している仕事や作業の確立されたプロセスの中に生じるtask focused。
  • Changes in industry structure or market structure that catch everyone unawares 業界と市場構造の変化
    • 旧来型のビジネスを続けていくことは、ほぼ崩壊を保証するものであり、会社に滅亡を宣告するようなものだ。
  • Demographics(population changes) 人口動態
    • 近い将来に動く人口動態とそこから生まれる新たな機会は、誰でも予測することができる。
  • Changes in perception, mood, and meaning 認識の変化
    • 認識というのは目に見えないので変化を捉えるのが難しい。
  • New knowledge, both scientific and nonscientific 新しい知識
    • 「知」によるイノベーションが最強。完成したビジネスシステム、市場の絞り込みと集中、戦略的に優位なポジションで独占することが成功の鍵。

The Practice of Entrepreneurship 起業家的にマネジメントする

イノベーションを起こし、成功させ続けるための組織マネジメントについて書かれています。以下の6つにポイントを意識します。

  • policies 考え方
    • イノベーションを魅力的で、自分たちにもメリットがあるものだと捉えることが重要。破棄こそがイノベーションへの一歩で、変化をチャンスと捉えるようにマネジメントされなくてはならない。
  • practices 実施作
    • 問題に意識を奪われるよりも、チャンスに焦点を合わせること。最も価値のあるせいかとは、組織全体の考え方や風土が変化していくこと。
  • measurement 評価
  • structures 組織
    • 旧来の既存事業とは切り離して運営する。
  • staffing 人材
    • 必要なのは学ぼうとする姿勢。
  • dont's タブー
    • 自社の得意領域から外れたイノベーションのための努力は、成功する確立が極めて低い。

Entrepreneurial Strategies 起業家的に戦う~戦略~

具体的に4つの形の戦略が書かれています。

  • Fustest with the Mostest 最速、最強の戦略
    • その市場の中でリーダーの地位を獲得することが目的。最も優れているが、最もギャンブル性が高い。
  • Hit Them Where They Aint't 不意を突く戦略
    • 敵がきづかないうちに攻めよ。創造的模倣戦略は、ほぼ完成している製品をより完全なものにし、市場で適切な場所に位置づける。起業家的な柔道戦略は、ほぼ完成していたビジネスの種を事業化して成功を収める戦略。最もリスクが低く、成功しやすい。
  • Finding and occupying a specialized "ecological niche" ニッチ狙いの戦略
    • ニッチ戦略は他者からの脅威にさらされることが少ない。料金所戦略、専門技術戦略、特殊マーケット戦略がある。
  • Changing the economic characteristics of a product, a market, or an industry 製品、市場、産業の経済的価値を変える戦略
    • 顧客を創造する戦略。紅葉を創り出す戦略、値づけ戦略、顧客側の社会的・経済的事情に適合する戦略、顧客にとって真に価値あるものを提供する戦略がある。

英語で読み解く ドラッカー『イノベーションと起業家精神』

英語で読み解く ドラッカー『イノベーションと起業家精神』

DDoS関連のCloudWatchメトリクス

AWSのDDoS対策ですが、これから検討している方はまず実際に攻撃されてるかをCloudWatchで確認することをお勧めします。

DDoS関連のCloudWatchメトリクスは、AWS上でのDDoS対策資料のp55に一覧があるのでメモしておきます。
AWS Solutions Architect ブログ: [AWS Black Belt Online Seminar] DDoS 対策 資料及びQA公開

名前空間 メトリクス 説明
CloudFront Requests HTTP/Sリクエスト数
CloudFront TotalErrorRate 全リクエスト中HTTPステータスコード4xx/5xxの割合
Route53 HealthCheckStatus ヘルスチェックエンドポイントのステータス
ELB SurgeGueueLength ロードバランサーでバックエンド応答を待っているリクエスト数
ELB UnHealthyHostCount AZ中のunhealthyなインスタンス
ELB RequestCount 登録インスタンスに転送した処理済みリクエスト数
ELB Latency ロードバランサーがリクエストを転送してから応答までの経過時間(秒
ELB BackendConnectionErrors 失敗したコネクション数
ELB SpilloverCount キュー飽和により拒否されたリクエスト数
AutoScaling GroupMAXSize オートスケーリンググループの最大サイズ
EC2 CPUUtilization CPU使用率
EC2 NetworkIn ネットワークインターフェースでの受信バイト数
DDoSProtection DDoSAttackBitsPerSecond DDoS攻撃の秒あたりビット数(0より大はDDoS攻撃検知)
DDoSProtection DDoSAttackRequestsPerSecond DDoS攻撃の秒あたりリクエスト数(0より大はDDoS攻撃検知)

DDoSProtectionsは「AWS Shield アドバンスド」のことです。

本番環境だけでなく、検証環境のリソースも確認しておきましょう。
自分の環境で確認してみたところ検証環境のELBのSurgeQueueLengthが単調増加していて、ログからアクセス元のIPを確認してみると外国からたくさん攻撃されてくることがわかりました。

私は検証環境だったので削除することで対応しましたが、本番環境の場合はWAFでIPをブロックするなどの検討が必要になります。

冒頭にも書きましたがまずは確認することをおすすめします。