こんにちは!スマートバンクでSREをしている @maaaato です。
スマートバンクではVisaプリペイドカードを発行しており、PCI DSSというクレジットカード業界のセキュリティ基準を取得しています。
PCI DSSの要件には定期的に対応を必要とするものがあり、例えば90日毎にパスワードの変更を実施する(要件8 システムコンボーネントへのアクセスを識別・認証する)といった要件があります。
PCI DSSの更新時には対応したエビデンスを提出する必要があり、スマートバンクではGitHubに対応する要件のIssuesを作成しエビデンスとしています。
定期的にGitHubにIssuesを作成する必要があるのですが、これまで温かみのある手作業で作成していました。手動である必要はなく、「頻度も低いのでパッと作っちゃうか」という理由です。とはいっても対応する要件の件数が1つ2つではないのでめんどうな作業でした。まさにThis is Toilです。
そこでGitHub Actionsを利用して定期的にIssuesを作成するように対応をしました。
小さなトイルを減らそう
PCI DSSの対応が発生するタイミングは以下の通りです。
- 90日毎(四半期)
・ パスワードの変更や不要なアカウントが存在していないか確認 - 半年毎
・ PCI DSSの適応範囲のセグメントから別セグメント(逆のパターンも)へのネットワークレベルでの接続確認 - 一年毎
・ インシデントが発生した場合における訓練の実施
全体の作業の一部のみを記載しており本来は他にもあります。
どれも次に対応するまでの期間が長くその都度手動でIssuesを作成していましたが、一年毎の対応ですと20個近いIssuesの作成が必要となります。
繰り返す作業で自動化できるものは自動化したい欲が湧いてきました。
Issuesを作成するGitHub Actionsが複数あった
自分はGitHub Actionsに明るい方ではなかったので社内のSlackに「Issuesを自動的に作成したいがいい方法はないか?」と聞いてみたところ、すぐに返信があり、Create an issueを教えてもらいました。 他にもないか調べてみると似たようなActionsにissue Bot Actionを見つけました。
今回やりたかったこと
今回やりたかったことは定期的にIssuesを自動作成することですが、親のIssuesに子のIssuesを紐づけたいと考えていました。
元々のIssuesの構成は四半期に対応する作業を子のIssuesとして作成し、それらを束ねる親のIssuesを作成し紐づけていました。この構成は親のIssuesを見れば残っているIssuesの確認が容易だったため踏襲したいと思っていました。
実現にあたって
結論から言うと親のIssuesに子のIssuesのNumberを埋め込むにはCreate an issueとissue Bot Actionを組み合わせる必要がありました。
Create an issueは作成したIssuesのNumberをstep.xxxx.output.number
で参照が可能ですが、Issue Bot Actionで作成した場合は参照が出来ませんでした。
Create an issueで作成するIssuesはIssueのtemplateの利用できますが、template内に外部から渡した変数を参照することが出来ません。しかし、Issue Bot Actionではbodyをyaml上に定義する事が出来るため、step.xxxx.output.number
を参照させて親のIssuesに子のIssuesのNumberを埋め込むようにしています。
それぞれの特徴を今回の要件にフォーカスしてまとめると以下の通りです。
GitHub Actions名 | IssuesのNumberの取得 | テンプレートへの変数の埋め込み |
---|---|---|
Create an Issue | ◯ | ✗ |
Issue Bot Action | ✗ | ✗だがyaml上でbodyを定義し参照が可能 |
実際にどのような定義になっているかyamlの記述内容の一部を以下に記載します。
name: 四半期毎のPCIDSS更新作業 on: schedule: # UTCで記載 - cron: 00 01 01 04,10 * workflow_dispatch: inputs: override: description: 'If you want to create issues, enter "true"' required: false default: "" jobs: create_issue: name: 四半期毎のPCI DSS更新作業 runs-on: ubuntu-latest steps: # Repo code checkout required if `template` is used - uses: actions/checkout@v3 - name: Generate GitHub Apps token id: generate uses: tibdex/github-app-token@v1 with: app_id: ${{ secrets.CREATE_ISSUES_BOT_APP_ID }} private_key: ${{ secrets.CREATE_ISSUES_BOT_PRIVATE_KEY }} - uses: JasonEtco/create-an-issue@v2 id: password-change with: filename: .github/ISSUE_TEMPLATE/request-issue-password-change.md env: GITHUB_TOKEN: ${{ steps.generate.outputs.token }} - name: Get current date id: date run: echo "::set-output name=date::$(date +'%Y/%m')" - uses: imjohnbo/issue-bot@3d96848fb5e9a4a473bb81ae62b4b4866a56e93a with: assignees: "maaaato" labels: "pcidss" title: "${{ steps.date.outputs.date }} 四半期毎のPCI DSS更新作業" body: | # 四半期ごと - パスワードの変更 8.2.4 - #${{ steps.password-change.outputs.number }} env: GITHUB_TOKEN: ${{ steps.generate.outputs.token }}
主要な部分を解説します。
id: password-change
はCreate an issueを利用してIssuesを作成しています。このIssueは子になります。また、テンプレートが利用できるのでIssuesのテンプレートを参照しています。
- uses: JasonEtco/create-an-issue@v2 id: password-change with: filename: .github/ISSUE_TEMPLATE/request-issue-password-change.md env: GITHUB_TOKEN: ${{ steps.generate.outputs.token }}
次にissue Bot Actionを利用している箇所ですがこれは親のIssuesになります。親のIssuesに子のIssuesのNumberを埋め込みたいのでbodyに#${{ steps.password-change.outputs.number }}
として紐づけを行っています。
- uses: imjohnbo/issue-bot@3d96848fb5e9a4a473bb81ae62b4b4866a56e93a with: assignees: "maaaato" labels: "pcidss" title: "${{ steps.date.outputs.date }} 四半期毎のPCI DSS更新作業" body: | # 四半期ごと - パスワードの変更 8.2.4 - #${{ steps.password-change.outputs.number }} env: GITHUB_TOKEN: ${{ steps.generate.outputs.token }}
2つのGitHub Actionsを組み合わせるのはいささか奇妙ではありますがこうすることでやりたかった事を実現しています。図に示すと以下の通りです。
GitHub Actionsをローカルで実行したいと思ったら
GitHub ActionsはデフォルトブランチにあるActionsを読み込むため、検証を行う場合にはリポジトリの設定からデフォルトブランチをトピックブランチに変更していました。これではなかなか手間になりますし、対象のリポジトリの更新が自分しかいなかったのでよかったものの、複数人で参照していると業務に支障が出てしまいます。
そこでactを利用しローカルマシンからGitHub Actionsの検証を行いました。2019年からあるツールなのと広く認知されているかと思いますのでこのブログでは名前の紹介のみとします。
最後に
2つのGitHub Actionsを組み合わせて小さなトイルを削減しました。PCI DSSにフォーカスした取り組みでしたが、それ以外の定期的な作業でIssuesを作成する場合は同じ仕組みを導入しています。
正直な話をするとどちらか1つのActionsで済むようにしたいと考えています。PRのチャンスだと思っているのでいい感じにできたらブログにしたいです。
このブログを書いた時点ではPCI DSS v3.2.1をベースにしていますが、現在SREチームでは2024年4月から適応されるv4.0に向けた対応に取り組んでいます。