AWS ロング ID の雑なまとめ

• 期限: 2016/12/16
  • でもアカウント毎にちょいちょい違うっぽいので以下で確認
    • EC2 Dashboard の Resource ID length management

【目次】

変更対象と変更内容

ロング ID 変更対象

• Reservation (各リザベーションは単一のインスタンス起動リクエストの結果を意味しますが、複数のインスタンスを起動した際には複数のインスタンスと関連付けられます。 )
• Instance ID
• Volume ID
• Snapshot ID

reservationはインスタンスを起動するアクションのこと。run-instancesを使って一度に複数のインスタンスを起動すると、（普通は）１個のreservationが作られ、複数のインスタンスがそこに属する（ただし場合によっては複数のreservationが作られることもあるらしい）。

qiita.com

変更内容

• それぞれ 8 桁から 17 桁になる．

変更設定 URL

• EC2 Dashboard の Resource ID length management をクリック

既存リソースの変更

• できないっぽい．ショートだろうがロングだろうが，1 度割当たった ID は変更不可っぽい．

設定対象の単位

• IAM ユーザー，または IAM ロール単位
• リージョン単位 (マルチリージョン運用であれば，それぞれのリージョンで設定が必要)
  • すべてのリージョンで一気にオプトインするためのツールがある．
    • awslabs/ec2-migrate-longer-id: The code opts the entire account in to the longer id format for ec2 resources in each region with a single request. It will also print status and revert to shorter ids in case of problems. https://github.com/awslabs/ec2-migrate-longer-id

オプトイン・オプトアウト

• 現在の設定の確認
  • EC2 インスタンス ID のロング ID 設定を調べたいとき (ARN には調べたい対象 IAM ユーザーの ARN を指定．PROFILE は場合によっては指定)

$ aws ec2 describe-identity-id-format --resource instance --principal-arn [ARN] --profile [PROFILE]
{
    "Statuses": [
        {
            "Deadline": "2016-12-12T18:00:00Z",
            "UseLongIds": true,
            "Resource": "instance"
        }
    ]
}

• オプトイン

$ aws ec2 modify-identity-id-format \
    --resource [instance | reservation | snapshot | volume] # どれをオプトインしたいか選ぶ
    --principal-arn [ARN]
    --use-long-id

• オプトアウト

$ aws ec2 modify-identity-id-format \
    --resource [instance | reservation | snapshot | volume] # どれをオプトアウトしたいか選ぶ
    --principal-arn [ARN]
    --no-use-long-id

ARN にルートアカウントを指定すれば，そのアカウント配下の IAM ユーザーの設定を一気に変更できる．

その他

運用スクリプトなどで桁数バリデーションチェックしている場合は修正しましょう．

開発環境でのテスト

• ある IAM ユーザーのロング ID を有効化する．
• 開発環境をその IAM ユーザーで作り直す．

• 可能な限りの E2E テストを流して異常が起こらないかチェック

• 面倒くさかったらルートアカウントの ARN 指定してバーン！ってやってまずそうならバーン！と戻すという手もあり．自己責任でよろしくお願いします．

詳細は以下！

よくある質問 - Amazon EC2 | AWS https://aws.amazon.com/jp/ec2/faqs/#longer-ids

こんなブログ書いててなんですが「より長い EC2、EBS、および Storage Gateway リソース ID」セクションを全部読んでおいた方がいいと思います．

以上

AWS IAM の雑なまとめ

【目次】

IAM の用途

• AWS マネージメントコンソールへのログイン，AWS CLI や AWS SDK, IAM HTTPS API などで使用できる．

IAM の単位

• IAM ユーザー

  • ユーザー．10 グループまで所属可能．
  • 認証情報は，IAM ユーザーごとに API キーを発行するか，OpenSSL などで作成した X.509 Certificate をアップロードして使う．
  • API キーはローテーション強制ができる．

• IAM グループ

  • 単にユーザーをグルーピングしたもの

• IAM ロール

  • AWS サービスやアプリケーションに対して権限を付与するためのもの．IAM ユーザー|グループとは紐付かない．EC2 のインスタンスプロファイルなど．

IAM ポリシー

ユーザーベースポリシー

• IAM ユーザー|グループ|ロールに紐付ける．

