CI/CD on ゲンゾウ用ポストイット

OIDCを使ってGithub ActionsからAWSにアクセスする仕組みについて理解を整理してみた

Wed, 16 Aug 2023 17:47:45 +0900

はじめに

Github Actions から AWS クラウドリソースを操作するためにACCESS_KEY、SECRET_ACCESS_KEYを使う方法はもう古い、OIDCを使うのが一般的といわれましたが理解していなかったため整理しました。

検証環境

今回取り上げる CI/CD ( ビルド ) パイプライン は Github Actions に限定しています。

クラウドプロバイダー に関しても、 AWS に限定しています。

ただしアーキテクチャはCI/CDパイプラインがCircleCIやCloudBuild、クラウドプロバイダーがGCPやAzureに置き換えられたとしても適用可能なものと考えられます。

パスワードやアクセストークンを使ってGithub Actionsからクラウドへ認証する方法の問題点

Github ActionsのようなCI/CDパイプラインから、クラウド環境 ( AWS、Azure、GCP… ) にアクセスするケースは多いはずです。

ビルドされたソフトウェアやコンテナイメージはいずれデプロイされますし、デプロイ環境としてクラウド環境 ( ex: AWS ) が利用されることが多いからです。

Github Actionsがクラウド上のリソースにアクセスするために、事前にパスワードやアクセストークンといった認証情報を取得しておく必要があります。

これらの認証情報はGithubの secrets に保存することが多いでしょう。 Github Actionsワークフローは実行のたびに secrets から認証情報を取り出し、これを使ってクラウド環境へのアクセスを可能にします。

しかし、このような secrets を使う方法には問題があります。以下のような手間が発生します。

クラウド上のIAMサービスで認証情報を生成する
生成した認証情報をGithubのsecretsに登録する

つまり、認証情報が二重管理されることになります 。

OIDC ( OpenID Connect ) を使うメリット

そこで登場するのがOIDC ( OpenID Connect ) です。

OIDCを使うと、Github Actionsワークフローがクラウドプロバイダーに対して要求するアクセストークンは、有効期限の短いものとなります。

もちろんOIDC認証による認証をサポートされているクラウドプロバイダーでしか利用できない方式ではありますが、現在はほとんどのクラウドプロバイダー ( AWS、Azune、GCP、HashiCorp Vault… ) がOIDCをサポートしています。

GCPにSpinnakerをインストールするための手順を整理しました

Fri, 12 Feb 2021 21:49:15 +0900

はじめに

前回でようやくSpinnakerが生まれてきた背景やできることを大まかにつかめました。

ここからは実際にインストールしてみたいと思います。

検証環境

項目	選定
クラウド	GCP ( Google Cloud Platform )
デプロイ環境	GKE ( Google Kubernetes Engine )
Spinnakerインストール環境	GCE ( Google Compute Engine )

前提条件

作業用PCで gcloud コマンド ( Google Cloud SDK ) が実行できること
GCP 上に GKEクラスタ が構築済みであること

作業用PC での作業

まずは自分の作業用PCで作業を行います。

1. コマンドラインから各種作業を実行するための準備

コマンドラインで作業を進めていくに当たり、いくつかのAPIを 有効化 します。

以下の2つの Google APIを有効にします。 Google Cloud Console Webページから有効にしても良いですが、ここでは gcloud コマンドで有効化します。

1
2
3


$ gcloud services enable \
 iam.googleapis.com \
 cloudresourcemanager.googleapis.com

2. Halyardをインストールする Compute Engine インスタンスを作成

Halyard をインストールする Compute Engineインスタンス を作成します。

本番環境で環境依存の問題が散見されたのでSpinnakerの導入を検討してみました

Thu, 11 Feb 2021 08:00:37 +0900

はじめに

会社で、 検証環境 では障害が発生しないが 本番環境 では障害が発生する、といったことが何度か続きました。

原因は 検証環境 と 本番環境 のクラウドサービスの設定の差異でした。再現性のある方法でクラウド上の環境を構築してこなかったことが原因ではありますが、できてしまっているものはしょうがないです。

「カナリアデプロイ」 と呼ばれる、 本番環境 に部分的にデプロイして動作確認し、問題なければ全展開するデプロイ方法があります。これはぜひ導入したい！そこで見つけた名前が Spinnaker でした。

Spinnakerを使って「カナリアデプロイ」が実現できる、という話を耳にしたので調べてみました。

graph LR;
 load_balancer-->|95% Traffics| web_server(Web Server);
 load_balancer-->|5% Traffics| new_web_server(Web Server); subgraph Old
 web_server-->applicacion_server(Application Server)
 applicacion_server(Application Server)-->database(Database);
 end 
 subgraph New
 new_web_server-->new_applicacion_server(Application Server)
 new_applicacion_server(Application Server)-->new_database(Database);
 end

継続的インテグレーション( CI )

素早いソフトウェアの改善・改良や新機能追加が求められる時代がありました。（当時は僕もJavaばっかり触っていました。）

当時、開発された分割モジュールを統合してビルドすると、、、

ビルドに失敗する！
正常に動作しない！

なんてことはよくありました。

そこで偉い人？が「開発の早い段階から継続的に以下のステップを実施すればいいんじゃね？」と考えました。

コードチェック
ビルド
ユニットテスト

こうして、継続的インテグレーション(CI)が誕生しました。

継続的デリバリ( CD )

更に時が過ぎ、「継続的インテグレーション」を更に推し進める思想が生まれました。

偉い人？が「ソフトウェアのデプロイも継続的に、自動的に行ったらいいんじゃね？」と考えました。

こうして、継続的デリバリ(CD)が誕生しました。

ちなみに、 「継続的デリバリ」 を行うためには、以下の2つが必要となります。

ビルドされたパッケージ
パッケージを運用環境にデプロイする手段

それを踏まえて、昨今の状況の話に移ります。