Skip to main content

前提条件

  • MySQL インスタンス(v8.0+)にアクセス可能な Kubernetes クラスター(v1.24 以降)
  • 最低限必要なクラスターリソース:4 vCPU、16GB RAM
  • テーブルに対する読み書きおよび削除権限を持つデータベース認証情報
  • Helm(バージョン 3.17.0 以降)
  • API、Console、IDP エンドポイント用のドメイン名

インストール手順

Authlete レジストリから Helm チャートおよびコンテナイメージにアクセスするには、以下の手順に従ってください。

セットアップフェーズ

1. 組織の作成

  • Authlete Console にログインします。
  • 自社用の組織を作成します。
  • Organization ID を控えておきます。
new-org

2. アクセスのリクエスト

  • Organization IDOrganization Name を Authlete サポートに共有します。
  • Authlete は、あなたの組織に対してレジストリアクセスを許可します。

3. 組織トークンの発行

  • Authlete Console にて、組織用の Token を発行します。
  • Organization IDToken は認証に必要なので手元に保持しておいてください。
user-permissions

準備フェーズ

1. Kubernetes ネームスペースの作成

2. Helm レジストリへのログイン

以下のコマンドを使用してログインします:
<ORG_ID> および <TOKEN> を実際の値に置き換えてください。 ログインが完了すると、レジストリから Helm チャートを取得できるようになります。

3. Helm チャートの取得

Authlete の Helm チャートは OCI フォーマットで配布されています。以下のコマンドでチャートを取得してローカルに展開します:

4. イメージレジストリの設定

Authlete のコンテナイメージへのアクセスには 2 つのオプションがあります: オプション A: 直接レジストリアクセス(開発/評価環境) 開発または評価目的の環境では、Authlete のレジストリから直接イメージを取得可能です:
オプション B: イメージのミラー(本番環境推奨) 本番環境では、イメージのミラー セクションを参照し、イメージをプライベートレジストリにミラーリングしてください。

5. イメージのミラー

信頼性と制御性を高めるため、Authlete 提供のコンテナイメージを自社のレジストリにミラーリングすることを推奨します。これにより、Authlete のレジストリへの直接依存を避け、再現性のあるデプロイが可能になります。
values.yaml を更新して、インストール前にミラーしたイメージパスを使用してください。 代替として、crane を使用してイメージを直接プッシュすることもできます。
crane を使用したミラー

設定フェーズ

1. Values とシークレットの設定

  • 既定の values.yaml はチャートに同梱されています。必要に応じて内容を確認・変更してください。
  • global.repo を自社レジストリに設定します。
  • ドメイン名を domains セクションに設定します:
重要: ドメイン名は初回インストール後に変更することができません。ドメイン名を変更する場合は、データベースを初期化し、Authlete を最初から再インストールする必要があります。インストール前に使用するドメイン名を慎重に決定してください。

2. TLS 証明書の設定

  • ドメイン用の TLS 証明書(例: Let’s Encrypt や社内の証明機関から取得)を用意し、authlete ネームスペースに kubernetes.io/tls タイプの Kubernetes シークレットを作成してください。証明書はすべてのドメイン(例: api.example.com、login.example.com、console.example.com)をカバーしている必要があります。ワイルドカードまたは SAN 証明書を使用できます。
注意: proxy-certsを外部シークレットマネージャーから管理する場合は、このステップを省略し、外部シークレットマネージャーのセクションをご参照ください。

3. データベースおよびメモリキャッシュへの TLS 接続を有効化 (任意)

アプリケーション設定
環境変数の変更だけで TLS 暗号化を有効化できます。 Redis: Redis 接続で TLS 暗号化を有効にするには、キャッシュ接続設定で tls: true を指定します。
Database: データベースへの TLS 接続は sslMode プロパティで有効化します。
注記: Redis やデータベースが提示する TLS 証明書がプライベート CA によって発行されている場合は、すべての証明書を含むカスタムバンドルを作成し、アプリケーションに読み込ませる必要があります。詳細は Private CA セクションを参照してください。

4. Private CA (Optional)

プライベート CA 証明書で TLS を使用するには、必要な証明書をすべて含むカスタムバンドルを Helm チャートの外部で作成します。次に、そのバンドルを含む ConfigMap を作成します。要件は以下のとおりです。
  • ConfigMap 名は “custom-ca-bundle” とすること
  • 少なくとも ca-bundle.p12ca-bundle.crt の 2 つのキーを含めること
