ランサムウェアやボットによる攻撃が横行する今日の状況において、アプリと 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 環境での操作経験があることを前提としています。 さらに、次のものが必要です。
okta
register
コマンドを実行して新しいアカウントにサインアップします。 執筆時点では、Okta CLI はベータ版であり、本番環境での使用は推奨されていません。クラウド サービスは、ユーザー 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 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",
...
}
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 と 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 管理コンソールの「ディレクトリ」カテゴリの「ユーザー」ページで各ユーザーを追加します。
Okta を IdP として、NGINX Ingress Controller をリレーパーティとして SSO を構成することで、認証プロセスを 1 つのアプリケーションからオフロードしました。 実際には、ユーザーが単一の資格情報セットを使用して多数のアプリケーションにアクセスできるようにする必要があるでしょう。 また、ユーザーがアクセスできるアプリケーションを柔軟に変更したい場合もあります。 上記のセクションの手順を繰り返すことでこれを実行できます。
次の図に示す例では、 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 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"