Okta と NGINX Ingress Controller を使用して Kubernetes に OpenID Connect 認証を実装する

ランサムウェアやボットによる攻撃が横行する今日の状況において、アプリと API を保護することがいかに重要であるかについては、これまで何度も記事を書いてきました。 Web アプリケーション ファイアウォール(WAF) などのメカニズムとともに、ユーザー ID を認証し、承認制御を実施することは、ビジネス アプリケーションを保護するための重要な方法です。

認証と承認を実装する最も直接的な方法は、アプリケーション自体に実装することです。 これは、ユーザーベースが小さく、アプリを頻繁に更新する必要がない場合には機能しますが、規模が大きくなるとすぐに実行できなくなります。 たとえば、ユーザーが多数のアプリごとに異なるアカウント名とパスワードを覚えておく必要がある場合、ログインしようとすると「ユーザー名またはパスワードが間違っています」というイライラするメッセージが表示されることが多く、簡単に推測できる「abc123」パスワードなどの安全でないソリューションに頼ることになります。 パスワードリマインダーを記したポストイット® ノートで飾られたモニターを見たことがあるでしょう。

シングル サインオン (SSO) テクノロジは、個別のユーザー名とパスワードをすべて排除し、1 セットの資格情報を使用することで、これらの問題を部分的に解決できます。 ユーザーは、アイデンティティ プロバイダー (IdP) を使用して 1 回サインインするだけで、多くのアプリにアクセスできます。 しかし、開発者は依然として、SSO システムとインターフェースするためのコードをアプリに組み込む必要があり、特にアプリケーションの複雑さが増すにつれて、これは非常に困難になる可能性があります。

組織が拡大し、急増するユーザーベースの要件を満たす必要が生じるにつれて、認証や承認など、アプリの機能に固有ではない要件をアプリケーション層からオフロードすることが重要になります。 Kubernetesで集中認証と承認を行うのに最適な場所はIngress コントローラーです。Ingress コントローラーは、クラスターに入るすべてのトラフィックを精査し、適切なサービスにルーティングできます。 これにより、開発者は認証ロジックの構築、維持、複製の負担から解放され、ネイティブ Kubernetes API を使用してイングレス レイヤーで SSO テクノロジーを簡単に活用できるようになります。

このブログでは、 NGINX Plus ベースのNGINX Ingress Controller を中継側として動作させ、Okta を事前設定された ID プロバイダー (IdP) としてOIDC 認証コード フローをサポートする、本格的な SSO ソリューションを実装する方法を示します。

注記： この機能は、NGINX オープンソースベースの NGINX Ingress Controller では使用できません。

前提条件

このブログでは、Kubernetes 環境での操作経験があることを前提としています。 さらに、次のものが必要です。

• Kubernetes 環境– NGINX Ingress Controller は、標準の Kubernetes だけでなく、Amazon Elastic Kubernetes (EKS)、ベアメタル、Google Kubernetes Engine (GKE)、Microsoft Azure Kubernetes Service (AKS)、Rancher Kubernetes Engine、Red Hat OpenShift などの多数の Kubernetes プラットフォームでもサポートされています。
• NGINX Plus ベースの NGINX Ingress Controller – NGINX Plus ベースのバージョンの NGINX Ingress Controller の有効なライセンスが必要です。 30 日間の無料トライアルをリクエストして、今すぐライセンスを開始できます。 詳細については、ドキュメントをご覧ください。
• Okta 開発者アカウント– Okta を IdP として設定するには、まず開発者アカウントにサインアップします。 代わりに、 Okta コマンドラインインターフェース(CLI) をダウンロードし、 okta registerコマンドを実行して新しいアカウントにサインアップします。 執筆時点では、Okta CLI はベータ版であり、本番環境での使用は推奨されていません。

IdP の事前設定

クラウド サービスは、ユーザー ID を取得して検証する場所を認識する必要があり、そのために IdP が必要になります。 IdP はデジタル ID を安全に管理および保存し、攻撃者が ID を盗んでユーザーになりすますことができないようにします。

このセクションでは、Okta CLI を使用して Okta を IdP として事前構成し、Okta がアプリ統合と呼ぶものを作成します。