CA バンドルの作成
trust-manager のドキュメント に記載の方法で公開 CA バンドルを抽出することを推奨します。以下では、そのバンドルを含む ConfigMap の作成方法を説明します。
trust-manager を使ったバンドル作成 (任意)
trust-manager を使うと、Kubernetes で信頼バンドルの管理が容易になります。インストール手順は trust-manager の公式ドキュメント を参照してください。trust-manager をインストールしたら、単一の Bundle オブジェクトを作成します。必要な証明書をすべて含む ConfigMap は自動的に生成されます。 以下は trust-manager が最終バンドルを組み立てるための Bundle の例です。この Bundle のマニフェストファイル名は bundle-creation.yaml とします。
最後に、次のコマンドで Bundle を作成します。
注記: cert-manager が提供する公式の Debian trust パッケージを使用している場合は、trust パッケージが最新に保たれているか定期的に確認してください。
バンドルの手動作成
以下の手順では、docker コマンドを使ってカスタムバンドルを数ステップで作成します。
注記: 以下のチュートリアルはサンプルコードです。バンドルの作成・保管・更新を安全に行うことはお客様の責務です。
  1. gen-bundles.sh ファイルを作成
  1. バンドルをビルド
  1. ca-bundle.p12ca-bundle.crt が準備できたら、次のように Kubernetes の ConfigMap を作成します。
注記: trust-manager のバンドル作成に使用されている現在の Debian ベースイメージは docker.io/library/debian:12-slim で、ca-certificates のターゲットバージョンは 20230311+deb12u1.6 です。
アプリケーションからカスタムバンドルを読み込む
バンドルの準備ができたら、アプリケーションから利用できるように追加設定を行います。.Values.global.tls.caBundle.enabled を “true” に設定して、バンドルをアプリケーションの Pod にマウントします。
バンドルの更新
新しいバンドルを作成して既存のものと置き換えた場合は、IdP、Authlete Server、プロキシの各 Pod (アプリケーション) を再起動してください。再起動時に、アプリケーションが更新後のバンドルを読み込みます。

5. データベース接続を設定

本プラットフォームは 2 つのデータベースを必要とします。1 つは API サーバー用、もう 1 つは IdP サーバー用です。secret-values.yaml で接続情報を設定します。
注記: MySQL 8.0+ を使用する場合、データベースは次の設定で構成してください:
  • 文字セット: utf8mb4
  • 照合順序: utf8mb4_0900_ai_ci
  • チャートアーカイブには secret-values.yaml のテンプレートも同梱されています。データベースおよび Authlete 管理者の資格情報に合わせて修正してください。
※ AWS-EKSでMySQLデータベースのDNS名を使用される場合: ・RDS-Proxyを使用する場合:host: sample-db.proxy-stu901vwx234.us-east-1.rds.amazonaws.com ・RDS-Proxyを使用しない場合:host: sample-db.cluster-stu901vwx234.us-east-1.rds.amazonaws.com

6. キャッシュの設定

以下が現在サポートされているキャッシュソリューション:
マネージドキャッシュサービス
本番環境ではマネージドキャッシュサービスの利用を推奨します。以下のサービスに対応しています:
  • Google Cloud Platform:Memorystore for Valkey
  • Amazon Web Services:ElastiCache for Redis or Serverless-Valkey
  • Azure:Azure Cache for Redis
GCP 利用者への注意:Memorystore for Valkey を使用する際は、Private Service Connect(PSC)とサービス接続ポリシーを利用した接続を推奨します。これがサポートされている唯一のネットワーク方式です。詳細な手順は Memorystore for Valkey ネットワーク構成ガイド を参照してください。
マネージドキャッシュサービスを使用するには、values.yamlを下記の通りに編集します:
注意:キャッシュサービスがクラスターモードの場合は providercluster に設定してください:

7. メンテナンスタスクの設定

