Oktaをコードで管理するまで　Terraform × AI によるIaC実践録

はじめに

こんにちは、Sansan株式会社コーポレートシステム部の平野です。
普段はインフラエンジニアとして、社内インフラに関連する各種SaaSの設計・開発から運用まで担当しています。
前職ではSIerにて、クレジット業界向けシステムのSREエンジニアとして、システムの信頼性や運用性を高める仕事に携わっていました。
そのときに培った、プロダクト開発では当たり前になっているIaCや自動化の知見を、情シスというフィールドで生かせないかと考え、現在の業務にも積極的に取り入れています。

今回のテーマにしたのは、社員の認証・認可まわりを担っているOktaの運用についてです。
担当領域の中でもインフラ・セキュリティの両面で重要度が高く、TerraformやAIとの相性も良さそうだったことから、IaC化に取り組んでみました。
この記事ではOktaをIaC化しようと考えた背景、実際の進め方、そして今後の目指す方向についてご紹介します。

なぜOktaのIaC化に取り組んだのか？

もともとOktaの運用では、入退社に関するアカウントの作成や無効化などはAPIを使った自動化ツールで対応していました。

ただ一方で、認証ポリシーやアプリケーション設定などセキュリティに関わるクリティカルな部分は、GUIでの手作業に頼っていたのが現状です。
設定変更の履歴については、GoogleスプレッドシートやNotionなどを活用して管理を行ってきました。しかし、運用の中で「誰が・いつ・何を・なぜ」変更したのか、すべての情報を正確に記録することは難しく、運用の複雑化に伴って将来的なリスクを懸念する声もあがっていました。そのため、より可視性の高い管理体制を構築する必要がありました。

私は前職でIaCに取り組んでいた経験があり、こうした課題は「コードで設定を管理する」ことで大きく改善できると感じていました。
最近では、GitHub CopilotなどのAIツールでコードを作成・レビューしたり、OpenAIのCodexやDevinといったAIエージェントを活用する動きも一般的になってきています。
ただし、それらを生かすには「コードベースであること」が前提です。
そう考えると、まずはOktaの設定そのものをコード化するところから始めるべきだという思いが強くなり、TerraformによるIaC化に着手しました。

どうやってOktaをIaC化したか

Terraformを選んだ理由は次の通りです：

チーム内にノウハウがある
- AWSなど他のサービスで既に活用していた実績がある
豊富な対応範囲
- マルチクラウドやSaaSに広く対応
- Okta用の公式Providerが存在
運用管理のしやすさ
- 宣言的なリソース定義により状態が可視化しやすい
- 変更管理が明確に行える

まず、Terraformのコード生成機能を活用するために、OktaのAPIを使ってリソース一覧を取得し、それをimport.tfとして出力するスクリプトを作成しました。

例
API: GET https://${okta_domain}/api/v1/policies
---
[
  {
    "type": "OKTA_SIGN_ON",
    "id": "policyId",
    "status": "ACTIVE",
    "name": "Policy name",
    "description": "Policy description",
    "priority": 1,
    "system": true,
    "conditions": {
      "people": {}
    },
    "created": "2024-04-25T17:35:02.000Z",
    "lastUpdated": "2024-04-25T17:35:02.000Z",
    "_links": {
      "self": {},
      "rules": {}
    }
  }
]
---

import.tf:
---
import {
  to = okta_app_signon_policy.${Fixed Policy name}
  id = "${policyId}"
}
---

このスクリプトにより、既存の設定をTerraform形式でまとめて取り込み、コードベースで扱えるように変換しました。
その後、terraform plan -generate-config-outコマンドを使ってコードを出力しましたが、一部パラメーターに誤りや不足があり、VSCode上でGitHub Copilotを補助に使いながらterraform planの出力と照らし合わせて細かく手修正していきました。
最終的には「terraform planでNo Changeになる状態」、つまりコードと実態が完全に一致した状態を実現しました。

TerraformによるOktaへのアクセスには、公式ドキュメントに沿ってOAuth 2.0を用いた認証方式を採用しています。
OktaのProviderがOAuth 2.0に対応しているため、スコープ制御など柔軟でセキュアな認証管理が可能になります。

こうして、Oktaの設定をコードで一元管理できるIaC体制を構築できました。

OktaのIaC化によって得られた変化とこれからの期待

TerraformでOktaの設定をコード化することで、当初さまざまな運用改善を期待していました。
取り組みを進める中で、すでに実感し始めている変化もあり、ここでは「期待していたこと」と「実際に得られたこと」をセットでご紹介します。

属人化の解消

