猫でもわかるWebプログラミングと副業

本業エンジニアリングマネージャー。副業Webエンジニア。Web開発のヒントや、副業、日常生活のことを書きます。

【AWS IAM】AWS EC2 から CodeCommit のコードを clone できるようにするまで【CloudFormation】

はじめに

CodeCommit にpushされているコードを AWS EC2 にデプロイしたい。

ただし、CodeDeploy などを使うほどのものでもないので、サクッと git clone とかでデプロイしたい。

AWSコンソールでぽちぽちすることはやりたくないので、そこはCloudFormationを使いたい。どうしてもAWSコンソール上でぽちぽちすると手順がよくわからんくなってしまうし、裏で勝手にリソースが作られたりして、リソースの削除が面倒という問題がある。

CloudFormationで作成されたリソースは「スタック」と呼ばれ、スタックを削除すると全てのリソースが削除できるし、誰がやっても同じようにリソースが作成できるので、今回はCloudFormationを採用している。

git cloneのために何をする必要があるか

EC2からCodeCommitのコードをcloneするには

  • AWS IAMロールの設定
  • EC2インスタンスのgit config

が必要になる。

AWS IAMとは

IAMとは Identity and Access Management の略で、ユーザーの管理だとか、権限管理などを行うAWS上のサービスだ。

IAM ロールとは

IAMには「グループ」「ユーザー」「ロール」「ポリシー」がある。

「ポリシー」はAWSコンソールのIAMから「ポリシー」を見てもらうと色々出てくる。例えば AWSCodeCommitReadOnly は CodeCommit から Clone できたりREADONLYな操作が可能になるポリシーである。これを「ユーザー」にくっつけるとそのユーザーがCodeCommitからのREADONLYな操作ができるようになる。

AWS IAM のポリシーの例
AWS IAM のポリシーの例

これによりユーザーの権限を細かく設定できる。この人はCodeCommitにはアクセスできるけどEC2のコンソールにはアクセスできない、などの設定が可能だ。

ポリシーは「ユーザー」だけでなく「グループ」に付けることもできる。そのグループにユーザーを所属させると、グループに与えられた権限がそのユーザーに与えられる仕組み。ユーザーが多くなってきた場合はユーザーごとに設定するのは大変なので、グループで権限管理するのが主な使い方になる。

「ロール」は特殊だが、今回はこれが一番重要だ。AWSではユーザーではなくインスタンスの権限も管理してやる必要がある。例えば「このインスタンスはCodeCommitにアクセスする権限があるかどうか」「このインスタンスは〜できる権限があるかどうか」というのをこのIAMの権限を見て判定している。

この場合はユーザーではなく「ロール」に「ポリシー」をつけて、その「ロール」をEC2インスタンスにつけてやる必要がある。

EC2からCodeCommitのcloneを行いたい場合

CodeCommit から git clone を行いたい場合、

  • AWSCodeCommitReadOnly の権限を持つロールを作成する
  • そのロールをEC2につけてやる

ということが必要になる。

本当は「ロールをEC2につける」のではなく、「そのロールを持つインスタンスプロファイルを作成して、そのインスタンスプロファイルをEC2につける」というのが正確っぽいが、インスタンスプロファイルはあんまり意識しなくてもいい。*1

CloudFormationで表現する

ロールを作る→そのロールを持つプロファイルを作成する→プロファイルをインスタンスにくっつける ということをする。

  # CodeCommitからReadができるロール 
  CodeCommitRole: 
    Type: AWS::IAM::Role 
    Properties: 
      AssumeRolePolicyDocument: 
        Version: '2012-10-17' 
        Statement: 
        - Effect: Allow 
          Principal: 
            Service: 
            - ec2.amazonaws.com 
          Action: 
          - sts:AssumeRole 
      ManagedPolicyArns: 
        - arn:aws:iam::aws:policy/AWSCodeCommitReadOnly 

AssumeRolePolicyDocumentPrincipal で指定されているサービスから CodeCommit の ReadOnly を許可する的な意味。AssumeRolePolicyDocument については深入りするとわからなくなってくるので、一旦ここは雰囲気だけ捉えて終わっておくことにする...

ManagedPolicyArns にこのロールが持つポリシーを指定する。AWSコンソールのIAMでポリシーを検索してクリックすると「ポリシーARN」というのが見られるのでこれを書く。

ポリシー ARN
ポリシー ARN

次にこのロールを持ったインスタンスプロファイルを作成する。

  CodeCommitProfile: 
    Type: AWS::IAM::InstanceProfile 
    Properties: 
      Roles: 
      - Ref: CodeCommitRole 
    DependsOn: 
    - CodeCommitRole 

PropertiesRoles で先ほど作成した CodeCommitRole を割り当ててやる。

DependsOn にも CodeCommitRole を書いてやる。これは CodeCommitRole の作成が終わってからこの処理をしてねということだ。*2

最後にEC2にインスタンスプロファイルを割り当ててやる。

  AsadaigakuDevWeb: 
    Type : AWS::EC2::Instance 
    Properties: 
      # InstanceProfile以外のパラメータは略
      IamInstanceProfile: !Ref AsadaigakuDevWebProfile 

これでEC2の権限追加は完了。

git config

続いてEC2上にインストールされているgitの設定を追加してやる必要がある。これを追加してやると、公開鍵の登録だとか、パスワード認証などが不要で CodeCommit から git clone できるようになる。

git config --global credential.helper '!aws --region us-east-1 codecommit credential-helper $@' 
git config --global credential.UseHttpPath true 

最初の credential.helper の設定に --region は常に us-east-1 でいい(もしかしたら us-east-1 以外でもいいのかもしれない)。

これで CodeCommit から HTTPS のパスをコピーして git clone できるようになった。

*1:もっと複雑なことをやろうとしたら意識する必要があるのかもしれない

*2:CloudFormationは基本的にyamlの順番にかかわらず並列処理でリソースが作成されるので、場合によってはこのようにDependsOnを書く必要がある