Terraform Auth0 Modulesの紹介

本記事は「Introducing Terraform Auth0 Modules」を翻訳した記事です。

Auth0上でB2B(Business-to-Business)SaaS(Software-as-a-Service)を構築するチームは、多くの場合同じアイデンティティ基盤を必要とします。

• アプリケーションとAPI
• ロールと権限
• M2M(Machine-to-Machine)クライアント
• 多要素認証(MFA)
• 攻撃保護
• ブランディング
• カスタムログインドメイン
• エンタープライズシングルサインオン(SSO)を備えたOrganizations

長年にわたり、多くのチームがAuth0 Terraform Providerを使用してアイデンティティ基盤を構築してきました。各チームは同じ設定の独自バージョンを記述し、保守しています。

Terraform Auth0 Modulesは、プロバイダー上に構築された既製のモジュールにアイデンティティ基盤をパッケージ化します。最初のモジュールであるb2b-saas-starterは、現在Terraform Registryで利用可能です。

Auth0上でB2Bアプリケーションを管理する開発者やプラットフォームエンジニアにとって、本記事は役立ちます。以下の方法を学びます。

• 1つのモジュールブロックで完全なアイデンティティ設定を作成する
• モジュールが適用するセキュリティのデフォルト設定を使用する
• 顧客向けにロール、権限、エンタープライズSSOを追加する
• カスタムログインドメインを段階的に有効化する
• 1つのテナントで複数のアプリケーションを実行する

前提条件

進めるには以下が必要です。

• Terraform 1.3.0以降
• Auth0テナント。モジュールはMFAや攻撃保護などのテナント全体の設定を管理するため、新しい開発用テナントが最適です。
• Auth0 Management APIの認可を受けたM2Mアプリケーションと、ドメイン、クライアントID、クライアントシークレット

まだAuth0アカウントを持っていない場合 無料でサインアップし、開発用テナントを作成してモジュールを試してください。

1つのモジュールブロックで始める

新しく空のディレクトリを作成し、以下の設定を追加します。ロールベースアクセス制御(RBAC)で保護されたアプリケーションクライアントとAPIを作成し、MFAと攻撃保護のテナント全体のセキュリティ設定を適用します。

# main.tf 
module "b2b_saas" { 
 source  = "auth0/modules/auth0//modules/b2b-saas-starter" 
 version = "~> 1.0"

 app_name        = "Acme" 
 app_callbacks   = ["https://app.acme.com/callback"]
 app_logout_urls = ["https://app.acme.com"] 
 app_origins     = ["https://app.acme.com"]

 api_name       = "Acme API" 
 api_identifier = "https://api.acme.com" 
}

次に、M2Mアプリケーションからプロバイダーの認証情報を設定し、変更をプレビューします。

# terminal 
export AUTH0_DOMAIN="your-tenant.auth0.com" 
export AUTH0_CLIENT_ID="..." 
export AUTH0_CLIENT_SECRET="..."

terraform init
terraform plan

プランには5つのリソースがリストされます。

1. アプリケーションクライアント
2. API
3. テナント設定
4. 攻撃保護
5. MFA

Auth0 Terraform ProviderはMFAリソースをauth0_guardianと名付けます。プランを確認し、terraform applyを実行してリソースを作成します。

設定不要なセキュリティのデフォルト

重要なアイデンティティ設定は見落とされがちです。モジュールは設定を有効にします。

• APIでのRBACの強制。 RBACを強制しない場合、Auth0はロールや権限を持たないアクセストークンを発行するため、APIはユーザーに許可された操作を確認できません。モジュールは強制を有効にし、アクセストークンに権限を含めます。
• アプリケーションのPKCE(Proof Key for Code Exchange)とリフレッシュトークンのローテーション。 シングルページアプリケーション(SPA)からの並行したリフレッシュリクエストが失敗しないように、3秒の猶予期間を設けます。
• 攻撃保護。 ブルートフォース保護、不審なIPの制限、漏洩パスワード検出を備え、それぞれしきい値を設定できます。
• MFA。 TOTP(Time-based One-Time Password)を有効にし、オプションとしてメールとリカバリーコードを利用できます。

プランの出力では、APIリソースにenforce_policies = trueとtoken_dialect = "access_token_authz"が表示されます。2つの設定によりRBACが有効になり、アクセストークンに権限が追加されます。

モジュールの入力ですべてのデフォルトを上書きできます。

プレーンデータとしてのロールと権限

B2Bアプリケーションでは、多くの場合APIの次にロールと権限を追加します。モジュールを使用すると、モジュールブロック内のデータとして記述できます。

# main.tf (inside the module block)
 roles = ["admin", "member"]
 permissions = { 
   admin  = ["read:projects", "write:projects", "manage:members"] 
   member = ["read:projects"]
 }

モジュールは各ロールを作成し、APIに各権限を登録して、ロールに権限を割り当てます。また、入力もチェックします。宣言していないロールを権限が参照している場合、Auth0で変更が行われる前にterraform planがエラーで停止します。