もともとは、「誰がどの設定をどう変更したのか」を正確に把握するために、記憶やドキュメントに頼らざるを得なかった状況から脱却したいという課題意識がありました。
Terraformでのコード管理とPull Requestによるレビュー運用を組み合わせることで、すべての変更履歴がGitHub上に記録され、チーム内での情報共有や確認がしやすくなったと感じています。
設定の背景や意図もPull Requestの中でやりとりされるようになり、透明性と自律性の高い運用へと一歩ずつ近づいている実感があります。

設定ミスのリスク低減

設定変更時にterraform planを実行して差分を事前に確認するというフローを組み込むことで、GUI操作でありがちな「うっかり変更」や想定外の副作用を防げるようになることを期待していました。
実際、コードでの差分確認が定着してからは、変更の内容を事前に確認・議論できる場が増え、安心感のある変更運用が実現しつつあります。
今後はより高度な自動チェックやポリシー適用にも取り組み、さらなる信頼性の向上を目指していきたいと考えています。

運用効率の向上

Terraformコードの変更に連動して、CI上でterraform fmt、validate、planが実行され、差分確認〜レビュー〜適用までの一連の流れが半自動化されることに期待を持っていました。
この部分はすでに運用に乗っており、Pull Requestのレビュー時に自然と差分が可視化されることで、工数を抑えつつも確認の質を落とさない開発フローが実現できています。

さらに、日次でterraform planを自動実行し、差分が検出された場合にSlackへ通知が届く仕組みも導入しました。
これにより、Terraformのレビュー外で発生した変更も検知できるようになり、運用の抜け漏れ防止にもつながっています。

AIツールによる運用支援の可能性

OktaのIaC化と並行して、AIツールの活用にも取り組んでいます。それぞれのツールがコード生成、レビュー、ドキュメント化、ナレッジ共有と多面的に貢献してくれると感じています。

GitHub Copilot

Terraformのリソース定義や繰り返しパターンの補完を通じて、実装の初速向上や迷いの削減を期待しています。
構文や命名の統一といった設計品質の底上げにもつながっています。

CodeRabbit

AIベースのレビュー支援をPull Requestで導入することで、スタイルチェックや軽微な指摘を自動化できます。こうしてレビュー者は、設計意図や構成判断に専念できるようになります。

OpenAI Codex

自然言語による指示からコード生成、修正、説明までを自律的にこなすAIエージェント。開発プロセスの効率化だけでなく、透明性と安全性の向上にも寄与すると期待しています。

これらのAIツールを活用することで、開発体験そのものを進化させ、生産性と属人性のバランスを取れるチーム運用を実現していきたいと考えています。

OpenAI Codexの動作

当社では希望者に対してChatGPT Enterpriseアカウントが払い出されているため、執筆時点でリリースされたばかりのCodexを試してみました。
依頼したいこと: 特定のCustom admin roleへの権限追加依頼
プロンプト: Custom admin role: ${RoleName} にapplicationを編集する権限を付与したい

編集対象ファイルを指定しなくても、モジュール構成を理解した上で自動的に正しいファイルを見つけ出し、修正まで行ってくれました。
依頼内容に加えて、関連する修正候補を推測して提示してくれる点も非常に助かりました。実際、次のように追加の修正案にコメントを付け、編集の選択肢を広げてくれています。
Terraformにまだ慣れていないメンバーもいるチームにとって、こうした“気の利いた提案”まで含めた対応はとても助かっています。

If you want this role to manage specific apps, create a resource set and assign the role using the scoped_custom_role_assignment module (as done for other apps in role_assign.tf).

おわりに

Oktaの設定をTerraformでIaC化した取り組みは、単なる効率化にとどまらず、チームの運用スタイルそのものを見直すきっかけになりました。
コードを用いることで属人依存を減らし、運用の再現性や透明性を確保できるようになりました。

さらに、AIツールを活用することで、コード生成・レビュー・ナレッジ共有のあり方まで変わりつつあります。

情シスを「守りの運用」から「自走できるエンジニアリングチーム」へ進化させていく。

その一歩として、OktaのIaC化はとても良い題材でした。

これからもIaCとAIを武器に、よりプロダクティブで技術的に面白い情シス運用を追求していきたいと思います。
この記事を読んで、私たちの取り組みに少しでも共感していただけたなら、ぜひ一度カジュアルにお話ししませんか？
チームや業務内容、今後の展望について、ざっくばらんにご紹介できれば嬉しいです。

最後までお読みいただき、ありがとうございました。

Sansan技術本部ではカジュアル面談を実施しています

Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。

Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信