• AWS 管理ポリシー

  • AWS によってあらかじめ用意されたアクセス権群のテンプレートのようなもの．複数の IAM ユーザー|グループ|ロールで共有可能
• ユーザー管理ポリシー
  • ユーザーによって独自にカスタマイズ，定義されたポリシー群．複数の IAM ユーザー|グループ|ロールで共有可能

• インラインポリシー

  • 各 IAM ユーザー|グループ|ロール毎に個別に設定するポリシー．共有不可．

• IAM ポリシージェネレーターを使用して書き出させるのが簡単で確実

  • IAM ポリシージェネレーター内で 5 バージョンの管理が可能
• ポリシーのテストには IAM ポリシーシミュレーターというのが使える．
• 既存ポリシーのチェックには IAM ポリシーバリデーターというのが使える．

リソースベースポリシー

• S3 のバケットポリシーなどに紐付ける．他には VPC, Lambda, Glacier, KMS, OpsWorks など．他多数．
  • AWS Black Belt Techシリーズ AWS IAM http://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam 33 ページ
  • IAM と連携する AWS サービス - AWS Identity and Access Management http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

IAM ロールの信頼ポリシー

• ある IAM ロールに付けた権限を他の主体 (Principal) に移譲する．
  • ( ≒ Principal が，ある IAM ユーザーになりすます．権限を引き受ける(AssumeRole))

ID フェデレーション

• AD ユーザー ( ≒ ID プロバイダー, SAML 2.0 or OpenID Connect (Google, Facebook, Amazon などのアカウントが対応している．また Amazon Cognito とも連携可能) と互換性のあるもの) などに IAM 権限を移譲する．

  • AWS STS (Security Token Service, IAM のサブプロダクト) を使用．具体的には AssumeRole, GetFederationToken.
  • Temporary Security Credentials

• identity provider カラムで ID プロバイダーを設定し，ある IAM ロールを AssumeRole する．

一時的セキュリティ認証情報

• IAM ロールを使ったクロスアカウントアクセスなど

• アカウント (IAM ユーザー) 側

  • どの IAM ロール (リソースに紐付いた IAM ロールなど) を移譲されるかを定義
• リソース側
  • 誰 (Principal) がどのリソースにどんな権限を持つことができるか定義

Temporary Security Credentials

• 以下の 3 つをユーザーに与え，期限付きの認証情報を与える．一時的な IAM AssumeRole と考えてもよい．GetSessionToken(自分自身の IAM ユーザー権限を一時的に利用), GetFederationToken はこの仕組を利用する．
  • アクセスキー ID
  • シークレットアクセスキー
  • セキュリティトークン
• 権限を与える時間帯
  • IAM ユーザー
    • 最小 15 分 〜 最大 36 時間 (デフォルト 12 時間．時間帯はプリセットのものから 1 つ選ぶ)
  • AWS アカウント
    • 最小 15 分 〜 最大 1 時間 (デフォルト 1 時間．時間帯はプリセットのものから 1 つ選ぶ)
• 詳細は以下
  • AWS Black Belt Techシリーズ AWS IAM http://www.slideshare.net/AmazonWebServicesJapan/20150617-aws-blackbeltiam 53 ページ

Temporary Security Credentials のまとめ

種別	説明	権限
GetSessionToken	自身の権限で一時認証	自身の権限 クロスアカウント不可 MFA 利用可
GetFederationToken	信頼ユーザーで一時認証	自身の権限内で規定 クロスアカウント不可 MFA 利用不可
AssumeRole	IAM ロールとマッピング	IAM ロールで規定 クロスアカウント可 MFA 利用可

AWS CLIでAssumeRole from Tetsunori Nishizawa

www.slideshare.net

その他

