ALB(Application Load Balancer)でWebサービスを冗長化する

概要

ALBを使ってアプリケーションを冗長化する手順です。

HTTPS接続でアプリケーションにアクセス出来るところまでをこの記事で紹介します。

前提条件

以下の事前条件が必要です。

  • VPCの作成を行っておく
  • 最低でも2台のWebサーバインスタンスを起動させておく事
  • ロードバランサー用サブネットの作成が行われている事(後で説明します。)

事前準備その1(ロードバランサー用サブネットの作成)

以下は公式サイトに書かれている内容です。

ロードバランサーのアベイラビリティーゾーンを指定します。ロードバランサーは、これらのアベイラビリティーゾーンにのみトラフィックをルーティングします。アベイラビリティーゾーンごとに 1 つだけサブネットを指定できます。ロードバランサーの可用性を高めるには、2 つ以上のアベイラビリティーゾーンからサブネットを指定する必要があります。

今回検証で利用している東京リージョンには ap-northeast-1aap-northeast-1c の2つのアベイラビリティーゾーンが存在するので、それぞれでサブネットの作成を行います。

サービス → VPC → サブネット → 「サブネットの作成」より作成を行います。

ap-northeast-1a で サブネットを作成します。
以下のように入力を行います。

  • ネームタグ

    • account_api_alb_1a
    • 開発環境アカウント用APIのALB用と分かる名前を付けています。分かりやすい名前であれば何でも構いません。
  • VPC

    • 利用対象となるVPCを選択します。
  • IPv4 CIRD block

    • 192.0.30.0/24
    • ネットワークの設計方針にもよりますが今回は 192.0.30.0/24 を割り当てます。

alb_subnet_step1.png

続いて ap-northeast-1c でも同じ要領でサブネットを作成します。
※先程とほとんど同じなので、入力内容に関しての詳細は省略します。

alb_subnet_step2.png

事前準備その2(SSLの証明書の用意)

SSLで接続を可能にするのでSSL証明書の用意が必要です。

今回は検証なので自己証明書を利用する事にします。

以前、LAMP 環境構築 PHP 7 MySQL 5.7(前編) という記事を書きました。

こちらに載っている手順を参考に自己証明書を用意します。

ALB(Application Load Balancer)の新規作成

ここからが本題になります。
サービス → EC2 → ロードバランサー → ロードバランサーの作成 を選択します。

alb_step1.png

Step1 ロードバランサーの設定

基本的な設定を行っていきます。
名前を入力します。(今回はaccount-api-alb)という名前を付けました。

インターネットに公開するサービスを想定しているので、スキーマは「インターネット向け」を選択します。

ロードバランサーのプロトコルにHTTPSを追加します。

alb_step2-1.png

アベイラビリティーゾーンに先程作成したサブネットを割り当てます。

alb_step2-2.png

Step2 セキュリティ設定の構成

SSL証明書の設定を行います。

alb_step2-3.png

証明書の名前は分かりやすい名前でOKです。

プライベートキーには事前準備で作成した、プライベートキーを入れます。
-----BEGIN RSA PRIVATE KEY----- から -----END RSA PRIVATE KEY----- までを全てコピーして下さい。

パブリックキー証明書には -----BEGIN CERTIFICATE----- から -----END CERTIFICATE----- までの内容を全てコピーして下さい。

セキュリティポリシーは ELBSecurityPolicy-2016-08 を選択します。

※2017-05-22 現在、この手順で問題なく証明書の追加が出来るハズなのですが Certificate not found というエラーが発生しロードバランサーの作成に失敗してしまいます。

証明書のアップロードを aws-cli を使って事前に実施するようにしたら上手く行きました。

証明書のアップロード
aws iam upload-server-certificate --server-certificate-name self-certificate --certificate-body file://crt.crt --private-key file://private.key

file:// を付けるのがポイントです。これがないと上手くアップロード出来ませんでした。

--server-certificate-name には任意の名前を入力して下さい。

上手く行くと下記のようなレスポンスが返ってきます。

証明書アップロードのレスポンス
{
    "ServerCertificateMetadata": {
        "ServerCertificateId": "XXXXXXXXXXXXXXXXXXXXX",
        "ServerCertificateName": "self-certificate",
        "Expiration": "2018-05-22T04:14:02Z",
        "Path": "/",
        "Arn": "arn:aws:iam::999999999999:server-certificate/self-certificate",
        "UploadDate": "2017-05-22T05:58:44.754Z"
    }
}

アップロード完了後に「AWS Identity and Access Management(IAM)から、既存の証明書を選択する」を選んで先程アップロードした証明書を選択して下さい。

alb_step2-3.1.png

この問題については 既存の ELB に SSL 証明書を追加しようとすると Server Certificate not found for the key というエラーになる件の解決方法 を参考にさせて頂きました。

Step3 セキュリティグループの設定

セキュリティグループの設定を行います。

alb_step2-4.png

Step4 ルーティングの設定

ターゲットグループの新規作成を行います。

alb_step2-5.png

名前、プロトコル、ヘルスチェック用のURLの設定等を行います。

Step5 ターゲットの登録

ロードバランサーの配下で起動するインスタンスを選択します。

alb_step2-6.png

作成に必要な情報入力は以上となります。

確認画面に進み作成を行いしばらくすると、ロードバランサーが作成され利用可能な状態となります。

※サービス → EC2 → ロードバランサー より確認が出来ます。

alb_step3.png

動作確認

サービス → EC2 → ロードバランサー よりDNSが確認出来るので、動作確認を行います。

curl -kv https://account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com/
*   Trying 0.0.0.0...
* TCP_NODELAY set
* Connected to account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com (0.0.0.0) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate: system
> GET / HTTP/1.1
> Host: account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Date: Mon, 22 May 2017 07:26:02 GMT
< Content-Type: application/json
< Transfer-Encoding: chunked
< Connection: keep-alive
< Server: nginx/1.12.0
< X-Request-Id: 76c7e41f-1a4e-4328-972c-b98055e84395
< Cache-Control: no-cache, private
<
* Curl_http_done: called premature == 0
* Connection #0 to host account-api-alb-000000000.ap-northeast-1.elb.amazonaws.com left intact
{"code":404,"message":"Not Found"}

