helpdelete

AWS CLIとCredentialの話

はじめに

自己紹介

  • 誰?
    • 「たっち」と名乗っております
    • @TatchNicolas 
    • ぷるぷる、ぼくはわるい関西人じゃないよ
    • ややオネエな中国語を話します
  • 何してる人？
    • Androidアプリ開発
    • SESでJava開発
    • 研究者向けにAWS環境構築・サポート

今日の目標

  • AWS CLIについて知る
  • AWS CLI/SDKをちょっと便利に、安全に使う方法を知る
    • 具体的にはIAM Roleとprofileと環境変数(direnv)を使います
    • すでにご存知の方はマサカリの準備是非そうでない方へのサポートを！

AWS CLIについて

そもそも、AWSってどうやって操作されているの？

  • 最終的には同じところに行き着く
    • マネジメントコンソール(ブラウザで操作、気軽に使える)
    • SDK(プログラムで操作する、自動化にて大活躍)
    • CLI(今日やるところ)

どれも最終的にはREST APIを叩きに行くのでできることに(ほとんど)差はない

CLIのメリット

  • 繰り返しが容易
    • CloudFormationを作ったり壊したり
    • S3で復数のバケット/オブジェクトに一括の操作
  • 自動化も組める/シェル芸できる
  • 明示的に書くべきことが多い=あるサービスを使うのに必要な情報を自然と意識するようになる

CLIのセットアップ

  1. IAM Userに対してAccess Keyを発行
  2. pip install awscli
  3. aws configure
    • 1で発行したAccess Key/Secret Keyのペアを入力(以下、合わせて「Access Key」と表記します)

基本的な使い方

  • コマンドの基本はaws <service namea> <subcommand> <parameters>
    • サービス名はec2/s3/codecommitのように全て小文字
    • サブコマンドはget-repositories/describe-stacksのようにハイフン区切りで「動詞-目的語」の形
    • オプションは--user-nameのようにハイフン２つで始まり、単語はハイフン区切り

例

aws iam list-users
aws ec2 describe-instances
aws cloudformation delete-stack --stack-name foo

認証と権限の話

IAM

  • IAM Userに、2種類の認証情報を付けられる
    • AWS Management Console access/CLIから作るときはaws iam create-login-profile
    • Programmatic access/CLIから作るときはaws iam create-access-key
  • 具体的に何ができるか=権限はIAM Policyで設定する
    • ポリシーはUser/Group/Roleに(復数でも)アタッチできる

AWSの権限周りの基本的な考え方(公式から一部抜粋)

  • 最小権限を付与する
    • 要らない権限はつけない！
  • 不要な認証情報を削除
    • 使わないユーザは消す
    • Management Consoleしか使わないなら、Access Keyは発行しない(逆も然り)
  • 認証情報を共有するのではなく、ロールを使って委託する
    • Access Keyをファイルに書いてzipにパスワードをかけてメールで送信するとか...

詳しくは公式のベストプラクティス 参照

AWSサービスが引き受けるロールの話

  • IAM Roleは「帽子」に例えられる
    • あるIAM Userが帽子をかぶっているときは、その帽子に定義されている権限で操作できる
  • EC2/Lambda/BeanstalkにRoleをもたせることができる
    • その上で動かすAWS CLI/SDKはそのRoleの権限の範囲で操作ができる
    • DynamoDB/SES/CloudWatchなどなど、システム(アプリ)にAWSサービスを取り入れるときに
    • Access Keyをそもそも発行しなくて良い！

Access Keyをコードに直書きするのはやめよう！

問題点

プログラマブルにAWSを利用できる=効率的に悪用される

  • Access Keyは漏れると本当に大変
    • GPUインスタンスを上限まで立ててマイニングされ、クラウド破産
    • git-secrets を使いましょう
  • 複数アカウント/復数ユーザを使うときに面倒
    • 管理すべきAccess Keyが増えるのも嬉しくない
    • ???「注意を徹底する!Excelで作った申請書にハンコだ!」
    • --profileオプションを使ってもいいが、コマンドが長くなる

『問題を根性で解決するのは馬鹿です。
問題をエンジニアリングで解決するのがエンジニアの仕事です。』

(これとても好きなのですがの出典はどちらでしょうか...)

じゃあどうする？

私が個人的に実践しているやり方

  • ルートアカウントは使わないで大切にしまっておく(大前提)
  • AssumeRole以外何もできないユーザを用意する
    • MFA(多要素認証)はかけておきましょう
    • Access Keyも発行します
    • SAML/LDAP連携などは今回は御容赦を...
  • 操作したい範囲の権限を持ったRoleを作る
    • できるだけ、プリセット(AWS Managed)のポリシーから選んで使う
    • Trusted relationshipで上記のユーザを信頼する
    • Conditionsで「MFAが有効である」を条件に追加
  • 案件ごとに作業フォルダを用意してdirenv を使ってprofileを切り替え

ひとつのIAM Userで復数のAWSアカウントを操作できる！

Access KeyをMFAで保護することができる！

AssumeRoleしかできないIAMユーザのポリシー

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "foo",
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::*:*"
            ]
        }
    ]
}

IAM RoleのTrusted relationship

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": {
            "AWS": [
               "arn:aws:iam::123456789012:user/johnsmith",
            ]
         },
         "Action": "sts:AssumeRole",
         "Condition": {
            "Bool": {
               "aws:MultiFactorAuthPresent": "true"
            }
         }
      }
   ]
}
  • 他のアカウント(他部署やお客様など)を操作するときは、
    1. 向こうのアカウントでロールを作ってもらう
    2. Principalのところに自分のIAM UserのARNを入れてもらう

AWS CLIの設定

[default]
region = ap-northeast-1
output = json
[profile adminrole]
region = ap-northeast-1
role_arn=arn:aws:iam::123456789012:role/AdministratorAccessRole
mfa_serial = arn:aws:iam::123456789012:mfa/johnsmith
source_profile = default
[profile anotherproject]
region = ap-northeast-1
role_arn=arn:aws:iam::222222222222:role/AnotherRoleInAnotherAccount
mfa_serial = arn:aws:iam::123456789012:mfa/johnsmith
source_profile = default

direnvで.envrcの設定

export AWS_PROFILE=adminrole

(おまけ)グローバルな.gitignoreの設定

  • アプリのコード/外部からアクセス可能なサーバににAccess Keyを書いちゃいけない
  • そのために使った.envrcをコミットしては意味がない
    • 先のgit-secretと合わせて二重防御
    • MFAと合わせて三重防御

~/.gitconfig

[core]
	editor = vim
	excludesfile = /home/johnsmith/.gitignore_global

~/.gitignore_global

.envrc

注意点/補足

  • Roleを使わなくても可能だが、結構面倒
    1. aws sts get-session-token --token-code 123456
    2. 帰ってきた一時認証情報を環境変数または~/.aws/configureに保存
  • --profileなし、direnv+環境変数で操作対象を切り替えると今どの環境を触っているのか意識しにくい
    • IAM Userはaws sts get-caller-identityで自分が誰なのかわかる
  • Assume Roleで利用する一時認証情報の期限は自分で設定できる
    • あんまり長いと守りとして弱い、短いと頻繁にMFAコードを求められてストレス

今度やりたいこと

  • AWS Secrets Manager を使ってみたい

  • AWS CLIシェル芸大会

  • IAM Roleを使ったRDSへの接続

  • Google Firebase

  • JenkinsでIonicのCI/CDパイプライン

  • WebSocketでスライドめくり

ありがとうございました