AWS CodeConnections からGitLabに最小権限で安全に接続したい

AWS Code PipelineでFargate等にデプロイするときに、何をソースにするか問題があります。

CodeCommitが緩やかに廃止しそう

CodeCommitは非常に分かりやすくて便利だったのですが、新規ユーザの利用が制限されてしまいました。今のところOrganization以下に作った新アカウントでもリポジトリは作れるように見えますが、廃止に向かうサービスに依存するのもの怖いものです。

移行先として何があるでしょうか？自前でEC2などを管理しない、なるべくマネージドなものを前提にします。

• ECR
  • これは「手元でDockerビルドしてpush」とほぼイコールになりそうです。
  • シンプルで分かりやすいですが、デプロイ担当者のローカル環境に依存（ベースイメージをpullした日付など）するのと、ARMイメージをx86のPCでビルドする難易度が高いなどから、採用したくありません。
• S3
  • ソースコード一式をZIPで固めてCodeBuildでビルドすることになりそうです。
  • よく使う方法ではありますが、リビジョンが記録されず、なんというか力技感があります。最後の手段。
• Bitbucket / GitHub / GitLab
  • できればこれにしたい。

BPSではセルフホスティングのGitLabを使っているため、できればこれを使いたい。デプロイするときだけGitHubにpushとかは、権限設定が複雑すぎるし避けたいです。

IP制限をどうするか

CodeConnectionsが使うIPは固定されています。GitLab側でIP制限をかけている場合は、以下のIP（執筆時点）を許可します。

• 52.196.132.231
• 54.95.133.227
• 18.181.13.91

参考: 許可リストに追加する IP アドレス - デベロッパーツールコンソール

求められる権限が強い

ホスト登録時

「セルフマネージドへの接続 GitLabを作成する」に従ってセットアップしますが、最初に管理者権限のパーソナルトークンが要求されます。

スコープダウンされたアクセス許可のみを持つ GitLab 個人用アクセストークン (PAT) をすでに作成しておく必要があります。API。詳細については、https://docs.gitlab.com/ee/user/profile/personal_access_tokens.htmlを参照してください。を作成して使用するには、管理者である必要がありますPAT。
セルフマネージドへの接続 GitLabを作成するより

初期設定後に削除可能とは言え、気持ち悪いですね。

試したところ /api/v4/applications APIが呼ばれ、Application: AWS Connector for GitLab Self-Managed というGitLabアプリケーションが登録されていました。

※最初試したらその他にAWS CodeStarみたいな名前のユーザも作成されたのですが、気持ち悪いから削除してみて、もう1回試したら今度は作成されなかった...謎です。

登録されたアプリケーションを見てみると...権限が強すぎますね。ただリポジトリをcloneしたいだけなのに書き込み権限なんていらないでしょ！

気持ち悪いのでおもむろにチェックを外してやりましょう。お前には読み取り権限だけで十分です。

接続時

求めてくる権限が強すぎます。しかも自分で承認すると全プロジェクトの権限を渡すことになってしまいます。嫌だよそんなの。

なお、先程の手順でアプリケーションの権限を減らしているとエラーが出ます。そりゃそうです。

URLをコピーして書き換えましょう。

# URL末尾のこれを
&scope=api+read_user+read_api+read_repository+write_repository

# こうする
&scope=read_api+read_repository

※こんなので大丈夫？と思って一応サポートに聞いてみましたが、それによって使えない機能が生じるのを気にしなければOKという感じの返答だったので、自己責任の範囲ですが大丈夫そうです。

こうしても、全プロジェクトへの権限になってしまうのは宜しくないので、先にGitLab側で特定プロジェクトの読み取り権限だけを持つユーザを作り、それでOAuthすることにします。AWSマネジメントコンソールでログインしているブラウザで、この読み取りユーザにログインし直す必要があるのが少し手間です。

これで、一応接続はできました。あまり試していませんが、CodeBuildのsourceフェーズは成功したようなので多分大丈夫でしょう。

なお、apiスコープを付けていないので、GitLab側から通知を登録するような処理が行われず、GitLab側でマージしたら自動でパイプライン起動、とかはできません。それをやりたければもうひと工夫必要そう。

アプリ毎回作るの？

別のAWSアカウントで同じことをやる場合、最初の管理者トークンでアプリケーションを作るところからやり直しになりそうです。そうするとGitLab側にApplication: AWS Connector for GitLab Self-Managedというアプリケーションが大量登録されます。どれがどれだか見分けるのは困難で、消せずに負債になりそう。

せめてもの緩和として、アプリケーションが作成されたらすぐにアプリケーション名にAWSアカウント番号などを入れておきましょう。

まとめ

やりたいことは「GitLabで管理しているソースコードからCode Pipelineを起動したい」「余計な権限は付けたくない」だけなのですが、想定より面倒が多いです。

CodeCommitを使って、GitLabからミラーリングしたり、CodeCommitにpushするのが一番安全かつ分かりやすいです。なぜCodeCommitを廃止しようとしているのか、理解に苦しみます。Pull Request的な機能とかは何もいらなくて、ただのベアリポジトリ機能で良いんですが...　是非とも思いとどまってほしいものです。

また、AWSに限らずですが、世のサービスプロバイダにおかれましては、もう少し最小権限の原則を尊重して頂けるとありがたいものです。利便性重視のデフォルトはもちろん良いのですが、強い権限を渡さないと初期設定から何も進まないとされてしまうと、どうしても怖いです。