各Webサーバのログを確認すると、処理が振り分けられているのが、確認出来ます。

本番環境での運用に向けて

ここまで簡単に作成が出来ましたが実環境で運用を行うにはまだまだ考慮が必要な点が多いです。

  • SSL証明書を正式な物にする(自己証明書で運用とかはさすがに厳しいと思います)
  • 独自ドメインでのアクセスを可能にする
  • 各EC2のログに記載されているIPがロードバランサーの物になっている

※これらの手順は順次行っていく予定ですので、準備が出来次第記事を書く予定です。

最後まで読んで頂きありがとうございました。

続きを読む

aws周りのメモ2

postgresqlを使う

RDSへpostgresqlをいれて立ち上げ

認証と接続

import-key-pair — AWS CLI 1.11.87 Command Reference
http://docs.aws.amazon.com/cli/latest/reference/ec2/import-key-pair.html

cd $HOGE
openssl genrsa -out my-key.pem 2048
openssl rsa -in my-key.pem -pubout > my-key.pub
# IAMのコンパネで*.pubを入力
# 多分、権限があれば以下でもいける
# aws iam upload-ssh-public-key

【AWS 再入門】EC2 + RDS によるミニマム構成なサーバー環境を構築してみよう – NET BIZ DIV. TECH BLOG
https://tech.recruit-mp.co.jp/infrastructure/retry-aws-minimum-vpc-server-environment/

便利

無料枠

無料のクラウドサービス | AWS 無料利用枠
https://aws.amazon.com/jp/free/

AMI

AWS Marketplace: Search Results
https://aws.amazon.com/marketplace/search/results?x=14&y=18&searchTerms=&page=1&ref_=nav_search_box

CFテンプレート

サンプルコード & テンプレート – AWS CloudFormation | AWS
https://aws.amazon.com/jp/cloudformation/aws-cloudformation-templates/

ec2 ami tool & ec2 api tool

Mac で Amazon EC2 API Toolsを設定する – サーバーワークスエンジニアブログ
http://blog.serverworks.co.jp/tech/2013/01/31/mac-amazon-ec2-api-tools-setup/

ec2 api toolは若干心配。

VPCを使う

接続の際に、sshを経由したい。sslでもいいけどなんかsshがいいなと。
パスワードよりkeyのほうがセキュアだからかな。

0から始めるAWS入門①:VPC編 – Qiita
http://qiita.com/hiroshik1985/items/9de2dd02c9c2f6911f3b

導入

Amazon VPC とは? – Amazon Virtual Private Cloud
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Introduction.html

公式のいろいろ

料金 – Amazon VPC | AWS
https://aws.amazon.com/jp/vpc/pricing/

基本は無料だけどNATとVPNは別課金。

【AWS 再入門】VPC 環境に踏み台サーバーを構築して SSH 接続してみよう – NET BIZ DIV. TECH BLOG
https://tech.recruit-mp.co.jp/infrastructure/retry-aws-bastion-host-vpc/#i-3

ec2(Bastion)を配置する必要がありそう。

【AWS 再入門】EC2 + RDS によるミニマム構成なサーバー環境を構築してみよう – NET BIZ DIV. TECH BLOG
https://tech.recruit-mp.co.jp/infrastructure/retry-aws-minimum-vpc-server-environment/

VPC に推奨されるネットワーク ACL ルール – Amazon Virtual Private Cloud
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Appendix_NACLs.html

vpcでのネットワークのポリシーの例

Default VPC

AWSのDefault VPCを削除して困った話 – MikeTOKYO Developers
http://blog.miketokyo.com/post/49939300091/aws-default-vpc

デフォルトvpcは削除したらダメか。使い分けがわからん。

Amazon EC2 と Amazon Virtual Private Cloud – Amazon Elastic Compute Cloud
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-vpc.html

基本の機能はデフォルトとそうじゃないvpcは同じだけど、
デフォルトvpcがないとちゃんと機能しない。
デフォルトの属性によって、指定がないとipを紐付けたりする。

VPCネットワーク設計

これだけ押さえておけば大丈夫!Webサービス向けVPCネットワークの設計指針 | eureka tech blog
https://developers.eure.jp/tech/vpc_networking/

ネットワークは一度稼働させると移行が大変なので、初期設計が非常に重要になります。

わかりやすい。図が特に。

  • Bastion
  • NAT
  • Security Group

ENI

インフラエンジニアに贈るAmazon VPC入門 | シリーズ | Developers.IO
http://dev.classmethod.jp/series/vpcfor-infra-engineer/

サブネットで指定したIPアドレスのうち、先頭4つと末尾の1つはVPCで予約されるため使用できません。

VPCでは常にDHCP有効とするのがポイントです。

また、DHCPサービスで伝えられる情報(DHCPオプション)は、変更することもできます。

仮想マシンにひもづくENIにより、DHCPサーバーから毎回同じMACアドレス、IPアドレスが付与されます。これは、仮想マシンの状態に依存しないため、仮想マシンを再起動しようと、一旦シャットダウンしてしばらくしてから起動した場合でも必ず同じアドレスが付与されます。

ENI(Elastic Network Interface)か。。なるほど。でも、使うことはなさそうだな。

NAT

IPマスカレードが使えないVPC
NATは、Static(静的・サーバー用途)とElastic(仮想・クライアント用途)がある。
個人的には、このNATインスタンスの実装は、あまり好きではありません。動きがややこしいですし、ユーザーが自分でNATインスタンスの管理をしなければならないのも煩雑な印象を受けます。VPCのネットワークサービスの一つとして提供される機能であれば、ユーザーからはなるべく抽象化され仮想マシンとして意識されないようにするべきと考えます。
ただ、ユーザーから仮想マシンとして見える分、機能・実装が具体的に把握できる点やカスタマイズ性が高い点は良いとも思っています。