• STS は基本的にグローバルサービス (https://sts/amazonaws.com) だが，IAM の Account Settings にて各リージョンで STS の機能をアクティベート可能(->レイテンシーの低減などの効果)．同時に AWS CloudTrail も忘れずにアクティベートすること．

• Switch Role

  • AWS マネージメントコンソールにて，ある IAM ユーザーから，クロスアカウントアクセス用 IAM ロールにスイッチできる．
  • 必要なときに IAM ユーザーの権限を昇格とかに使える．
    • IAM ユーザー側には読み取り権限のみ
    • IAM ロール側には更新権限も

• 変更の反映にまれに遅延が発生することがある，らしい．

コンフィグ類の書き方

• ~/.aws/config

[default]
region = ap-northeast-1

[profile foo]
region = us-east-1

• ~/.aws/credentials

[default]

[foo]
aws_access_key_id = A*******************
aws_secret_access_key = x***************************************

$ aws configure list で確認

以上

【スーパー小ネタ】SHA-256 でファイルのハッシュ値チェック

CentOS 7 でやろうとしたら shasum コマンドが入ってなかったのでメモ．

$ sudo yum install perl-Digest-SHA
$ shasum -a 256 ファイル名

以上

EC2 Auto Recovery の雑なまとめ

【目次】

Auto Recovery の流れ

• 対応しているインスタンスタイプのインスタンスを起動する

• Create Status Check Alarm

  • Whenever で Status Check Failed を選択して Create Alarm をクリック

• CloudWatch に作成されているアラームを確認

  • +EC2 Action, Recover this instance

• CloudWatch アラームのパラメーターを決める

  • 何秒間隔で: 60 秒 ( = 1 ピリオド)
  • 何ピリオド: 1 ピリオド
  • 何回失敗したら: 1 回

前提条件 (対応しているインスタンスタイプなど)

• Use a C3, C4, M3, M4, R3, T2, or X1 instance type
• Run in a VPC (not EC2-Classic)
• Use shared tenancy (the tenancy attribute is set to default)
• Use EBS volumes, including encrypted EBS volumes (not instance store volumes)

aws-cli で Auto Recovery (用の CloudWatch アラームを) 作成

こんなコマンドをたたくと Auto Recovery が設定されます．

$ ar_instance_id='i-0123456789abcdefg'

$ aws cloudwatch \
    put-metric-alarm \
    --alarm-name StatusCheckFailed_System-Alarm-for-"${ar_instance_id}" \
    --metric-name StatusCheckFailed_System \
    --namespace AWS/EC2 \
    --statistic Minimum \
    --dimensions Name=InstanceId,Value="${ar_instance_id}" \
    --unit Count \
    --period 60 \
    --evaluation-periods 1 \
    --threshold 1 \
    --comparison-operator GreaterThanOrEqualToThreshold \
    --alarm-actions arn:aws:automate:ap-northeast-1:ec2:recover

【追記】 --statistic Maximum から --statistic Minimum に変更．AWS の推奨だから

docs.aws.amazon.com

また上記リンク先内に

Important
再起動と復旧アクションの競合状態を避けるには、EC2 インスタンスを復旧させるアラームを作成するときに、アラームのしきい値として 1 分に代えて 2 分を設定することをお勧めします。

とあるが，これはあくまで「再起動」と「復旧」の２つのアラームが存在する場合の推奨であり，「復旧」アラームのみであれば 1 分でもよい．

注意点など

---

【訂正: 2017 年 1 月 9 日 追記】

以下の「IAM ロールと IAM ユーザー」のセクションは無視してください．

以前は，IAM ロールの権限で Auto Recovery のアラームを作成すると，アラームを設定した際に一時的な認証情報が使用されていました．そして，リカバリーアクション発動時に，一時的な認証情報を再度利用しようとし，一時的な認証情報のため，それでは処理が実行できずエラーが発生していたが，現在は対応され，IAM ロールの権限で Auto Recovery のアラームを作成しても，問題なくリカバリーアクションが実行されます．

IAM ロールと IAM ユーザー

IAM ロールを使うとアラームの作成自体は問題なく終了するが，recover アクションが動かないので IAM ユーザーを作り適切な権限を付与し，そちらのプロファイルを使ってアラームを作成する．

• Auto Recovery 用 CloudWatch アラームを作成する用の IAM ユーザーを作成

cw_alarm_for_auto_recovery
Access Key ID:
A*******************
Secret Access Key:
x***************************************

• 権限付与, 可能な限り絞った方がよいが，手っ取り早く PowerUserAccess を付与

• Auto Recovery 用 CloudWatch アラームを作成する aws コマンドを発行する Linux ユーザー配下に credentials を設定

$ aws configure --profile cw_alarm_for_auto_recovery
AWS Access Key ID [None]: A*******************
AWS Secret Access Key [None]: x***************************************
Default region name [None]: ap-northeast-1
Default output format [None]:

$ cat ~/.aws/config
[default]
region = ap-northeast-1
[profile cw_alarm_for_auto_recovery]
region = ap-northeast-1

$ cat ~/.aws/credentials
[cw_alarm_for_auto_recovery]
aws_access_key_id = A*******************
aws_secret_access_key = x***************************************

$ aws configure list
Name                    Value             Type    Location
----                    -----             ----    --------
profile                <not set>             None    None
access_key     ****************NVVA         iam-role
secret_key     ****************O0pW         iam-role
region           ap-northeast-1      config-file    ~/.aws/config

• Auto Recovery 用 CloudWatch アラームを作成

• $ aws cloudwatch put-metric-alarm コマンドに，オプション --profile cw_alarm_for_auto_recovery を付与

System Status Check の失敗をどうやってテストするか

set-alarm-state を使っても，インスタンス復旧のアクションが実行される前に確認のためのヘルスチェックが再度実行が走るため，疑似障害は起こせない．

そのため，アラームの発火条件を ALARM is INSUFFICIENT にして，インスタンスを止めてテストする．

【追記】 以下のブログによると recover はテストできない模様． terminate はテストできました．

www.simpline.co.jp

recover を実行するアラームを作成する場合，IAM ロールによる実行許可が使用できない． root アカウントまたは必要な権限を付与した IAM ユーザーでアラームを作成する必要がある．

• recover に必要な権限
  • ec2:DescribeInstanceStatus
  • ec2:DescribeInstances
  • ec2:DescribeInstanceRecoveryAttribute
  • ec2:RecoverInstances

詳細は以下

docs.aws.amazon.com

抜粋

アクセス許可

AWS Identity and Access Management (IAM) ユーザーの場合、アラームを作成または変更するには次のアクセス権限が必要です。

ec2:DescribeInstanceStatus と ec2:DescribeInstances。Amazon EC2 インスタンスステータスメトリクスに対するすべてのアラーム用。
ec2:StopInstances。停止アクションを含むアラーム用。
ec2:TerminateInstances。終了アクションを含むアラーム用。
ec2:DescribeInstanceRecoveryAttribute と ec2:RecoverInstances。復旧アクションを含むアラーム用。

インラインポリシーの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Stmt1478745555000",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceRecoveryAttribute",
                "ec2:RecoverInstances"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "Stmt1478745582000",
            "Effect": "Allow",
            "Action": [
                "cloudwatch:PutMetricAlarm"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Auto Recover ありのインスタンス ID 一覧取得

$ aws cloudwatch describe-alarms --query 'MetricAlarms[?MetricName==`StatusCheckFailed_System`].Dimensions' | grep Value | cut -d ':' -f 2-2 | sed 's/ //' | sed 's/"//g'

• 既存インスタンスで Auto Recovery なしのものにすべて付与するシェルスクリプトの作成とテスト 全インスタンスのインスタンス ID - Auto Recovery ありのインスタンス ID = まだ Auto Recovery のないインスタンスのインスタンス ID リスト これを while ループに食わせて一気に作成

• 指定したインスタンス ID の EC2 インスタンスに Auto Recovery を付与するシェルスクリプトの作成とテスト 手動でインスタンス ID のリストを作成し， これを while ループに食わせて一気に作成

Python 環境のセットアップ on Mac OS X in 2016 秋

自分用メモ

• Mac OS X 10.11.6 - El Capitan

デフォルトの Python

$ which python
/usr/bin/python

$ python -V
Python 2.7.10

pip はデフォルトでは入っていません．

Homebrew で Python 3 をインストール

$ brew install python3

$ which python3
/usr/local/bin/python3

$ python3 -V
Python 3.5.2

Python 3.4 か 3.5 から pip も一緒にインストールされるようです．

$ which pip3
/usr/local/bin/pip3

Python のための bash 設定

$ vi ~/.bashrc

export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python3.5/site-packages
export PYTHONDONTWRITEBYTECODE=1

Python 3 系から pyenv なども統合されているようですので今後追記していきます．

入門 Python 3

Pythonプロフェッショナルプログラミング 第2版

パーフェクトPython (PERFECT SERIES 5)