03 指定响应提示的应用类型，首先用 1（表示一个 Web 应用），然后用 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 Controller
将基于 NGINX Plus 的 NGINX Ingress Controller 配置为验证用户身份的中继方。
定义客户端凭证密钥
出于安全原因，系统不支持对 OIDC 策略对象中的客户端密码进行硬编码。因而，我们创建了一个 Kubernetes Secret 对象，其中包含客户机密的 base64 编码值的数据。
apiVersion: v1
kind: Secret
metadata:
name: oidc-secret
type: nginx.org/oidc
data:
client-secret: base64-encoded-value-of-client-secret
然后应用包含 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 策略
NGINX Ingress Controller 1.10.0 中添加了对基于 OIDC 的身份验证的支持。
NGINX Ingress Controller 实现的 OIDC 身份验证的使用的是一个 Policy 对象，它是一个 Kubernetes 自定义资源，在 NGINX Ingress Controller 中定义了 OIDC 策略。
01 将上一节中获得的信息插入 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
02 应用策略（此处在 oidc.yaml 中进行定义）
$ kubectl apply -f oidc.yam
03（可选）检查策略的有效性
$ kubectl get policy
NAME STATE AGE
oidc-policy Valid 2m
定义 VirtualServer 对象
VirtualServer 和 VirtualServerRoute 是 NGINX Ingress 资源，它们制定了将入向流量路由到 Kubernetes 集群中后端应用的规则。必须在 VirtualServer 或 VirtualServerRoute 资源中引用 OIDC 策略才能使其生效。
01 在 /路径前缀下引用 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
02 应用 VirtualServer 资源（此处在 app-virtual-server.yaml 中进行定义）
$ kubectl apply -f app-virtual-server.yaml
03（可选）验证资源的有效性
$ kubectl get vs
NAME STATE HOST IP PORTS AGE
app-ingress Valid unit-demo.linkpc.net 2m
测试环境
要测试 OIDCOkta 集成能否正常工作，请在浏览器的地址栏中输入 NGINX Ingress Controller 的主机名。您将被重定向到 Okta 登录门户，您可在该门户上输入 Okta 开发者账号的凭证以访问后端应用。
一旦通过身份验证，即可访问 app-server-payload 上游服务。
将用户添加到应用
在大多数情况下，企业的多个用户都需要访问应用。在 Okta 管理员控制台目录（Directory）类别下的人员（People）页面上添加每个用户。
为 SSO 创建多个应用集成
我们使用 Okta（作为 IdP）和 NGINX Ingress Controller（作为中继方）配置 SSO，从而卸载一个应用的身份验证流程。在实践中，您可能希望用户能够使用一组凭证访问多个应用。您可能还希望能够灵活地改变用户可以访问的应用。
您可以通过集成 Okta 与其他应用、定义其他 OIDC 策略并在 VirtualServer 资源中引用这些策略来实现这一点。在下图描述的示例中，有两个子域名：unit-demo.marketing.net 和 unit-demo.engineering.net，它们解析为 NGINX Ingress Controller 的外部 IP 地址。
NGINX Ingress Controller 根据子域名将请求路由到营销（Marketing）应用或工程（Engineering）应用。如要授予用户访问权限，请在 Okta GUI 的分配（Assignments）选项卡上，将用户与每个适当的应用相关联。然后，Okta 向通过身份验证的用户颁发一个短暂的会话 cookie，以支持他们访问这些应用。
结语
通过将 NGINX Ingress Controller 配置为中继方，将 Okta 配置为 IdP，您可以在 Kubernetes 中实现基于 OIDC 的 SSO，并消除开发人员的身份验证和授权负担，让他们专注于优化应用中的业务逻辑。