NAT インスタンスと NAT ゲートウェイの比較 – Amazon Virtual Private Cloud
http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-nat-comparison.html

なるほど。。

Bastion

AWSで最低限セキュアな構成を組む – Qiita
http://qiita.com/ausuited/items/09b626fa5264f0c650fd

パブリックSubnetにEC2インスタンス(踏み台サーバーとして)
NATインスタンスを作成した要領で、パブリックSubnetにEC2インスタンスを作成する。Security groupは新規に作成してSSHをAnywhereに。Key pairは厳重に管理。尚、踏み台サーバーは、使用する時以外はStoppedにしておく事で、さらにセキュアな状態とする。このデザインパターンをOn Demand Bastionパターンと呼ぶらしい。

詳しい。「On Demand Bastionパターン」か。なるほど。

vpcへの踏み台サーバー
ポートフォワーディング、トンネルなどと同じ意味。

Network ACL

インスタンス単位じゃなくサブネット単位でより制限してセキュアにしたい場合に使うのかな。

安全なVPC設計 — Commerce Hack
http://tech.degica.com/ja/2016/01/07/designing-vpc-and-subnets/


結局どうするのか、、ひとまずNATはつかわずに、Bistionをつくってみる感じかな。

アベイラビリティーゾーン

リージョンごとでの、障害などで全部やられないように物理的にセグメントされた範囲の単位かな。
RDSではセグメントグループに2つ以上のゾーンを含める。でも、一つしか使わなくていい。ということか。s

RDSのVPC間の移動

サブネットグループの関連付けを変えればいいらしい。間違って設定したので移動した。

【小ネタ】知っていましたか?RDSを別のVPCに移動できることを | Developers.IO
http://dev.classmethod.jp/cloud/aws/rds_can_move_to_another_vpc/

Bastion作成作業をしてみる

主に下記を参考。

【AWS 再入門】EC2 + RDS によるミニマム構成なサーバー環境を構築してみよう – NET BIZ DIV. TECH BLOG
https://tech.recruit-mp.co.jp/infrastructure/retry-aws-minimum-vpc-server-environment/

  • サブネットってなんだっけとか復習。
  • ストレージはどうするのか。
    • とりあえずssdにしたけどマグネティックでよかったかなあ。

      • ssd:$0.12 : 1 か月にプロビジョニングされたストレージ 1 GB あたり
      • マグネティック: 0.05 USD/GB-月
  • public IPは設定必要だよね
  • market placeからamiを取得した方がいいの?
    • とりあえず公式のウィザードを使ったけど。
  • 認証にIAMが追加されていたので使ってみた
    • これとは別にキーペアは必要ってことかな。
  • CFnテンプレート(CloudFormationテンプレート)というのがあるらしい。。
    • これでつくりなおそうかな。。
  • サブネットとかいろいろネットワーク系の設定
    • なんだかんだいっていろいろあった
  • セキュリティグループ
    • エイリアスみたいなセキュリティグループにできたらいいのに。タグや名前で明示化かな。
    • bastionは22をあけて、rdsは5432をbastionからのみあける
  • ログイン
  • DNS
    • あれ、パブリックDNSがうまく割り振ってないな。。
      AWSでPublic DNS(パブリックDNS)が割り当てられない時の解決法 – Qiita
      http://qiita.com/sunadoridotnet/items/4ea689ce9f206e78a523
    • RDSのDNS
      • nslookupしたら内部ipがかえってくるのね。接続できないけどなんか気持ち悪いな。これかな。。
        外部からdnsを引けることを気にしている人は見かけなくて便利だからって話なのかね。
        【AWS】VPC内でPrivate DNSによる名前解決 – Qiita
        http://qiita.com/y_takeshita/items/2eb5e6abb5eb5516d1de

やってるうちはいいけど、しばらくやらないと設定の方法とか忘れそう。。こういうのは学習コストだけじゃないな。

PlantUMLで図にしておく

Kobito.hQIwJs.png

VPC内のRDSへLambdaから接続。。

しまった!アンチパターンだそうだ。。

Lambda+RDSはアンチパターン – Qiita
http://qiita.com/teradonburi/items/86400ea82a65699672ad

Lambda + RDS benchmark – Qiita
http://qiita.com/taruhachi/items/3f95ae3e84f56edb3787

新し目の記事でIAM認証でクリアできそうな。。

【全世界待望】Public AccessのRDSへIAM認証(+ SSL)で安全にLambda Pythonから接続する – サーバーワークスエンジニアブログ
https://blog.serverworks.co.jp/tech/2017/04/27/rds-iam-auth-lambda-python/


セキュアに接続するのと速度のトレードオフになっていたのが
IAM認証のおかげで両方可能になったということっぽい。
でも、ネットのスループット、コネクション数(料金・負荷)、など、、ほかにも気にすることが出て来そうで若干不安。
非同期でよければキューイングして一回投げっぱなしすればどうだろう。
もしくは、似てるけど、Lambdaから一回値を返してもらってからRDSへ投げ直す。
これでいっかなあ。。Lambdaの意味がなくなる?うーん。

今後

  • 疑問としてrdsなど内部向けのdnsを外から見れなくできないものか。
  • というか、rdsのエンドポイントって再起動したら変わったりしないかね。ipは固定されるのか。
    • たぶん、サブネット内でdhcpになるのでipは変動するけどエンドポイントは固定。。じゃないかしら。

posgresqlをつかうための情報

Amazon RDS 上の PostgreSQL – Amazon Relational Database Service
http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html#PostgreSQL.Concepts.General.SSL

続きを読む

IAM認証RDS�・非VPC Lambda・API Gateway・CloudFront・WAFで接続元IP制限付きAPIを作成する

主に以下2例に対して情報を少し追加するだけの記事です。

API GatewayのバックをVPC Lambdaにしている場合、APIのくせに返答に時間がかかる場合がある、という問題があります。なので、

  • 非VPC Lambdaから安全にPublic AccessibleなRDSに接続したい
  • かつ、API Gatewayに接続元IP制限をつけたい