プラットフォームの安定性を維持し、不要なストレージの使用を避けながら最適なパフォーマンスを確保するためには、定期的なメンテナンスタスクを実行する必要があります。以下の項目を確認してください。
データのクリーンアップ
AuthletはOAuth 2.0およびOpenID Connectトランザクションを大量に処理しているため、期限切れのトークンや認可コードなどのような一時的な項目が蓄積されていきます。APIスループットを最大化し、またランタイム操作中のパフォーマンスを確保するため、Authleteは期限切れの項目に対して、有効期限を過ぎた直後に削除せず、期限切れのフラグを立て、このクリーンアップタスクの対象として削除します。管理をしなかった場合、このデータの肥大化はデータベースクエリのパフォーマンスの低下、および過剰なストレージの消費に繋がってしまうリスクがあります。 クリーンアップタスクを定期的に実行し、期限切れまたは削除されたすべてのレコードに対して、物理的な削除を行う必要があります。そうするには、values.yml内にある下記のセクションを修正し、プロセスの実行時刻を指定してください。scheduleプロパティはKubernetesのスケジュール形式を使用します。
重要: 本番環境では、クリーンアッププロセスをピーク時間外(例:現地時刻で午前2時)に1日1回以上実行することをお勧めします。
専用APIインスタンスの使用
Authlete APIを通してデータ削除を実行するメンテナンスタスクは、データ削除を行うインスタンスへほとんど影響を与えないように設計されています。ただし、一部の環境においては、顧客リクエストを処理するAPIインスタンスを使用して、メンテナンスタスクを実行しない方が良い場合もあります。その場合、メンテナンスタスク専用のAPIコピーをデプロイするdeployApiSidecar: trueオプションを有効にすることをお勧めします。有効化した場合は、追加リソースがかかりますので注意してください。

8. HSM設定

AuthleteはGoogle Cloud HSMとAWS KMSをサポートしています。使用する場合は以下を参照してください。 Google CloudHSMの場合:
AWS KMSの場合:

9. 外部シークレットマネージャー

外部シークレットマネージャーを使用する場合、Helmデプロイに必要なシークレットがクラスター上に存在し、適切に構成されている必要があります。シークレットが見つからない場合は、デプロイおよびアップグレードの工程が失敗します。 必要なシークレットはauthlete-credentialsproxy-certsproxy-certsを外部シークレットマネージャーで管理する場合)です。
外部シークレットマネージャーにauthlete-secretのシークレットを追加します。
Cache Authが無効の場合:
Cache Authが有効の場合:
外部シークレットマネージャーでプロキシ証明書(proxy-certs)を管理する場合は、authlete-proxy-secretのシークレットを作成してください
注意: HelmチャートのexternalSecrets機能を有効化する場合は、values.yamlを下記のように更新して下さい。

10. Podアフィニティの設定

Podアフィニティを有効化するには、values.yamlを下記のように編集してください:
apiAffinityはデフォルトとしてfalseに設定されており、その場合podアフィニティは無効になります。 Podアフィニティを有効化することによって、API podと同じノードに存在するプロキシpodをスケジューリングすることが可能になり、パーフォーマンスを向上させ、またネットワークレイテンシーを軽減させることができます。

11. クリーンアップジョブを設定する

クリーンアップを有効にする場合、下記をvalues.yamlファイルに含めてください:
apiAffinityfalse(デフォルト値)の場合, Podアフィニティは設定されません。 Podアフィニティを有効にすると、ネットワーク遅延を軽減させるためにプロキシのポッドがAPIポッドと同じノードに設定され、各コンポーネント間でのパフォーマンスが改善されます。

12. その他の設定オプション

プロキシ設定
ドメイン名が非常に長い場合、map_hash_max_size パラメータの制限に達する可能性があります。mapHashBucketSizeserverNamesHashBucketSize の値を増やすことで回避できます。
DB スキーマ更新フック
Liquibase の変更セットに含まれる新しい変更を自動適用し、アプリケーションと同じバージョンのデータベーススキーマを保つため、DB スキーマ更新フックを導入しました。これらのフックは冪等であり、アップグレード版と旧版の間でスキーマに変更がない限り、既存のデータベーススキーマを変更しません。 これらのフックは、インストール時およびアプリケーションバージョン更新時にスキーマを作成・更新するために必要です。ただし、新規アプリケーションをデプロイしない、またはスキーマ変更が見込まれない場合は無効化できます。

デプロイフェーズ

1. コアプラットフォームコンポーネントのインストール

Helm を使用してコアコンポーネントをインストールします。
外部シークレットマネージャーを使用しない場合:
外部シークレットマネージャーを使用する場合:
インストールの確認:
期待される出力例:
注意:初回のデプロイにはイメージの取得とデータベース初期化のために最大 5 分程度かかることがあります。

