たいがーのインターンシップ体験記【18日目】　~STSに対応できました…が？~

急に夏のような暑さがやってきて、本物の夏は耐えられないのではないかとおびえています、たいがーです。

ついに昨日から半袖を解禁してしまいました。夏に着るものがなくなりそうです。

前回は、今まで作ったもののSTS対応を進めていました。今回も、その続きから始めます。一時的に作られたキーを使い、以前作成したスクリプトでEC2インスタンスを一度に起動してみようと思います。

前回、最後はassume roleがaccess deniedされているというエラーが出ていました。調べてみると、ポリシーの"Principal"を変更するといいらしい！とのことで、やってみました。

"Principal"エレメントは、リソースへのアクセスを許可または拒否するユーザー、アカウント、サービス、または他のエンティティを指定するものだそうです。

これは許可をされる側の設定なので、ロール内の信頼ポリシーの話なのですが、それを理解していませんでした。今までポリシーを変更したのがassume roleを設定したときのみだったので、IAMユーザー内のポリシーの話かと勘違いし、とりあえずやってみました。

こちらが変更前。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::ACCOUNT_ID_NO:role/USER_NAME"
            ]
        }
    ]
}

こちらが変更後。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Principal": {
            "AWS": "arn:aws:iam::ACCOUNT_ID_NO:user/IAM_USER_NAME"
            },
            "Resource": [
                "arn:aws:iam::ACCOUNT_ID_NO:role/USER_NAME"
            ]
        }
    ]
}

もちろん、実行しても動きません。

社員の方にとりあえず出てきたから打ってみたと話すと、そもそものところが違うということで、もう一度STSの解説をしていただきました。

これは、IAM ロール用の信頼ポリシーおよびリソースベースのポリシーで使用することができます。

と公式のドキュメントにも書いてあったのにもかかわらず、この点を見逃していました。

また、そもそも上記のポリシーに関しても、ポリシーのResourceに、この設定しているアカウントのものしか追加しておらず、一時的なキーを作成する、ほかのアカウントの情報が入っていませんでした。

なので、ユーザーのポリシーを変更します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::ACCOUNT1_ID_NO:role/USER_NAME"
                "arn:aws:iam::ACCOUNT2_ID_NO:role/USER_NAME"
                "arn:aws:iam::ACCOUNT3_ID_NO:role/USER_NAME"
            ]
        }
    ]
}

これで3アカウントに対応することができると思ったのですが、assumeの命令を出しているアカウントのサーバーが起動していませんでした。

そこで、起動しなかったアカウントのIAMロールの信頼ポリシーの"Principal"を触っていきます。変更前はアカウントがrootアカウントになっていますが、こちらを変更していきます。変更前はこのような形です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_ID_NO:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

アカウントをIAMユーザーのアカウントに設定することで、アクセスが許可されます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_ID_NO:user/IAM_USER_NAME"
      },
      "Action": "sts:AssumeRole",
      "Condition": {}
    }
  ]
}

無事、すべてのインスタンスを起動することができました。

さて、いよいよ出来たスクリプトをほかの方に見ていただくためにGitにあげます。前回、何も起こらずに今日は終わったらいいなぁと言っていた、Git関係のエラー。どうだったのかといいますと…

Gitのコツってあるのでしょうか

今日もエラーが起こりました！大半の要因が私の確認不足等で起こるのですが、何か対策やコツはないのでしょうか…

Git Bashでcommitをするとき、このようにして、コメントをつけます。

$ git commit -m "コメント"

その際、コメントをミスしましたが、あとで直せるかなと思い、pushしてしまいました。それも、２個続けて。

間違いはここから始まりました。

さっきのコメント、明らかに打っている途中で、レビューをしていただくし、訂正しなければ…とリモートリポジトリで確認すると、、コメントが変更できませんでした。プルリクの名前は変更可能なのですが、commitのコメントは訂正できないようです…

とりあえず検索してみると、git rebaseを使い、コミットをまとめ、修正したいコミットの一覧が出てくるので編集すれば、コメントを変更することができることが判明しました。そこで、どこまで戻すかを調べようと思いました。そう思い、打ったのはこちらでした。

$ git reflog

実はこれが大きな罠でした。

ここではコミットのみをrebaseでまとめ、修正しなければならなかったので、使うべきは

$ git log

でした。git reflogはコミット以外の部分も表示されるので、こちらで表示したもので考えると、まとめなくてよいところまで、まとめてしまいます。その結果、名前を変える気のなかった他の課題を取り組んでいた時に触っていたcommitまで、今作業中のブランチで変更したかのようになってしまいました。

とりあえず、何事もすべてをなかったことにするために、git logでどこまでを戻すかを調べます。そうして今日のコミットする前まで戻り、すべてやり直しました。

Gitを使っているときはいつも以上に確認不足がひどく目立ちます。もっと確認しながら進めなければなと思います…毎回言っている気がしているけれど…

コードレビューをしていただいています

人から実際意見をもらうことによって、さらに見やすくしていこうということで、GitHubでほかのかたにレビューをしていただいています。

勢いのままで書いているなと思うのが、クォーテーションがシングルとダブルが混じっていたり(Pythonはどちらでも使えるが、統一したほうが綺麗かつ見やすい)、コメントの入れる位置がずれていたりするところです。

また、たびたびしてしまうのが，一度しか使わない変数を宣言してしまうことです。その際は、わざわざ宣言しなくてもそのまま書いてしまって良い、とレビューが来て、いつもとりあえず長くなるものは、とりあえず宣言してしまう癖があるので、気を付けようと思いました。

性格のおおざっぱさがばれています

あとで何とかなるだろうと思っていると、意外なところで落とし穴にはまることも多くありました。Gitはコミットする前やプッシュする前に、何度か確認する必要がありますよね。そうしないと自らの首を絞めかねません。もう少し、落ち着いて作業したいと思います。