というのがやりたいことです。

RDS接続認証でIAMが使えるようになった

執筆時点で公式日本語ドキュメントは無し。

つまりどういうこと?

MySQLの認証プラグインを作ったからRDSイメージにいれておいたよー、という話らしいので見てみる。

select * from plugin;
+-------------------------+-------------+
| name                    | dl          |
+-------------------------+-------------+
| AWSAuthenticationPlugin | aws_auth.so |
+-------------------------+-------------+
1 row in set (0.01 sec)

同じものをPostgreSQLでも作ってくれればPostgreSQLでもIAM認証が使える用になるんですよね? (よく知らないまま希望)

それのなにがうれしいの?

MySQLのuser/password認証がAWS_ACCESS_KEY_IDとAWS_ACCESS_SECRET_KEYに置き換わったような感じです。

……って言っちゃうと「それはそう」案件になるんですが、特定のIAMロールを持つ非VPC Lambdaからのみのアクセスを許可するようなRDS MySQLを作ることができる、というのが特にうれしい点です。

MySQL組み込みの認証機構よりは比較的安全な方法で、RDSをPublic Accessibleにできるようになる、とも言います。RDSがPublic Accessibleなら、Lambdaも非VPCでよくなります。しかもそのLambdaも特定のIAMロールを持つものだけに制限できます。安心だ。

やりたいこと

RDS (IAM & SSL) | AWS Lambda (IAM) | API Gateway (https) | CloudFront (https) | Web Application Firewall

rds-iam.png

の構成を作りたい。社内APIとかですな。なんか登場人物が多いですが、以下の事情があります

  • ソースIP制限をつけたいが、API Gateway自体にソースIP制限機能がない
  • WAFにはあるが、WAFはALBかCloudFrontにしか使えない

よって、

  • CloudFrontをAPI Gatewayの前段に置く
  • WAFをCloudFrontの前段に置く

ことでアクセスをコントロールします。

API Gateway自体に関しては、API Tokenを必須にすることでアクセスを制限します。もちろんCloudFrontからはアクセスできないといけないので、Origin設定でAPI Tokenをヘッダに追加する必要があります。ややこしいなおい。

ちなみに、API Gatewayの認証をIAMにすることもできるんですが、これだとAPIユーザーにAWS v4 Signature Authを実装させることになるので心苦しいです。

うっわめんどくさっ。

やってみよう

RDSをつくる

IAM Database Authentication for MySQL and Amazon Aurora

IAM認証はdb.m1.smallより大きいインスタンスのみでしか使えないので注意。ユーザーの作り方もドキュメントのままですが、

CREATE USER jane_doe IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS' REQUIRE SSL;

DBとLambda間はSSLにしないといけないので、REQUIRE SSLオプションを付けてSSLを強制します。

Lambdaのレンジ:3306のInをAllowしたSecGroupを作る、つってもLambdaのレンジってめっちゃ広そう?
https://docs.aws.amazon.com/ja_jp/general/latest/gr/aws-ip-ranges.html

Lambdaをつくる

試しに作ったLambdaは

from __future__ import print_function

import os

import boto3
import mysql.connector

def lambda_handler(event, context):
    print(event, context)
    token = boto3.client('rds').generate_db_auth_token(
        DBHostname=os.environ['RDS_HOST'],
        Port=3306,
        DBUsername=os.environ['RDS_USER']
    )
    conn = mysql.connector.connect(
        host=os.environ['RDS_HOST'],
        user=os.environ['RDS_USER'],
        password=token,
        database=os.environ['RDS_DATABASE'],
        ssl_verify_cert=True,
        ssl_ca='rds-combined-ca-bundle.pem'
    )
    cursor = conn.cursor()
    cursor.execute('SELECT user FROM mysql.user')
    rows = cursor.fetchall()
    result = [str(x[0]) for x in rows]
    return {'users': result}

DBのユーザーをSELECTして返すだけのものです。

Lambda実行時のIAMロールにIAM Database Authポリシーが必要になります。

Attaching an IAM Policy Account to an IAM User or Role

arn:aws:rds-db:region:account-id:dbuser:dbi-resource-id/database-user-name

ここでMySQLのGRANTONTOを指定しているみたいなものと考える。

別のIAMロールを付けてLambdaを実行してみると、みごとにDB接続エラーが発生する。

Lambdaをzipでまとめる

Dockerfileを作ってzipを生成するナウでヤングな最先端のイカしたアレだぜ。デプロイ時に非VPCを選択。

FROM amazonlinux

RUN yum install -y python27-devel python27-pip zip
RUN pip install --upgrade pip
RUN mkdir /opt/rds-iam-auth /opt/build
COPY ./ /opt/rds-iam-auth/
WORKDIR /opt/rds-iam-auth
RUN pip install wheel
RUN pip install -r requirements.txt -t .
RUN zip -r rds-iam-auth.zip *

CMD cp rds-iam-auth.zip /opt/build

悲しいかなLambdaのamazonlinuxに入っているboto3がIAM RDS authに未対応 (執筆時) だったのでrequirement.txtに追記。近々AMIもアップデートされるだろう。

その他をつくる

コンソールからぽちぽちやる作業がたくさんあります。特にここで追記することはないので、先人の記事を参照したいところだ。

注意点まとめ

  • APIエンドポイントを直接使用されないように、API Tokenを必須にしておくこと。
  • WAFはGlobalリージョンで作成しないとCloudFrontのコンソールから選べないので注意。
  • CloudFrontのOrigin設定時に、x-api-tokenヘッダ転送設定を追加すること。
  • CloudFrontの設定反映には時間がかかるの辛いコーヒー飲むしかない。

ためす

WAFで社内のGlobal IPのみアクセスを許可。

$ curl https://hoge.cloudfront.net/
{"users": ["helloworld", "iamuser1", "mysql.sys", "rdsadmin"]}

WiFi変えたりとかして、Global IPを変えてみると

