ラベル AWS の投稿を表示しています。すべての投稿を表示

2015年4月18日土曜日

IAMロールを使ってEC2からS3のバケット一覧を取得してみた時のメモ

参考

EC2からS3へアクセスするIAMロールを作る

Roles
Create New Role
ロール名を決める(S3_Accessなど)
AWS Services RoleではAmazon EC2を選択
Attach PolicyではAmazonS3FullAccessを選択（一覧を取るだけなのでReadOnlyのものでもOK）
Create Role

EC2の起動

起動する時のIAM Roreの項目で先ほどのロールを選択(S3_Accessなど)

確認

以降、対象のEC2にSSHログインしてからの操作。

Rubyでやってみる。まずはAWS-SDKをインストール

$gem install aws-sdk-core

コードを書いてみる

$vi get_buckets.rb

以下のようにする。

require "aws-sdk-core"

Aws.config[:region] = 'ap-northeast-1'
s3 = Aws::S3::Client.new

resp = s3.list_buckets
puts resp.buckets.map(&:name)

実行

$ruby get_buckets.rb

これで取得できちゃいます。credentialsの設定とかを特にしなくて良いので楽。ドキュメントを見るとローカルのcredential情報を探した後になければIAMRoleの情報を探して使うようです。便利。

This code initializes an AWS::S3 object without specifying any credentials, which initiates a search for credentials using the default credential provider chain. The default credential provider chain looks for credentials specified in the environment, and failing that, will look for credentials from EC2’s metadata service.

