ACS事業部亀崎です。神奈川県平塚出身者ということもあって、七夕はちょっと特別(平塚七夕まつりがちょっと有名なんです)。 ということで年に一度の七夕記念、になっているかわかりませんが、7月7日7時7分に投稿させて頂きます。
今回は知っている人は知っている、知らなかった人はぜひ活用してほしい GitHub Actions + GitHub Environments + OpenID Connect(OIDC) を組み合わせて、よりセキュアにAzure Resourceをプロビジョニングするお話です。
GitHub Environments
GitHub Actionsから複数の環境にリソースをプロビジョニングしたい、それぞれの環境に合わせた環境変数を指定したい。 そういうときにどのように定義されていますか? GitHub Environmentsはそうしたときに活用するとよい機能です。
「環境」ごとにシークレットや環境変数を指定できます。そしてこの環境名をGitHub Actionsで指定することでプロビジョニング先や利用する環境変数を切り替えることができます。
GitHub Environmentsの指定方法
repositoryの「settings」-「Environments」で追加・更新等を行うことができます。
初期状態は以下のようになっていると思いますので、「New environment」で新しい環境を作成します。
最初に環境名を指定します。
testという環境名を指定すると以下のような画面が表示されます。 ここで、その環境を利用可能なブランチ制限、シークレット、環境変数を指定することができます。
なお、リポジトリ制限のオプションは以下のようなものがあります。今回はとくにブランチ制限は設けないものとします。
ここにシークレットを指定すると以下のような状態になります。(ここでは AZURE_TENANT_ID、AZURE_CLIENT_ID、AZURE_SUBSCRIPTION_ID という3つのシークレットを登録しました)
OIDCを使ってAzureに接続
もうひとつ、Azureにアクセスする際IDやパスワードはどのように登録していますか? パスワードを登録するのはできれば避けたいと思っていませんか?そうした場合に活用するのがOIDC接続です。
AzureのApp RegistrationとGitHub(今回はEnvironment)に、それぞれの身元情報を登録することで、パスワードを使用することなくアクセスできるようにするものです。
App RegistratoinとFedation資格情報の登録
Azure側の指定方法は、以下のとおりです。Azure AD管理画面でアプリケーションを登録します。そして、フェデレーション資格情報を登録します。
Federationの登録情報は以下のとおりとなります
なお、エンティティ型は用途に合わせて「環境」「ブランチ」「Pull Request」「タグ」を選択可能です。今回はGitHub Environmentsを利用するため、「環境」を指定しています。そして、環境の値として、さきほどのGitHub Environmentsで作成した環境名(例えばtest)を指定します。
あとは、Azure Resourceを作成・更新するためにアプリケーションに適切なロールを割り当てておきましょう。(様々なリソースプロビジョニングを行うならば、サブスクリプションのContributor Roleを割り当てておきます) ここまでで、Azure側の登録は完了です。
Azure ApplicationのテナントID、Client ID、プロビジョニング先のサブスクリプションIDをメモします。
そして、それらをGitHub Environmentsのシークレットとして登録しておきます(環境変数でも機能しますが、認証に関連する情報ということでシークレットに登録します)。登録した結果がさきほどのGitHub EnvironmentsのところのAZURE_XXXになります。
この両者を組み合わせ
さて、これらの指定を行ったならば、あとはプロビジョニングの実行です。 今回は、手動でGitHub Actionsを起動するようにします。その際、プロビジョニング先のGitHub Environement名を指定するようにしました。これで、いつでも、好きな環境に、パスワードを使用することなく、GitHub Actionsからプロビジョニングすることができます。
AzureへのProvisioningするには azure/login@v1
を利用します。ここで TenantID/ClientID/SubscriptionID
を指定します。最初に説明したようにOIDCを利用しているため、パスワードは指定せずに利用できます。ポイントは permissions.id-token/contens の指定の部分です。この指定でOIDCで内部で認証部分を処理できるようになります。
そのプロビジョニング先のサブスクリプションや環境変数は jobs.provisioning.environment
で決定されます。
どの環境にプロビジョニングするにも同じActionを利用できるのは、今後のメンテナンス等でも修正漏れなどを起こすことがなく、安全です。
name: Provisioning resource group on: workflow_dispatch: inputs: environment: description: 'Environment to deploy to' required: true default: test type: choice options: - test - another-test permissions: id-token: write contents: read jobs: provisioning: name: Resource Provisioning runs-on: ubuntu-latest environment: ${{ github.event.inputs.environment }} # プロビジョニングするGitHub Environement名を指定します。 steps: - uses: actions/checkout@v3 - name: 'Az CLI login' uses: azure/login@v1 with: client-id: ${{ secrets.AZURE_CLIENT_ID }} tenant-id: ${{ secrets.AZURE_TENANT_ID }} subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }} - name: 'Deploy bicep resources' uses: azure/arm-deploy@v1 with: scope: 'subscription' deploymentName: infra-provisioning-${{ github.event.inputs.environment }} template: ./infra/main.bicep region: japaneast
なお、infra/main.bicepは通常利用するbicepファイルと同じものです。
Backstage上でも表示
実はこのEnvironementを通じたプロビジョニング結果は先日来ご紹介しているBackstage上にも表示できます。
Backstageを使えば、Issue / Pull Request / Dependabot alert といった情報をまとめてみることができるので便利ですね。
最後に
ご紹介したGitHub EnvironementsやOIDCはすでにご利用の方も多くいらっしゃるかと思います。 今回は「まだ使ったことない」という方向けに、利用するまでの内容を画面をお見せしながら説明させていただきました。 この情報がなにかのお役に立てば幸いです。
また、Backstageと組み合わせることでさらに作業が効率化できます。ぜひご利用をご検討頂きたいと思います。