$ curl https://hoge.cloudfront.net/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Request blocked.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: jIG5TSJUn9rPZYI0JwUr9wZHFHFa_LRyVmwGC302sHjBgv0sLoPubA==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>

Forbiddenされる。

まとめ

AWSよくできてんなー。

続きを読む

AMIMOTO AMIを使ってAWSにWordPressをインストールする

2016年の春頃に書いてた下書きが出てきたのでとりあえず投稿する。

  • AMIMOTO HHVM AMIを選んでインスタンスを起動
  • 10分ぐらい待つ
  • Elastic IPを紐付ける
  • Elastic IPのアドレスにアクセス
  • インスタンスIDを入力してWordPressをインストール
  • Route 53から独自ドメインのAアドレスをElastic IPに設定 参考
  • SSHでインスタンスに接続$ ssh -i ec2.pem ec2-user@[Elastic IP]
  • $ sudo yum update
  • SFTPで接続してファイルを操作できるように$ curl -L https://raw.githubusercontent.com/amimoto-ami/run-httpd-as-ec2-user/master/run-httpd-as-ec2-user.sh | sudo bashを実行
  • TransmitでSFTPを設定。サーバ:Elastic IP、ユーザ名:ec2-user、パスワード:ec2.pem、リモートパス:/var/www/vhosts/[インスタンスID]/

SSLを設定

  • $ sudo openssl genrsa -des3 -out ./ssl.newpeace.vision.key 2048で鍵を生成
  • $ sudo openssl rsa -in /etc/nginx/ssl.newpeace.vision.key -out /etc/nginx/ssl.newpeace.vision.keyでパスフレーズを解除
  • $ sudo openssl req -new -key ./ssl.newpeace.vision.key -out ./ssl.newpeace.vision.csrで鍵を生成
  • 参考
  • ssl.globalsign.com.csrの内容を申請フォームに入力
  • SSL証明書を取得
  • SSL証明書をインストール
  • $ sudo vi /etc/nginx/ssl.newpeace.vision.crtで「証明書 SHA256」の内容をコピー
  • $ sudo vi /etc/nginx/dvcacert.cerで「中間CA証明書」の内容をコピー
  • $ sudo cat ssl.newpeace.vision.crt dvcacert.cer > ssl.newpeace.vision.pemで「証明書 SHA256」と「中間CA証明書」を結合(これできない。。)
  • $ sudo chmod -R 777 /etc/nginx/conf.d/でNGINXの設定ファイルに書き込み権限を付与
  • /etc/nginx/conf.d/ssl.default.confを作成して、