2. オプションコンポーネントのインストール

要件に応じて、以下の任意コンポーネントをインストールすることも可能です。
  • 管理コンソール: Authlete プラットフォームの主な設定 UI
  • IdP サーバー: ユーザー認証と管理のための OIDC 準拠 IdP
外部シークレットマネージャーを使用しない場合:
外部シークレットマネージャーを使用する場合:
オプションコンポーネントの確認:
期待される出力例:

3. ロードバランサーの構成

最後のステップとして、Authlete デプロイメントを外部に公開するためのロードバランサーサービスを構成します。
  1. まず、クラウドプロバイダーで静的外部 IP アドレスを予約します。
注意:以下のコマンドは GCP 専用です。他のクラウドプロバイダー(AWS、Azure など)を使用している場合は、各プロバイダーのドキュメントを参照して静的 IP アドレスを予約してください。
GCP では、GKE LoadBalancer サービスが同じリージョンに割り当てられた IP のみをサポートするため、リージョン固定の静的 IP を予約する必要があります。
  1. 予約した IP を使用してロードバランサーサービスを作成します。以下の内容で proxy-lb-service.yaml というファイルを作成してください:
以下がGKEの使用例になります
以下がAWS-EKSの使用例になります
  1. ロードバランサー設定を適用します:
  1. ロードバランサーの構成を確認します:
次のような出力が得られるはずです:
EXTERNAL-IP に予約した IP アドレスが表示されれば、Authlete デプロイメントは HTTPS 経由でその IP を通じてアクセス可能になります。

4. ドメインとロードバランサーのマッピング

3 つのドメインすべてに対して、ロードバランサーの IP アドレスを指すように DNS レコードを作成してください:
DNS 設定の確認:
すべてのドメインがロードバランサーの IP に解決され、エンドポイントにアクセス可能であれば、Authlete は利用準備が整っています。 次の手順で管理コンソールにアクセスできます:
  1. ブラウザで https://console.your-domain.com にアクセス
  2. secret-values.yaml に設定した管理者アカウントでログイン
  3. Authlete サービスの構成を開始
注意:コンソールにアクセスできない場合は、以下の項目を確認してください:
  • DNS レコードがすべてのネームサーバーに伝播されているか
  • ロードバランサーのヘルスチェックが成功しているか
  • TLS 証明書がすべてのドメインに対して有効であるか

移行フェーズ(任意)

Authlete 2.3から3.0へ移行される場合、トークン移行 を行うために**トークン移行ツール(Token Migrator)**を有効にする必要があります。

1. トークン移行ツール用クライアントの作成

トークン移行ツールが3.0環境にアクセスできるようにするため、移行先となる3.0環境においてまずサービスとクライアントを作成する必要があります。作成したサービスとクライアントは、トークン移行ツール起動時に環境へのアクセス権を確認するために使用されます。 クライアントの作成と設定は以下の手順で行なってください:
  1. https://console.your-domain.comへアクセスします
  2. 管理者としてログインします
  3. CLIENT_CREDENTIALSグラントを有効にした新しいサービスを作成し、サービス IDを控えます
  4. サービスを使用するための権限を持つサービスアクセストークンを作成し、トークンを控えます
  5. トークン移行ツール専用に使用するクライアントを下記設定で作成:
    • クライアントIDエイリアス: migration-service@system.authlete.com
    • クライアント認証方式: CLIENT_SECRET_POST
    • サポートされるグラントタイプ: CLIENT_CREDENTIALS
  6. 新しく作成したクライアントのクライアントシークレットを控えます
  7. チャートアーカイブに含まれるsecret-values.yamlファイルのtokenmigratorセクションを、作成したクライアント情報を指定して編集します

2. データベース設定

トークン移行ツールは2.3と3.0両方のデータベースに接続する必要があります。3.0のデータベース情報はHelmチャートにおいて既にアクセス可能ですが、2.3データベースに関しては接続情報を提供する必要があります。
  1. values.yamlファイルのtokenmigrator.sourceDatabase.hostを、既存のAuthlete 2.3データベースに向くように設定します 2.3データベースにおいてTLSが必要な場合は、データベースおよびメモリキャッシュへの TLS 接続を有効化 (任意) のガイドラインに従ってtokenmigrator.sourceDatabase.connectionParamsプロパティを設定してください。
  2. チャートアーカイブに含まれるsecret-values.yamlファイルのtokenmigrator.databaseセクションを2.3データベース接続用の資格情報を指定して編集します

