ブログ | NGINX

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

アミール・ラウダット

2021年9月22日公開

ランサムウェアやボットによる攻撃が横行する今日の状況において、アプリと 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 がアプリ統合と呼ぶものを作成します。

okta loginコマンドを実行して、Okta 開発者アカウントで Okta CLI を認証します。プロンプトで Okta ドメインとAPI トークンを入力します。
```
$ okta login Okta Org URL: https://your-okta-domain
Okta API token: your-api-token
```
アプリ統合を作成します。
```
$ okta apps create --app-name=mywebapp --redirect-uri=http[s]://ingress-controller-hostname/_codexch
```
どこ
- --app-name はアプリケーション名を定義します（ここでは、 mywebapp ）
- --redirect-uri はサインインがリダイレクトされるURIを定義します（ここでは、 ingress-controller-hostname /_codexch ）

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

Type of Application
(The Okta CLI only supports a subset of application types and properties):
> 1: Web
> 2: Single Page App
> 3: Native App (mobile)
> 4: Service (Machine-to-Machine)
Enter your choice [Web]: 1
Type of Application
> 1: Okta Spring Boot Starter
> 2: Spring Boot
> 3: JHipster
> 4: Quarkus
> 5: Other
Enter your choice [Other]: 5
Configuring a new OIDC Application, almost done:
Created OIDC application, client-id: 0oa1mi...OrfQAg5d7

NGINX Ingress コントローラの設定

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

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

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

apiVersion: v1
kind: Secret
metadata:
  name: oidc-secret
type: nginx.org/oidc
data:
  client-secret: base64-encoded-value-of-client-secret

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

$ kubectl apply –f client-secret.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カスタムリソースであるポリシーオブジェクトを使用します。

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

apiVersion: k8s.nginx.org/v1
kind: Policy
metadata:
  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

ポリシーを適用します（ここではoidc.yamlで定義されています）。
```
$ kubectl apply -f oidc.yaml
```

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

$ kubectl get policy 

NAME          STATE   AGE
oidc-policy   Valid   2m

VirtualServerオブジェクトの定義

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

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

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: app-ingress
spec:
  host: unit-demo.linkpc.net
  upstreams:
  - name: app-server-payload
    service: app-server-svc
    port: 80
  routes:
  - path: /
    policies:
    - name: oidc-policy
    action:
      proxy: 
        upstream: app-server-payload

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

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

$ kubectl get vs

NAME          STATE   HOST                   IP    PORTS   AGE
app-ingress   Valid   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 日間の無料トライアルをリクエストするか、お問い合わせの上、ユースケースについてご相談ください。

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"

検索結果の提案

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

前提条件

IdP の事前設定

NGINX Ingress コントローラの設定

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

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

NGINX Ingress OIDCポリシーの定義

VirtualServerオブジェクトの定義

環境のテスト

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

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

結論

あらゆるアプリを安全に配信しましょう

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

前提条件

IdP の事前設定

NGINX Ingress コントローラの設定

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

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

NGINX Ingress OIDCポリシーの定義

VirtualServerオブジェクトの定義

環境のテスト

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

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

結論

あらゆるアプリを安全に配信しましょう

F5の情報を入手