また、メタデータ(curl http://169.254.169.254/latest/meta-data/iam/security-credentials/S3_Access)を直接取得すると分かるのですが、利用できるAccessKeyIdとSecretAccessKeyは一定周期でより変わるので、直接credentialファイルを置くよりもよりセキュアだと思います。

2015年4月16日木曜日

AWS-VPCピアリングを試してみた

VPCピア接続を行い、異なるVPC間でのSSH接続を確認した時のメモ

参考

前提

同一リージョン
アベイラビリティゾーンは違っても大丈夫
AWSアカウントが違っても大丈夫
IPアドレス帯域が重複することはNG。VPCに割り当たっているのが172.16.0.0/16と172.16.0.0/16だとNGダメ。同じように172.16.0.0/16と172.16.1.0/24でも重複する帯域があるのでNG

AWSでの設定

VPC Peeringの設定

上記がとても詳しく書いてありました。下記メモ。

異なるCIDRのVPCを作成。今回の場合、VPC-A(172.31.0.0/16)とVPC-B(10.0.0.0/16)のCIDRを持つVPCで検証。
VPCのPeering Connectionsを選択し、VPC-A側でVPC Peering Connectionを作成する。Local VPC to peerでは接続するVPC-Bを選択する。別のAWSアカウントを利用する場合、Account情報を入れる
上記実施後、VPC-B側でPeeringの承認をする
VPC-A,Bそれぞれでルーティング設定を行う

テストしてみる

準備ができたのでEC2を起動して、異なるVPC間でSSH接続ができるか確認します。

VPC-A,VPC-BにそれぞれEC2を起動します。どちらのEC2でもAuto-assign PublicIPの設定を行います。また、SecurityGroupでは22ポートでanywhere(0.0.0.0)からの接続を許可するようにします。
自分のPCからどちらにもSSH接続できることを確認します。
VPC-Bで新しくユーザーを作成します。EC2にSSH接続用のユーザーを作成するを実施。
VPC-Aにログイン。~/.ssh/id_rsaを上記でコピペしたid_rsaの内容に変更。その後、chmod 0600 ~/.ssh/id_rsaを行う。
ssh deploy@10.0.1.233としてSSHログインできるか確認。指定するVPC-Bに存在するEC2のプライベートIPの部分は読み替えてください。
VPC-B側のSecurityGroupでSSHのinboundを許可するIPをanywhere(0.0.0.0/0)からVPC-A側のプライベートIP(172.31.15.213/16)などに指定します。そうすることでVPC-B側へのSSHはVPC-Aのインスタンスを介してのみできるような設定とできます。

2015年2月7日土曜日

SES(Simple Email Service)の監視について確認した時のメモ

SESを使うときの監視について確認したのでメモ。

概要

SESでは以下については監視などしておくと良さそうです。

24時間以内の送信メール数と上限値
Bounce数
Complaint数

1は単純にそれを超えると送信ができなくなるため（上限値は徐々にあがるのを待つか別途申請が必要） 2,3もその割合が多すぎるとAWS側でメールサービスを停止することがあるからです。

具体的にどう監視するかという所で大きく分けて2つあるようです。

AWS CLI(SDK)を使って定期的に取得する
SESの配信通知を使う

1.AWS CLI(SDK)を使って定期的に取得する

AWS CLI(SDK)で監視すべき内容が取得できます（恐らくSDKでも取れると思います）

AWS CLI ses

具体的なオプションとしては「get-send-quota」および「get-send-statistics」が該当します。

get-send-quotaでは24時間以内のメール送信数の上限と現在の送信数が取得でき、get-send-statisticsでは2週間以内の15分ごとの送信状況（何通送って何通がBounceしたかComplaintになったか）などが取得できます。

なので例えば24時間以内のメール送信数と上限の割合を取得する場合、具体的に以下のコマンドでパーセンテージが取得できます。(動作確認済み)

上記を利用してAWSのCloudWatchと連携すると「上限数のhoge%を超えたらアラートメールを送る」などという事が可能です。

CloudWatchとの連携は以下サイトが参考になると思います。（ここで紹介されているPythonツールは個人でメンテナンスしているようでAmazonとしてno longer supportらしいのでSDKかCLIを使ったほうが良さそうです）

Amazon Simple Email Service (SES)の送信件数をCloudWatchのカスタムメトリクスで監視する

2.SESの配信通知を使う

SESで設定をしておけば、

Bounce
Complaint
Delive（正常に宛先に届いたか）

などの時にAWS-SNSを通じて通知が受け取れるようです。

【AWS発表】SESの配信通知

SNSではメール通知やHTTPによって通知などできるので監視やBounceやComplaint時の送信先宛先リストからの削除などが出来ると思います。

2014年12月29日月曜日

AWS SDK for Javaとpercolを使ってEC2のインスタンスにログインする

既にRubyだとやってる人がいて便利そうだったので、Groovy(Java)でも書いてみた。

gist

使うとき

~/.ssh/configにログイン対象のEC2のユーザー名、KeyPair、ホスト名を予め指定しておくこと
~/.aws/credentialsの設定をしておくこと。AWS CLIでconfigure設定をすればOKだと思われる。
groovy ec2list.groovy| percol | cut -f 3 | xargs -o -n 1 ssh
上記コマンドで対象のEC2にSSHログインできる
いちいちコマンドを打つのが面倒なので適当にalias設定をしておくととても便利

参考資料

2014年12月23日火曜日

AWSセキュリティメモ

書いていること

個人的に最低限、知っておいた方が良いと思うこと

アカウントの設定(IAM)
VPC
SecurityGroup

以下の資料に詳しく書いてあります。

AWSのセキュリティについて

書かないこと

アプリケーション上のセキュリティとか
これだけやればいいということではないです

1.アカウント設定

AWS利用時に作成されるアカウント（以降Rootアカウント)は何でも出来て権限が強すぎるのでなるべく使わないようにする
IAM(Identity and Access Management)を使って別途アカウントを作成して運用する

Rootアカウントはなるべく使わない

Rootアカウントのアクセスキーがあれば削除する。AWSはアクセスキーを使ってAPIを介した各サービスの操作が可能だが、Rootアカウントのアクセスキーは何でも出来てしまうので利用しない。
初期設定時にはRootアカウントはパスワードのみとなっているのでMFAを用いた2段階認証を利用する

MFA?

パスワードだけでなく、物理デバイスやソフトウェアを用いてワンタイムパスワードを発行し2段階認証を行う。詳しくはMulti-Factor Authenticationを参照
物理デバイスの場合、$12.99
ソフトウェア型の場合、AuthyやGoolge AuthenticatorなどがありiPhoneやAndoridで利用可能。AuthyはChromeアプリもある
AWSアカウント作ったらこれだけはやっとけ！IAMユーザーとAuthyを使ったMFAで2段階認証