1. okta loginコマンドを実行して、Okta 開発者アカウントで Okta CLI を認証します。 プロンプトで Okta ドメインとAPI トークンを入力します。

   $ okta ログインOkta 組織 URL: https:// your-okta-domain Okta API トークン: your-api-token
   

2. アプリ統合を作成します。

   $ okta アプリ作成 --app-name=mywebapp --redirect-uri=http[s]:// ingress-controller-hostname /_codexch
   

   どこ

   • --app-name はアプリケーション名を定義します（ここでは、 mywebapp ）
   • --redirect-uri はサインインがリダイレクトされるURIを定義します（ここでは、 ingress-controller-hostname /_codexch ）

3. プロンプトに応じてアプリケーションの種類を指定します。まず、1 （ウェブアプリケーションを表す）そして5(リストされているフレームワーク以外のフレームワークを表します)。

   アプリケーションのタイプ
   (Okta CLI は、アプリケーション タイプとプロパティのサブセットのみをサポートします):
   > 1: ウェブ
   > 2: シングルページアプリ
   > 3: ネイティブ アプリ (モバイル)
   > 4: サービス (マシンツーマシン)
   [Web] を選択してください: 1
   アプリケーションの種類
   > 1: Okta スプリングブートスターター
   > 2: スプリングブート
   > 3: Jヒップスター
   > 4: クオークス
   > 5: その他
   [その他]を選択してください: 5
   新しい OIDC アプリケーションの構成、ほぼ完了:
   OIDC アプリケーション、クライアント ID を作成しました: 0oa1mi...オルフQAg5d7
   

NGINX Ingress コントローラの設定

NGINX Plus ベースのバージョンの NGINX Ingress Controller を、ユーザーを認証するリレーパーティとして構成します。

クライアント資格情報シークレットの定義

セキュリティ上の理由から、OIDC ポリシー オブジェクトにクライアント シークレットをハードコーディングすることはサポートされていません。 代わりに、クライアント シークレットの base64 エンコードされた値を含むデータを含む Kubernetes シークレットを作成します。

apiバージョン: v1 種類: シークレットのメタデータ: 名前: oidc-secret タイプ: nginx.org/oidc データ: client-secret: base64 でエンコードされたクライアント シークレットの値 

次に、シークレットを含む YAML ファイル (ここではclient-secret.yaml ) を適用します。

$ kubectl apply –f クライアントシークレット.yaml

認証エンドポイントの取得

OAuth 2.0およびOpenID Connect API を使用して、Okta が認可サーバー上で公開するエンドポイントに関する情報を取得します。

Okta エンドポイントに関する情報を出力するには、ローカル マシンで次のコマンドを実行します。 サンプル出力に示されているauthorization_endpoint 、 token_endpoint 、 jwks_uriの値をメモします。 これらは次のセクションで使用します。

$ curl -i https:// your-okta-domain /.well-known/openid-configuration { "authorization_endpoint": "https:// your-okta-domain /oauth2/v1/authorize", ... "jwks_uri": "https:// your-okta-domain /oauth2/v1/keys", ... "token_endpoint": "https:// your-okta-domain /oauth2/v1/token", ... }

NGINX Ingress OIDCポリシーの定義

OIDC ベースの認証のサポートは、NGINX Ingress Controller 1.10.0 で追加されました。 詳細については、弊社のブログの「OpenID Connect と NGINX Ingress Controller を使用した簡単で堅牢なシングル サインオン」をご覧ください。

OIDC 認証の NGINX Ingress Controller 実装では、NGINX Ingress Controller で OIDC ポリシーを定義する Kubernetesカスタム リソースであるポリシーオブジェクトを使用します。

1. 前のセクションで取得した情報を、 PolicyオブジェクトのauthEndpoint 、 tokenEndpoint 、およびjwksURIフィールドに挿入します。

   apiバージョン: k8s.nginx.org/v1 種類: ポリシー メタデータ: name: oidc-policy spec: oidc: clientID: client-id clientSecret: oidc-secret authEndpoint: https:// your-okta-domain /oauth2/v1/authorize tokenEndpoint: https:// your-okta-domain /oauth2/v1/token jwksURI: https:// your-okta-domain /oauth2/v1/keys
   