3. 外部シークレットの設定 (任意)

外部シークレットマネージャーを使用している場合は、トークン移行ツールが使用するクライアント情報とデータベース資格情報を外部シークレットに追加する必要があります。以下のコードスニペットを参考にトークン移行ツールのプロパティを追加してください:
Kubernetesの外部シークレットリソースに以下を追加してください:

4. トークン移行ツールのデプロイ

これによりhelm upgradeを実行してトークンマイグレーターをデプロイすることが可能になります。初回デプロイの場合はdryrunモードを使用し、設定を確認することを推奨します。実際の移行を開始する際はsyncモードに切り替えてください。
移行を開始する前に、Authlete 3.0へのサービス設定の移行 を参照してください。

5. トークン移行ツールの削除

トークン移行ツールは一時的な使用を目的としているため、移行が完了した後は廃止する必要があります。
  1. tokenmigrator.enabledfalseに設定します
  2. クライアントを削除する、もしくはシークレットをローテーションすることによって、トークン移行ツール用のクライアントを無効化してください(ツールが再有効化されることを防ぎます)。
  3. 移行が完了したことを確認できた後、クライアントとサービスを削除してください。トークン移行ツール専用の組織を作成していた場合は、その組織も削除して構いません。

Helmチャートチェンジログ

現在のHelmチャートバージョンは2.1.6です。

v2.1.6(2026年06月26日)

  • api:3.0.33、idp:1.0.28、console:1.0.23の新バージョンのリリースが追加されました
  • クリーンアップジョブ設定用のツール(authlete-ops:0.1.0)が追加されました

v2.1.5(2026年06月01日)アップデート

  • トークン移行ツールのサポートが実装されました(2.3から3.0への移行のみ対象)
  • pre-installとpre-upgradeのフックに対してラベルが追加されました
  • エラーログ処理用のLiquibaseスクリプトが改善されました
  • api:3.0.32、idp:1.0.27、console:1.0.22の新バージョンのリリースが追加されました
  • APIライフサイクルの終了フックにおけるcurlコマンドがwgetへ変更されました ⚠️ 破壊的変更 : Cloud SQL ProxyがHelmチャートのサイドカーとして含まれなくなったため、データベース接続の設定を直接行うことが必要になりました。接続オプションについてはvalues.yamlのデータベースに関するセクションをご参照ください。

v2.1.4(2026年04月03日)アップデート

  • AWS KMS向けにHSMサポートが実装されました
  • サポートされるデータベースタイプとしてPostgreSQLが追加されました

v2.1.3(2026年02月18日)アップデート

デフォルトのコンソールイメージが更新されました

v2.1.2(2026年02月10日)アップデート

  • standalone(単一キャッシュインスタンス)およびcluster(クラスタキャッシュモード)プロバイダーに対応した新しいキャッシュバックエンド設定が実装されました
  • APIポッド起動時の安定性向上のため、startUpプローブが追加されました
  • ノード間のポッドスケジューリング制御のため、設定可能なポッドアフィニティルールが追加されました
  • Shutdownエンドポイントが、Helmアップグレード時ににローテーションされる動的生成トークンによって保護されるようになりました
  • RFC 6749に準拠するため、nginxにキャッシュ制御ヘッダーが実装されました(各Authorizationサーバーに対して、レスポンス内にCache-Control: no-storeおよびPragma: no-cacheを含める必要があります)
  • nginxのポート8443に対するプロトコル定義が修正されました

v2.1.1(2025年11月06日)アップデート

  • nginxのバージョン情報が公開されなくなりました
  • Redisに対してACL(Access Control List)サポートが実装されました
  • Helm ChartからRedisのデプロイが廃止されました
    • これよりキャッシュを個別にデプロイすることが必要になりました

v2.1(2025年10月02日)アップデート

  • 外部シークレットマネージャーのサポートが実装されました

v2.0(2025年09月12日)アップデート

  • プライベート証明書認証局(CA)を通したTLS接続のサポートが実装されました
  • 不足していた内部接続向けのIPレンジが追加されました
  • map_hash_bucket_sizeおよびserver_names_hash_bucket_sizeパラメーターが、より大きな値を受け付けられるように拡張されました