IAM(Identitiy and Access Management)

Rootアカウントとは別に個別にアカウントを作成する事ができるのがIAM
基本的にはIAMで作った個別アカウントのみを使うようにする
権限を細かく設定することができる(S3のReadOnlyユーザーなど)
IAM Groupを使うとグループごとに権限を設定できる
個別のアカウントにもMFAが利用できるので特に権限レベルが強いものはMFAをかけておくとより安全

2.VPC(Virtual Private Cloud)

AWSはパブリッククラウドだが、AWS内にプライベートネットワークを構築する事ができる
VPC内でサブネットを区切ることもできる。VPC領域を192.168.0.0/16とし、その中に192.168.0.1/24と192.168.2.0という別のサブネットを作ることもできる
AWS Direct Connectでの専用線接続やインターネットVPNを利用することで直接AWSのVPCにアクセスすることも可能(やったことはない)

3層(Web,AP,DB)モデルの場合

Amazon Web Services 基礎からのネットワーク&サーバー構築が詳しい。一度これ見て組んでみることを推奨
Webサーバーはインターネットと接続が可能なサブネット内に配置し、APサーバーやDBサーバーは内部のみと通信可能なサブネットとすることでセキュリティを高める
APサーバーなどのプライベートネットワークからインターネットへ接続する(OSアップデートなど)の場合にはNATを起動して接続する。NATのAMI(AmazonMachineImage)を利用することで簡単に構築できる

3.SecurityGroup

InboundとOutboundのファイアウォールの設定が可能
名称の指定も出来るのでGroupNameに予めWeb、APなど作っておいてルールを設定しておくと良い
書いてない設定はDenyされるので許可させたいネットワークを書く
デフォルトでは22ポート(SSH)がどこからでも接続できるできるポリシーが適用されるので固定IPに変更する。
HTTP、HTTPSなどの場合でも極力どこからでも接続できることを意味する0.0.0.0/0やanywhereは指定せず固定IPなどの指定を推奨

2014年6月27日金曜日

[AWS]EC2のロードバランサを設定した時のメモ

ドットインストールのAmazon Web Services入門を参考にロードバランサの設定をした時のメモ

EC2のインスタンスの準備

EC2のインスタンスを作成する
適用させるSecurity Groupsで22と80ポートを解放する。
sshログインしてnginxなどのWebサーバーを起動させる
Webサイトにアクセス出来る事を確認

AMI(Amazon Machine Image)の作成

作成したインスタンスを複製するのためにAMIを作成
作成までは少し時間が必要
sshログイン、Webサイトにアクセス出来る事を確認

ロードバランサの作成

作成時に80ポートを転送するように設定
作成した二つのインスタンスを適用
作成後表示されるDNS NameのURLにアクセス(自分の場合、作成後すぐにアクセスするとエラーとなってしまった。数分後、アクセスすると問題なくサイトが表示された)
アクセスログを確認し、それぞれのインスタンスにアクセスが出来ていることを確認

2014年6月24日火曜日

[AWS]EC2及びローカル環境からRDSのMySQLに接続した時のメモ

EC2及びローカル環境からRDSのMySQLに接続した時のメモなお、予めEC2は起動済みでSSH接続出来る事が前提。

EC2からRDSへの接続

RDSを以下の内容で作成する。

Public AccessibleはNOにする
EC2と同じSecurityGroupを設定する。

RDS作成後、以下の情報をメモしておく。

エンドポイント(例:dbtest.hogefuga.ap-northeast–1.rds.amazonaws.comなど）
ポート（例:3306）
DBユーザー名（例:dbuser)
DBパスワード

次に設定したSecurityGroupのInboundを確認する。もし、DBのポート(上記の場合3306)の設定がされていない場合、以下のように同じSecurityGroup間の3306ポートの接続は可能なように設定する。

設定後、EC2にSSH接続し、以下のようなコマンドを実行。

$mysql -h dbtest.hogefuga.ap-northeast-1.rds.amazonaws.com -P 3306 -u dbuser -p