2. ポリシーを適用します（ここではoidc.yamlで定義されています）。

   $ kubectl を適用 -f oidc.yaml
   

3. (オプション) ポリシーの有効性を確認します。

   $ kubectl get policy NAME STATE AGE oidc-policy 有効期間 2m
   

VirtualServerオブジェクトの定義

VirtualServer と VirtualServerRoute は、Kubernetes クラスター内のバックエンド アプリケーションへの着信トラフィックをルーティングするためのルールをプロビジョニングするNGINX Ingress リソースです。 OIDC ポリシーを有効にするには、VirtualServer または VirtualServerRoute リソースで参照する必要があります。

1. /パス プレフィックスの下の OIDC ポリシーを参照して、プレフィックスに一致するパスを要求するユーザーが、要求がapp-server-payloadサービスにプロキシされる前に認証されるようにします。

   apiバージョン: k8s.nginx.org/v1
   種類: VirtualServer
   メタデータ:
   名前: app-ingress
   仕様:
   ホスト: unit-demo.linkpc.net
   アップストリーム:
   -名前: app-server-payload
   サービス: app-server-svc
   ポート: 80
   ルート:
   - パス: /
   ポリシー:
   - 名前: oidc-policy
   アクション:
   プロキシ:
   アップストリーム: app-server-payload
   

2. VirtualServer リソースを適用します (ここではapp-virtual-server.yamlで定義されています)。

   $ kubectl apply -f アプリ仮想サーバー.yaml
   

3. (オプション) リソースの有効性を確認します。

   $ kubectl get vs NAME STATE HOST IP PORTS AGE app-ingress 有効 unit-demo.linkpc.net 2m
   

環境のテスト

OIDC Okta 統合が正しく機能していることをテストするには、ブラウザのアドレスバーに NGINX Ingress Controller のホスト名を入力します。 Okta ログイン ポータルにリダイレクトされ、そこで Okta 開発者アカウントの資格情報を入力してバックエンド アプリケーションにアクセスできます。

認証に成功すると、 app-server-payloadアップストリーム サービスにアクセスできるようになります。

アプリケーションへのユーザーの追加

ほとんどの場合、組織内の複数のユーザーがアプリにアクセスする必要があります。 Okta 管理コンソールの「ディレクトリ」カテゴリの「ユーザー」ページで各ユーザーを追加します。

複数のアプリの SSO 統合の作成

Okta を IdP として、NGINX Ingress Controller をリレーパーティとして SSO を構成することで、認証プロセスを 1 つのアプリケーションからオフロードしました。 実際には、ユーザーが単一の資格情報セットを使用して多数のアプリケーションにアクセスできるようにする必要があるでしょう。 また、ユーザーがアクセスできるアプリケーションを柔軟に変更したい場合もあります。 上記のセクションの手順を繰り返すことでこれを実行できます。

• 他のアプリケーションをOktaと統合するためのIdPの事前設定
• NGINX Ingress OIDCポリシーを定義して他のOIDCポリシーを定義する
• 追加のポリシーを参照するためのVirtualServerオブジェクトの定義

次の図に示す例では、 unit-demo.marketing.netとunit-demo.engineering.netという 2 つのサブドメインがあり、NGINX Ingress Controller の外部 IP アドレスに解決されます。 NGINX Ingress Controller は、サブドメインに基づいて、リクエストをマーケティングアプリまたはエンジニアリングアプリのいずれかにルーティングします。 ユーザーにアクセスを許可するには、Okta GUI の[割り当て]タブで、ユーザーを適切な各アプリケーションに関連付けます。 Okta は、認証されたユーザーに、これらのアプリケーションにアクセスするための短期間のセッション Cookie を付与します。

結論

NGINX Ingress Controller を中継側、Okta を IdP として使用して Kubernetes に OIDC ベースの SSO を実装すると、開発者の認証と承認の負荷が軽減され、開発者はアプリのビジネス ロジックの最適化に集中できるようになります。 NGINX Plus ベースのNGINX Ingress Controller を使い始めるには、今すぐ30 日間の無料トライアルをリクエストするか、お問い合わせの上、ユースケースについてご相談ください。