本記事のゴール
AWS CodeCommit (CodeCommit) というサービスはご存知でしょうか。昨今ですと、ソースコード管理には GitHub を使うケースも多いかと思いますが、適切でないユースケースで GitHub が使われており、セキュリティホールの温床になっているケースも散見されるのが実態です。本記事では GitHub よりも CodeCommit でソースコード管理すべきケースを明らかにし、導入の手順について簡単にご紹介します。
AWS CodeCommit とは？
CodeCommit とは、AWS の提供するサービスで、端的には Git リポジトリサービスの 1 つです。他の Git リポジトリサービスと比較して、以下のような特性があります。
- リポジトリは基本プライベート
- AWS IAM でユーザ管理可能
- AWS サービスとの親和性が高い
２ 点目、3 点目は AWS のサービスなのでそのとおりですが、1 点目のリポジトリが基本プライベートであるという点が最も重要なポイントになります。
GitHub の誤った使い方とセキュリティ
企業のプログラム資産を管理しているリポジトリを誤って public に
すごく初歩的な誤りとして、企業でのコード管理、変更管理に GitHub を使っているようなユースケースで、誤って public リポジトリに上げてしまうリスクというのはあるかと思います。とはいえ、さすがに public リポジトリに上げたまま誰もいつまでも気が付かないというリスク自体はそこまで高くないと思います。
こちらの事件はいかがでしょうか。これはエンジニアの方で年収診断のために客先のために実装した自身のコードの一部を (そのままではないのかもしれないですが) public リポジトリに上げたというもので、当然エンジニア自身に責任は発生すると思います。一方で、年収診断を提供しているサービス側も、これについては「単なるソースコード診断をするだけなら GitHub の public リポジトリを使わずプライベートな場所にソースコードをアップロードさせる」もしくは「OSS活動、ソーシャルコーディングが年収診断の対象で、単なるコードが年収診断の対象でないのなら利用者へのガイダンスを丁寧なものにする」ことで同様の事件が回避できそうにも思いました。
秘匿性の高い情報を public リポジトリにアップロードしてしまう
個々の資産、情報レベルになると、本来公開してはいけないものが public リポジトリにでも上がってしまうものです。たとえばオープンソースで組んでいる AWS 上にデプロイするサービスのリポジトリに、AWS のキーペアを含めてしまう事例等。
AWS のキーペアを GitHub の public リポジトリにアップロードするのは極めて危険です。AWS を不正利用するために、攻撃者のクローラーが 24 時間 365 日動いています。こちらの記事によると、キーペアを push してからわずか 13 分で攻撃を受けたとのこと。
GitHub の規約にも注意
まずはこちら (GitHub の利用規約) をご覧ください。
1 人の個人または 1 つの法人が複数の無料「アカウント」を保持することはできません
GitHub利用規約
GitHub は、こちらに書かれているとおり2020 年 4 月に、無料プランでの private リポジトリのコラボレータの数の制限を撤廃しました。このことで、企業でも無料プランが使いやすくなったのですが、利用の最大の障壁となるのが上記の規約になります。
もしチームにプライベートでソーシャルコーディング、OSS 活動を行っているメンバーがいる場合、そのメンバーは企業の GitHub に参加できません。あるいは、知らず識らずのうちに規約違反し参加してしまっているかもしれません。一般に、ソーシャルコーディング、OSS 活動を行っているメンバーは高スキル者であることが予測されるため、そのメンバーが参加不能は致命的なはずです。
それでなくても、大企業となると複数組織になって、組織ごとにアカウントを取得してしまうとかで利用規約を踏んでしまいがちです。
AWS CodeCommit と GitHub の使い分け
これまでの議論を踏まえ、CodeCommit と GitHub を目的に応じて使い分けていくことをおすすめします。私の個人の見解だと以下のとおりです:
| カテゴリ | ユースケース | 使用するツール |
| 個人利用 (プライベート) | ソーシャルコーディング、OSS 活動 (それに関連する年収診断)が目的の場合 | GitHub public リポジトリ |
| GitHub 周辺ツールの利用が必須な場合 | GitHub private リポジトリ | |
| AWS 上で動くサービス、システムの開発に用いる場合 | CodeCommit | |
| 法人利用 | AWS 上で動くサービス、システムの開発に用いる場合 | CodeCommit |
| GitHub 周辺ツールの利用が必須な場合 | まずは周辺ツール含め代替手段がないか検討。なければ GitHub private リポジトリ |
当サイトの当カテゴリはあくまでプライベート利用がフォーカスですので、CodeCommit と GitHub の両方を上記の様な指針で使い分けていく説明をしますが、法人利用の場合はいったん企業のプログラム資産の管理に GitHub を使うのは避けるべしと言わざるを得ない状況です。
GitHub を活用するのは、筆者のケースですと周辺ツールを使うほど手の混んだ開発、大規模な開発をプライベートではやっておりませんので、まさしくソーシャルコーディング、OSS 活動のため、と考えています。
AWS CodeCommit の料金
大事なことを書きそびれかけましたが、CodeCommit の料金です。こちらによると、最初の 5 人のアクティブユーザーは、無料のようです。厳密には、ストレージが 50 GB まで、リクエストが 10,000 回/月までが無料枠です。ですので、プライベートで使う分には、ほぼ無料で使えます。
AWS アカウントがあり、特にソーシャルコーディング目的でない場合は AWS CodeCommit を使う方が利口といえそうです。
AWS CodeCommit の使用感
CodeCommit も基本は Git リポジトリサービスなので、git クライアントを使っての細かいアクセス等は説明を省略します。
まずは「リポジトリ」の画面から。
AWS、って感じですね。GitHubと比べると、アカウント回りや Organization 等がなく、シンプルだと思います。
お次はコードの画面。
シンプルです。Readme.md でリポジトリの説明を記載できるのは変わりません (この Readme.md、リポジトリ作成の際最初に master に push するケースが多いかと思うのですが、SF ファンの私はReamde.md と名前を付けたくなる衝動に駆られます笑、元ネタはこちら)。
次に、プルリクエストの作成画面です。
ソースブランチとターゲットブランチを選択して「比較」、後はタイトルと説明を記載してプルリクエストの作成、ですね。今回は画面キャプチャを入れてまで説明しないですが、「ブランチ」メニューから個別ブランチへ移動、そこで「プルリクエストの作成」をするとターゲットブランチは開いていたブランチが指定されますので、GitHub の使用感とほぼ変わりなし、です。
プルリクエスト作成の画面で、当然かもしれないですが diff も表示されます。
プルリクエスト一覧の画面も、シンプルですね。
マージ画面を見ていきましょう。
マージ戦略については、以下のようにご理解ください。
- 早送りマージ: GitHub の「Rebase and merge」の、rebase がないもの。なので、rebase が必要かどうかはプルリクエストを上げる側で見極め、必要に応じて git rebase の必要があります。
- スカッシュしてマージ: GitHub の「Squash and merge」と同じ挙動です。コミットをすっきりまとめられる反面、後戻りできなくなるので、こちらはあまり使わないパターンかと思います。
- 3 ウェイマージ: GitHub の「Create a merge commit」と同じです。
あと、デフォルトですとソースブランチが削除されるようになっているので、残す必要のあるブランチの場合は、チェックボックスからチェックを外すことをお忘れなく。
コミットメニューの中には、コミットビジュアライザーもあります。
ブランチメニュー画面です。
設定画面では「リポジトリ名」「リポジトリの説明」「デフォルトブランチ」が変更できました。
というわけで、シンプルな UI でしたが、プライベートリポジトリの運用、単なるソースコード管理、変更管理という意味では十分に感じています。
まとめ
知名度の点だけでソースコード管理ツールに GitHub が選ばれているケースがありそうですので、AWS CodeCommit 含め他のツールも十分検討の価値があることがお伝えしたいポイントとなります。当サイトでは主にプライベートでの利用がフォーカスであるものの、企業、お仕事でのソースコード管理もぜひ一考いただけるのでは良いかな、と考えています。