各顧客組織のエンタープライズSSO

ビジネス顧客は多くの場合、独自のアイデンティティプロバイダーでログインすることを望みます。Auth0 Organizationsを使用すると、各顧客は別々の組織を取得し、モジュールは組織のSSO接続を作成できます。

# main.tf (inside the module block) 
 organizations = [ 
   { 
     name         = "globex-corp" 
     display_name = "Globex Corp" 
     connection = {` 
       type             = "samlp" 
       domain_aliases   = ["globex.com"] 
       sign_in_endpoint = "https://idp.globex.com/sso" 
       signing_cert     = file("globex-cert.pem") 
     } 
   } 
 ]

例では、globex.comのメールアドレスを持つユーザーはGlobexアイデンティティプロバイダーを通じてログインします。samlpという値はSAML(Security Assertion Markup Language)接続を選択します。OIDC(OpenID Connect)の場合は、type = "oidc"を設定し、アイデンティティプロバイダーのクライアントID、クライアントシークレット、ディスカバリーURLを追加します。各組織はログインページに独自のロゴと色を持つこともできます。

新しい顧客をオンボーディングするには、リストにエントリを追加して変更を適用します。

明確な手順でのカスタムドメイン

login.acme.comのようなカスタムログインドメインは、ユーザーをブランドに留めます。Auth0はDNS(Domain Name System)レコードが有効になった後にのみドメインを検証できるため、モジュールは適用中の失敗を避けるために設定を段階的に分割します。

1. custom_domainを設定します。最初の適用でドメインを作成し、追加するDNSレコードをdns_verification_record出力で返します。
2. DNSプロバイダーにレコードを追加します。dns_verification_command出力のコマンドを使用して、レコードが解決されることを確認します。
3. enable_custom_domain_verification = trueを設定し、再度適用してドメインを検証し有効化します。

各ステップで、custom_domain_next_step出力が次にすべきことを説明します。

TerraformでDNSレコードを管理している場合、モジュールは1回の適用でドメインを検証できます。カスタムドメインの例で方法を示しています。

1つのテナントに複数のアプリケーション

製品の成長に伴い、同じテナントに管理ポータルや2つ目のアプリケーションを追加する場合があります。各テナントにはテナント設定、MFA設定、攻撃保護設定が1セットしかないため、1つのモジュールインスタンスのみが設定を管理する必要があります。他のすべてのインスタンスではmanage_*入力を使用します。

# admin.tf 
module "admin_portal" { 
 source  = "auth0/modules/auth0//modules/b2b-saas-starter" 
 version = "~> 1.0"

 app_name        = "Acme Admin" 
 app_callbacks   = ["https://admin.acme.com/callback"] 
 app_logout_urls = ["https://admin.acme.com"] 
 app_origins     = ["https://admin.acme.com"]

 manage_tenant            = false 
 manage_attack_protection = false 
 manage_mfa               = false 
}

最初のモジュールインスタンスはテナント全体の設定の所有権を保持します。インスタンスは管理ポータルのリソースのみを追加します。

設定の完全な制御も維持します。Actionsや追加のクライアントグラントなどの他のプロバイダーリソースをモジュールの横に追加し、自分で管理したいモジュールの部分をオフにします。

例を探索する

リポジトリにはすぐに実行できる12の例が含まれています。各例は1つの機能を追加するため、モジュールを段階的に学習したり、自分の設定に最も近いものから始めたりできます。

• 最小構成: ローカル開発用のSPAクライアント
• APIとRBAC: ロールとスコープ付き権限を持つ保護されたAPI
• エンタープライズSSO: 1つのテナントにSAML、OIDC、および混在したSSOを持つ複数の組織
• 複数のアプリケーション: 1つのテナントに2つのアプリケーションと2つのモジュールインスタンス
• 完全構成: モジュールのすべての機能

モジュールでB2Bアイデンティティを確立する

Terraform Auth0 Modulesは、Auth0上のB2Bアイデンティティのテスト済み開始点を提供します。

• 1つのモジュールブロックで、アプリケーションからエンタープライズSSOまで完全なアイデンティティ基盤を作成する
• RBAC、トークン、MFA、攻撃保護のセキュリティデフォルトが最初の適用から有効になる
• 1つのアプリケーションから複数のアプリケーション、多くの顧客組織へと、製品とともにモジュールが成長する

最初のモジュールであり、オープンソースです。必要な設定、再構築し続けるパターン、新しいモジュールのアイデアなど、フィードバックが次を決定します。

• Terraform Registryでb2b-saas-starterモジュールから始める
• GitHubですぐに実行できる例を探索する
• リポジトリで機能をリクエストするかバグを報告する

モジュールが役立つ場合は、リポジトリにスターをつけると他の開発者が見つけやすくなります。

参考資料

• Auth0 Terraform Providerのドキュメント
• Auth0 Organizationsのドキュメント
• Auth0のロールベースアクセス制御のドキュメント