パスワードが聞かれるので入力すればRDSのmysqlへの接続が出来る。

ローカルマシンからRDSへの接続

Public AccessibleはYESにする
SecurityGroupの設定でRDSに割り当てているもののInboundにアクセス元のローカルのグローバルIPとDBのポートによる接続許可のルールを追加する。（自分は確認の為にアクセス元を0.0.0.0/0にしましたが、セキュリティ的に通常設定すべきではありません）

ローカルマシンからEC2と同様にmysqlコマンドで接続が可能である。

2014年6月5日木曜日

[chef]test-kitchenのテストをAWSのEC2で実施する

前回のブログでJenkinsのレシピを作成し、Vagrantを利用してローカル環境のVMでtest-kitchenを利用してserverspecのテストを実行するようにしました。

今回、kitchen-ec2を使ってその環境をローカルでなく、AWSのEC2を利用してテストするようにします。

参考

Chefのテストツール kitchen-ec2を使う – 導入、チュートリアル

test-kitchen/kitchen-ec2

前提

AWSのアカウントがあること
AWS のアクセスキー/シークレットアクセスキーが存在すること。
EC2のキーペアを作成済みである事
VagrantやChefなどがインストール済みである事

環境の準備

必要なものをインストールします。

$gem install test-kitchen
$gem install kitchen-ec2

対象レシピのディレクトリに移動し、.kitchen.ymlを変更します。既に.kitchen.ymlが存在する場合には上書きするかの確認が表示されますが、必要に応じてバックアップを取得しておいてください。

$cd {repo_dir}
$kitchen init --driver=kitchen-ec2

.kitchen.ymlの編集

.kitchen.ymlを編集します。

---
driver:
  name: ec2
  aws_access_key_id: <%= ENV['AWS_ACCESS_KEY'] %>
  aws_secret_access_key: <%= ENV['AWS_SECRET_KEY'] %>
  aws_ssh_key_id: <%= ENV['AWS_SSH_KEY_ID'] %>
  ssh_key: <%= ENV['SSH_KEY'] %>
  security_group_ids: ["Vagrant"]
  region: ap-northeast-1
  availability_zone: ap-northeast-1a
  require_chef_omnibus: true

provisioner:
  name: chef_solo

platforms:
  - name: ubuntu-12.04
    driver:
      image_id: ami-0596ef04
      username: ubuntu
      flavor_id: t1.micro
  - name: centos-6.4
    driver:
      image_id: ami-99fa7098
      username: root
      flavor_id: t1.micro

suites:
  - name: default
    run_list:
      - recipe[jenkins::default]
    attributes:

ポイントだけ記載します。

aws_access_key_id:AWSのアクセスキー
aws_secret_access_key:AWSのシークレットアクセスキー
aws_ssh_key_id:キーペアの名称
ssh_key:キーペア(pem)のファイルパス
security_group_ids:設定するセキュリティグループ

詳細は test-kitchen/kitchen-ec2を確認ください。

上記のように環境変数から読み込む設定の場合、~/.bashrcなどに以下のように記載します。

export AWS_ACCESS_KEY="xxx"
export AWS_SECRET_KEY="xxxxxxxx" 
export AWS_SSH_KEY_ID="hogeKeyPair" 
export SSH_KEY="~/.ssh/hogeKeyPair.pem"

image_idについては自分で作成したAMIでも大丈夫ですし、aws marketplaceのものも利用出来るようです。

aws marketplaceのものを利用する場合、利用承諾をしていないとインスタンス起動時にエラーとなります。その場合には、利用承諾用URLが表示されるのでリンクがエラー文に表示されるのでそこから利用承諾を行うと以降の起動が成功します。

テストの実行

テストの実行は以下のコマンドで可能です。

$kitchen test

上記で

インスタンスの作成
AWSへのChefのインストール、レシピの適用
テストの実行
インスタンスの削除

をplatformsに書かれたOSの数分実行されます。

それぞれを個別にやるには

kitchen create
kitchen coverage
kitche verify
kitchen destroy

というコマンドが対応しています。

インスタンスの各状態はkitchen listコマンドで確認が出来ます。

登録: 投稿 (Atom)