/etc/nginx/conf.d/ssl.default.conf
server {
    listen      443 default spdy ssl;
    server_name _;
    root        /var/www/vhosts/i-c3880266;
    index       index.html index.htm;
    charset     utf-8;

    ssl                       on;
    ssl_certificate           /etc/nginx/ssl.newpeace.vision.pem;
    ssl_certificate_key       /etc/nginx/ssl.newpeace.vision.key;
    ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers               HIGH:!aNULL:!MD5;

を書く。

default.confcharset utf-8;の下にreturn 301 https://$host$request_uri;を追記

続きを読む

AWSでMastodonインスタンスを作るまで。自分まとめ

だいたいネットのチュートリアル通り

http://webfood.info/mastodon-aws-tutorial/
だいたいこの通りにやると構築できます(終了)

とするのも寂しいので、自分の環境で再現できるように、手順と詰まりやすい所を残しておきますね。

1.VPCを作る Virtual Private Cloud

A. まず、AWSから借りるサーバーをひとまとめにする仮想イントラネット、VPCを作ります。

image.png

この時、CIDR ブロックは XX.0.0.0/16をお勧めします。
ウィザード通りで大丈夫かと
image.png

↓ここからはVPCでトラブった時の雑学 CIDR ブロックについて若干おさらい。

VPCってなんだっけ。情報の授業のおさらい

VPCはAWSの仮想イントラネットです。VPCはサブネットマスクを使って自身のネットワーク内に
あるサーバーや更なるサブネットのアドレスを割り当てます。

こんな感じ、0が自分のネットワーク内で使えるアドレス

XX.0.0.0.0/24のサブネットマスク
11111111.11111111.11111111.00000000
0の数が8つ
2^8 = 256 のIPを割り振る事ができる。

XX.0.0.0.0/16のサブネットマスク
11111111.11111111.00000000.00000000
0の数が8つ
2^16 = 65536 のIPを割り振る事ができる。
これが分かってないと時々サブネットが作れず詰みになったりします。

情報の授業終わり

パブリックサブネットを作る

外部からSSH接続できるように仮想ルーターを配置します。
VPCの作成ウィザードで作成されてると思いますが、作られてなかったら、

A’ VPCダッシュボードからインターネットゲートウェイインターネットゲートウェイの作成で仮想ルーターを作ります。

仮想ルーターが出来たら、VPCにアタッチで作成したVPCとルーターを繋ぎます。
これで仮想ネットワークがインターネットに接続されました。

ですが、まだルーターがあるだけです。どのサブネットを作り、ルーターと接続します。
B’ サブネットの作成をクリックして先ほど作ったVPCにサブネットを作ります。
サブネットに割り当てるCIDRはXX.0.0.0.0/24がおすすめ

そして作成したサブネットをチェックし、ルートテーブルタブをクリック。
現在のルートテーブルを編集し、サブネットとインターネットゲートウェイをつなぎます。
image.png

rtb-XXXXXXXをクリックして編集します。

image.png

ルートタブから別ルートの追加 送信先を0.0.0.0/0 ターゲットをigw-XXXXXX(先ほど作成したインターネットゲートウェイのID)
を指定します。
これで、このサブネットにある仮想コンピューターはすべてインターネットからアクセスできるようになりました。
↑ここまで、VPCでトラブるケース。

2.インスタンスを作る。

A. Mastodonを実行するインスタンスを作ります。
インスタンスの作成をクリック
image.png

GithubのREADMEがUbuntuを推奨しているのでOSはUbuntuを選択するのがいいと思います。
一応はAmazon Linuxでも動く模様。
インスタンス詳細は先ほど作成したVPCサブネットを選択

image.png

ストレージは8Gだとすぐいっぱいになるっぽい。
20GBだとそれなりー、との噂を聞いたかも(曖昧)

セキュリティグループの設定

B. SSH接続からインスタンスを操作するようにセキュリティグループを作ります。

image.png

マイIPを選択し、自分のコンピューターからSSHポートが繋がるようにします。

image.png

画面には移りませんがSSH接続するのに、RSA暗号を使います。
インスタンスを作成時にキーペアが作成されるので自分用の秘密鍵を大切に保管してください。(秘密鍵が漏れて、自分の仮想コンピューターで好き勝手されて、20万の請求が来たとかいう話も)
これを失くすとインスタンスに接続できません。必ず漏れないように大切に保管してください。

C. 外部から接続できるようにインスタンスにパブリックIPを設定します。
サービス > EC2インスタンス > Elastic IP
から新しいアドレスの割り当てでパブリックIPを取得します。
パブリックIPが取得出来たらアクション > IP の関連付けで先ほど作成したインスタンスにIPを割り当てます。

3インスタンスに接続する。

A. まず、自分はwindowsなのでSSHクライアントをダウンロードします。
Putty」でググってダウンロード
image.png

B. インストーラーをダウンロードしてウィザードに従ってインストールします。

C. Puttyをインストールしたら、ダウンロードした秘密鍵をPutty形式に変換します。
PuTTYgenを起動してLoadをクリック

先ほど保存した秘密鍵ファイルを選びます。

image.png

選択したらsave private keyを選択し、秘密鍵を保存します。

A. いよいよインスタンスに接続します。
Puttyを起動します。
左のタブから SSH > Auth からBrowseボタンを押して、先ほど保存した秘密鍵を選択
image.png

秘密鍵を読み込んだら、
sessionを選択
Host Nameubuntu@XX.XX.XX(インスタンスに割り当てたパブリックIP)を入力
ここまで言ったら接続設定を保存しましょう
Saved Sessions適当な名前を入れて接続設定を保存します。

image.png

接続設定を保存したら、Openをクリック

image.png

こういう系の画面が出たら成功です。
これでLinuxサーバーが操作が操作できます。

4.マストドンのセットアップ

ここからは完全に上述のテキスト通りです。

まず、メモリが足りないっぽいので、スワップファイルを作ります。

先ほどのコンソールにコマンドを打ち込みます。

$ sudo fallocate -l 4G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

パッケージを最新にします。

$ sudo apt-get update
$ sudo apt-get upgrade

途中grub関連(?)の更新が聞かれますが

keep the local version currently installed

を選択してください。(どっちでも大丈夫だとは思うけど念のため)

マストドンのビルドetcに必要なソフトを入れます

$ sudo apt-get install -y python3-pip unzip docker.io nginx
$ sudo pip3 install docker-compose

上のテキスト通り、nginxの設定ファイルを編集します。

$ sudo vim /etc/nginx/sites-enabled/default

元々機能してた部分は#でコメントアウトします。
XX.XX.XX.XXの部分はインスタンスのパブリックIP

置き換える内容は以下の通りで。

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

#server {
#  listen 80;
#  listen [::]:80;
#  server_name XX.XX.XX.XX;
#  return 301 https://$host$request_uri;
#}

server {
  listen 80;
  listen [::]:80;
  server_name XX.XX.XX.XX;
  #listen 443 ssl;
  #listen [::]:443 ssl;
  #server_name XX.XX.XX.XX;

  #ssl_protocols TLSv1.2;
  #ssl_ciphers EECDH+AESGCM:EECDH+AES;
  #ssl_ecdh_curve prime256v1;
  #ssl_prefer_server_ciphers on;
  #ssl_session_cache shared:SSL:10m;

  #ssl_certificate     /etc/letsencrypt/live/everydon.com/fullchain.pem;
  #ssl_certificate_key /etc/letsencrypt/live/everydon.com/privkey.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 0;

  #root /home/mastodon/live/public;
  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    #proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    #proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

こんな感じになってるはず。
image.png

Nginxを再起動します。

$ sudo systemctl start nginx

これで、インスタンスのセキュリティグループをHTTPを任意のIPにすることでサーバーに接続できるはずです

Githubからマストドンのソースを持ってきます。

$ git clone https://github.com/tootsuite/mastodon

念のため、最新版を確認

$ cd mastodon
$ git tag -l
$ git checkout -b x.x.x refs/tags/vx.x.x(x.x.xは最新版のバージョン)

これでマストドンのソースがダウンロードされるはずです。

設定ファイルをコピーします。

$ cp .env.production.sample .env.production

設定ファイルの中でDBの永続化設定をします。

env.production
db:
  restart: always
  image: postgres:alpine
## Uncomment to enable DB persistance
  volumes:
    - ./postgres:/var/lib/postgresql/data

redis:
  restart: always
  image: redis:alpine
## Uncomment to enable REDIS persistance
  volumes:
    - ./redis:/data

dbとradisにある

  volumes:
    - ./nanntoka

の部分のコメントアウト(#)を外します

いよいよマストドンのビルドです
下記のコマンドを実行

$ sudo docker-compose build

5.マストドンの設定

マストドンが使うカギを生成します。
下記のコマンドを3回実行し、文字列をそれぞれどこかにコピーします。

$ sudo docker-compose run --rm web rake secret

こういう感じの文字列が出力されます。
3回コピーしてください。

4b804c1e71d14951a50cbc52f3b8a7ef9d1bf993e2774227cdf637102022f4a5af188aa4fa4c236b31e4ed6970469d1527e06097b678edfb0ed9e6d85c18d805

設定ファイルをもう一回いじります。

$ vim .env.production

ドメインの設定、後でもう一度設定し直します。

# Federation
LOCAL_DOMAIN=XX.XX.XX.XX
LOCAL_HTTPS=false

秘密鍵を入力します
=の先に3つの秘密鍵を入力

# Application secrets
# Generate each with the `rake secret` task (`docker-compose run --rm web rake secret` if you use docker compose)
PAPERCLIP_SECRET=
SECRET_KEY_BASE=
OTP_SECRET=

日本語設定はパス

DBのマイグレーションをします。
マストドンが使うデータベースの初期設定ですね。

$ sudo docker-compose run --rm web rails db:migrate

マストドンが使う固定ファイルを生成します。

$ sudo docker-compose run --rm web rails assets:precompile

ここで、Nginxを再起動します。
マストドンはport3000とport4000で動きますが、
以降は80ポートに来たアクセスをNginxがport3000とport4000に割り振ります。

マストドンへのアクセスの玄関口になる訳ですね。

$ sudo systemctl stop nginx
$ sudo systemctl start nginx

マストドンを起動します

$ sudo docker-compose up -d

マストドンが起動しました。

http://XX.XX.XX.XX/

にアクセスするとマストドンのトップページに飛ぶはずです。

mastodon-top.png

6.連携ソフトの設定

マストドンが利用するメールサービスを設定します。
メールはAWSのメールサービスSESを利用します。

ただ、途中です

続きを読む

【AWS】ELB(CLB)

はじめに

タダです。
AWS認定資格の試験勉強のためにELBの情報をまとめた自分用メモになります。
あくまで個人用のメモになるので、その点はご了承ください。
※違う内容書いているなどありましたらご指摘いただけると幸いです。
※本記事では、Classic Load Balancerの情報をまとめていきます。
※随時アップデートがあれば更新していきます。

サービス概要

ELBは2つのタイプに分けられる

  • Classic Load Balancer

    • アプリまたはネットワークレベルのいずれかの情報に基づいてルーティングする
    • 複数のEC2インスタンス間でシンプルなトラフィックのルーティングに適する
  • Application Load Balancer
    • リクエストパスまたはホストベースでルーティングする
    • 複数のサービスにルーティングしたり、同じEC2インスタンスの複数のポート間で負荷分散するのに適する

特徴

  • スケーラブル

    • ELB自体も負荷に応じてスケールアウト
  • 可用性向上
    • 複数AZへの振り分け、インスタンスのヘルスチェック
  • マネージドサービス
  • ルーティング方式
    • 基本はラウンドロビン
  • コネクションタイムアウト
    • クライアントからの無通信状態が続くと接続を自動で切断する(デフォルト60秒)
  • ELB自体のスケーリング
    • じんわりとしたトラフィックの増加には対応できる

      • 逆に急激なトラフィックの増加にはスケーリング対応できないため、事前にPre-Warming(暖機運転)の申請をAWSに行う
  • スティッキーセッション
    • 同じユーザーから来たリクエストをすべて同じEC2に送信
    • アプリケーションでのセッション情報、一時ファイルなどをEC2が保持する構成の場合に必要
    • HTTP/HTTPSでのみ利用可能
    • EC2の増減を柔軟に管理できるようセッション情報は別のDBやキャッシュサーバに保持させるのが好ましい
  • Connection Draining
    • EC2インスタンスとELB間の登録解除、ヘルスチェック失敗した時にルーティングを中止して、処理中のリクエスト終わるまで一定期間まつ
  • X-Forwarded-For
    • HTTPまたはHTTPSロードバランサーを使用する場合に、クライアントの IP アドレスを識別するのに役立つ
  • Proxy Protocol
    • ELBはProxy Protocolバージョン1をサポートしている
    • Proxy Protocolヘッダーはバックエンド接続用にTCPを使う場合、クライアントのIPアドレスを識別するのに役立つ
    • 有効化する場合の前提条件は以下の通り
      • ELBの背後にプロキシサーバがいないこと
      • インスタンスでProxy Protocol情報を処理できるか確認する
      • リスナー設定でProxy Protocloがサポートされているかを確認する
  • 他のサービスとの連携機能
    • AutoScaling
    • Route53
    • CloudFormation
    • OpsWorks
    • Elastic Beanstalk
    • CloudWatch
    • EC2
    • S3など

サポートプロトコル

Classic Load Balancerのサポートプロトコルは、以下の通り

  • HTTP
  • HTTPS
  • SSL(セキュアTCP)
  • TCP

ロードバランサーのタイプ

ロードバランサーのタイプとして、外向けロードバランサーと内向けロードバランサーがある

  • 外向けロードバランサー : インターネットからアクセスできるELB
  • 内向けロードバランサー : VPC内やオンプレ環境からのみアクセスできるELB

モニタリング

ELBの監視を行う場合は以下の方法がある

  • CloudWatchメトリクス
  • ELBのアクセスログ
    • ELBへのリクエストの詳細情報をキャプチャしているので、確認する
  • CloudTrailログ

トラブルシューティング

よくELBのトラブルシューティングでHTTPステータスから設定不足を確認することがあるので、ドキュメントの情報をまとめる

  • HTTP 400: BAD_REQUEST

    • 原因:クライアントが誤ったリクエストをしてしまったため発生
    • 解決策:直接インスタンスに接続し、クライアントリクエストの詳細をキャプチャする
  • HTTP 405: METHOD_NOT_ALLOWED
    • 原因:リクエストヘッダー内のメソッドの長さが127文字を超える
    • 解決策:メソッドの長さを確認する
  • HTTP 408: Request Timeout
    • 原因:指定されたコンテンツのサイズが実際に創始されたコンテンツサイズと一致しないや、クライアントとの接続が閉じているため発生
    • 解決策:リクエストを生成しているコードを調べ、リクエストをより詳細に調べることのできる登録済みインスタンスに直接送信する、レスポンスが送信される前にクライアントが接続を閉じないようにする
  • HTTP 502: Bad Gateway
    • 原因:インスタンスからの応答の形式が適切でないか、ロードバランサーに問題がある
    • 解決策:インスタンスから送信された応答が HTTP 仕様に準拠していることを確認する
  • HTTP 503: Service Unavailable
    • 原因:ロードバランサーにリクエストを処理する能力が不足または、登録されたインスタンス(正常なインスタンス)が存在しない
    • 解決方法:前者の場合は一時的な問題のため、一旦放置氏それでも解決しない場合はAmazon Web Servicesサポートへ問い合わせ
    • 後者の場合、正常なインスタンスを登録する
  • HTTP 504: Gateway Timeout
    • 原因:アプリケーションの応答が、設定されているアイドルタイムアウトよりも長くかかっているまたは、録されたインスタンスがELBへの接続を終了させている
    • 解決策:前者は、ELB側のアイドル接続のタイムアウト設定を伸ばす
    • 後者の場合は、MWのKeepAlive設定を有効にしてELBのタイムアウト設定よりも大きい値を定義する

参考

更新日時

2017/05/01 初回投稿

続きを読む

RDSのIAM認証 (aws−cli編) 【cloudpack大阪ブログ】

cloudpack大阪の佐々木です。

RDSの認証をIAMでできるという話です。
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html

基本的な設定はこちらを参照
http://qiita.com/Pampus/items/18b45330b990927652fd

認証に必要なTokenをaws-cliで取得できるようになってました。

aws-cliをアップデートします。

$ sudo pip install -U awscli
$ aws --version
aws-cli/1.11.81 Python/2.7.12 Linux/4.9.17-8.31.amzn1.x86_64 botocore/1.5.44

aws rds generate-db-auth-token コマンドが使えるようになっています。

NAME
       generate-db-auth-token -

DESCRIPTION
       Generates an auth token used to connect to a db with IAM credentials.

SYNOPSIS
            generate-db-auth-token
          --hostname <value>
          --port <value>
          --username <value>

OPTIONS
       --hostname (string) The hostname of the database to connect to.

       --port (integer) The port number the database is listening on.

       --username (string) The username to log in as.

実行するとトークンが発行されます。

$ aws rds generate-db-auth-token --hostname test.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com --port 3306 --username testuser --region ap-northeast-1
test.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com:3306/?Action=connect&DBUser=testuser&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Expires=900&X-Amz-Date=20170427T134947Z&X-Amz-SignedHeaders=host&X-Amz-Security-Token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&X-Amz-Credential=xxxxxxxxxxxxxxxxxxxxxx2Faws4_request&X-Amz-Signature=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

これをパスワードにして接続します。

$ mysql -u testuser -h test.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -p`aws rds generate-db-auth-token --hostname test.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com --port 3306 --username testuser --region ap-northeast-1` --ssl-ca=rds-combined-ca-bundle.pem
ERROR 2059 (HY000): Authentication plugin 'mysql_clear_password' cannot be loaded: plugin not enabled

んん?

--enable-cleartext-plugin ってのがいるらしいです。
https://dev.mysql.com/doc/refman/5.6/ja/cleartext-authentication-plugin.html

$ mysql -u testuser -h test.xxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com -p`aws rds generate-db-auth-token --hostname test.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com --port 3306 --username testuser --region ap-northeast-1` --ssl-ca=rds-combined-ca-bundle.pem --enable-cleartext-plugin
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 711
Server version: 5.7.16-log MySQL Community Server (GPL)

Copyright (c) 2000, 2016, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql>

続きを読む

IAM Database AuthenticationをPythonから試す

背景

RDS for MySQLとAuroraのDB接続にIAMが使えるようになったそうです。
Manage access to your RDS for MySQL and Amazon Aurora databases using AWS IAM
IAM Database Authentication for MySQL and Amazon Aurora
サンプルがJavaだったのでPythonから試してみました。

環境

  • Amazon Linux 2017.03
  • Aurora 1.12
  • Python 2.7.12
  • boto3-1.4.4

準備

Aurora

RDSのクラスターから「クラスターの変更」を開き「IAMのDB認証を有効にする」を「はい」に設定します。Auroraの場合db.t2.smallはIAMデータベース認証をサポートしていないためdb.t2.medium以上で試してください。
RDS_·_AWS_Console.png

DBユーザーの作成

IAMアクセス用のDBユーザーを作成し、必要な権限を付与します。

mysql> CREATE USER iam_auth_user@'testdb-cluster.cluster-abcdefghijkl.ap-northeast-1.rds.amazonaws.com' IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS';
mysql> GRANT SELECT ON `testdb`.* TO iam_auth_user@'%';

公開鍵のダウンロード

IAMデータベース認証はSSL接続が必須という事なので公開鍵をダウンロードしてec2上の適当なパスに配置しておきます
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Aurora.Overview.html#Aurora.Overview.Security.SSL

IAM

ドキュメントを参考にIAM Roleに権限を付与します。リソースIDはクラスターのものを指定しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "rds-db:connect"
      ],
      "Resource": [
        "arn:aws:rds-db:ap-northeast-1:12345678:dbuser:cluster-12ABC34DEFG5HIJ6KLMNOP78QR/iam_auth_user"
      ]
    }
  ]
}

接続

iam_db_auth.py
#  -*- coding: utf-8 -*-
from __future__ import print_function
import boto3
import mysql.connector
from mysql.connector.constants import ClientFlag

rds = boto3.client('rds', region_name='ap-northeast-1')

user = 'iam_auth_user'
host = 'testdb-cluster.cluster-abcdefghijkl.ap-northeast-1.rds.amazonaws.com'
db_auth_token = rds.generate_db_auth_token(host, 3306, user, 'ap-northeast-1')

config = {
    'user': user,
    'password': db_auth_token,
    'host': host,
    'db': 'testdb',
    'client_flags': [ClientFlag.SSL],
    'ssl_ca': 'rds-combined-ca-bundle.pem'
}

cnx = mysql.connector.connect(**config)
cur = cnx.cursor(buffered=True)

cur.execute('SELECT AURORA_VERSION();')
print(cur.fetchone())

cur.close()
cnx.close()
$ python iam_db_auth.py 
[(u'1.12',)]

以上です。

参考

続きを読む