Kubernetes (k8s) 集群包括称为节点的工作机器和一个控制平面,该控制平面由 API 服务器、调度程序、etcd、控制器管理器以及在 PaaS(平台即服务)的情况下,云控制器管理器组成。部署到集群的容器在工作节点上的 pod 中运行。同时,控制平面负责调度、响应请求和管理集群。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--GcBIM1En--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to- uploads.s3.amazonaws.com/uploads/articles/hr9e7yk7gtfp3wncpg0q.jpg)

当您使用 kubectl、客户端库或KDash之类的工具与 Kubernetes 集群通信时,您主要与Kubernetes API 服务器进行交互。 API 服务器负责管理集群并负责处理来自客户端的请求。

为什么要保护 API 服务器?

API 服务器具有多层安全性。默认情况下,与 API 服务器的所有通信都使用 TLS。身份验证使用服务帐户令牌、承载令牌、基本身份验证、代理或客户端证书完成,具体取决于平台。对于像 Amazon EKS、AKS 和 GKE 这样的 PaaS,也可以使用自定义身份验证机制来完成。请求通过身份验证后,API 服务器可以使用多种授权机制之一来控制对资源的访问,例如基于属性的访问控制 (ABAC) 或基于角色的访问控制 (RBAC)。最后,还有准入控制模块可以配置为控制资源修改。

由于 API 服务器是 Kubernetes 集群中客户端可以访问的唯一部分,因此保护 API 服务器是必不可少的。未经授权访问 API 服务器可能会导致整个集群被劫持,这也让攻击者可以访问其上运行的服务可访问的所有机密和数据。因此,正确配置用户和角色是保护集群的必要条件,尤其是在多个用户可以访问集群的组织中。

为什么选择 OpenID Connect?

OpenID Connect是建立在 OAuth 2.0 之上的身份验证标准。它添加了一个称为 ID 令牌的附加令牌。 OpenID Connect 还标准化了 OAuth 2.0 允许选择的领域,例如范围、端点发现和客户端的动态注册。

虽然 Kubernetes API 服务器的默认身份验证机制对于只有少数人管理集群的简单用例可能就足够了,但它不适用于更大的组织。此外,默认绝对不是最安全的方式,因为 Kubernetes 不处理用户管理,并希望它在外部完成。这就是 OpenID Connect (OIDC) 的用武之地。OIDC 可以管理用户和组,这与 Kubernetes RBAC 配合得非常好,可以非常精细地控制谁可以访问集群内的内容。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--V8TWFWlc--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://dev-to -uploads.s3.amazonaws.com/uploads/articles/8pu0qbgcqc84fy4719cw.jpg)

通过 OIDC 集成,您可以在现有基础架构中使用用于 SSO 的相同 OIDC 提供程序来访问您的 Kubernetes 集群,例如 Okta 或 Keycloak。

使用 Okta 作为 OIDC 提供程序来保护 API 服务器

Okta 提供云软件,帮助公司管理和保护应用程序中的用户身份验证,并使开发人员能够在应用程序、网站、Web 服务和设备中构建身份控制。 Okta 是经过认证的 OpenID Connect 提供商。

让我们看看如何使用 Okta 作为 OIDC 提供程序来保护 Kubernetes API 服务器,并使用 RBAC 来控制来自 Okta 管理控制台的访问。如果您使用的是 Amazon EKS,请查看此教程,了解如何将 Okta OIDC 与 EKS结合使用。

入门需要什么

在您尝试之前,请确保您可以访问以下内容。

• Okta 帐户。您可以注册一个免费的 Okta 帐户。或者,您可以使用其他 OIDC 提供商或Dex,步骤应该类似。

• 一个 Kubernetes 集群。我正在使用k3d运行本地k3s集群。您可以使用任何 Kubernetes 发行版,包括 Amazon EKS、AKS 和 GKE 等托管 PaaS。

• kubectl安装在你的机器上。

• Terraform安装在您的机器上。如果您通过Okta 管理控制台GUI 进行 Okta 配置,则不需要这样做。

设置 Okta OIDC 应用程序和授权服务器

您可以通过使用 Okta CLI 或管理控制台使用 Okta 创建一个简单的 OIDC 应用程序来实现集群的 OIDC 登录。但仅使用 OIDC 应用程序,您将不得不使用客户端密码从 kubectl 或任何其他客户端库进行身份验证。使用客户端密钥进行身份验证不会扩展并且并不比默认的 k8s 身份验证机制更好,因为您不会对用户和角色进行精细控制。为了更有用的设置,我们需要一个 OIDC 应用程序和一个授权服务器,其中包含为 Kubernetes 定制的声明和策略。这样,我们也可以使用 Okta 来管理用户和权限。

在 Okta 中设置 OIDC 应用程序和授权服务器有多种方法。如果您更喜欢通过 GUI 执行此操作,请按照前面提到的文章的*Configure Your Okta Org * 部分中的步骤,通过 Okta 管理控制台执行此操作。

在本教程中,我们将使用 Terraform 配置 Okta 部分,以便您可以将代码重用于任何所需的自动化。让我们深入了解所需的每个步骤。

设置 Terraform

您可以在此GitHub 存储库中找到本文的完整 Terraform 源代码

首先,我们需要配置Okta Terraform 提供程序。创建一个新的 Terraform 文件,假设为okta.main.tf,并添加以下内容:

variable "base_url" {
  description = "The Okta base URL. Example: okta.com, oktapreview.com, etc. This is the domain part of your Okta org URL"
}
variable "org_name" {
  description = "The Okta org name. This is the part before the domain in your Okta org URL"
}
variable "api_token" {
  type        = string
  description = "The Okta API token, this will be read from environment variable (TF_VAR_api_token) for security"
  sensitive   = true
}

# Enable and configure the Okta provider
terraform {
  required_providers {
    okta = {
      source  = "okta/okta"
      version = "~> 3.15"
    }
  }
}

provider "okta" {
  org_name  = var.org_name
  base_url  = var.base_url
  api_token = var.api_token
}

进入全屏模式 退出全屏模式

您需要提供输入变量org_name、base_url和api_token。在名为okta.config.auto.tfvars的文件中更新这些值。名称中的.auto很重要;否则,Terraform 不会自动拾取它。例如,如果您的 Okta 实例的地址是dev-1234.okta.com,那么您的org_name将是dev-1234,而base_url将是组织名称之后的所有内容(例如,okta.com)。

接下来,您需要生成api_token值。以超级用户身份登录您的 Okta 管理员控制台,然后从导航菜单中选择 Security > API > Tokens (Tab)。接下来,单击 Create Token 按钮,为您的令牌命名,单击 Create Token,然后复制新生成的令牌。将其保存在从 Git 中排除的单独的secret.auto.tfvars文件中或名为TF_VAR_api_token的环境变量中。

Okta 提供程序现在已配置并准备就绪。

创建群组

现在我们需要一些组来区分和映射想要访问我们集群的不同类型的用户。假设我们有一组具有集群完全访问权限的管理员和另一组具有有限访问权限的用户。您可以根据需要拥有任意数量的组。下面的配置将创建两个组。该组的权限将使用集群上的 Kubernetes RBAC 策略定义,我们稍后会这样做。

# Set up OKTA groups
resource "okta_group" "k8s_admin" {
  name        = "k8s-admins"
  description = "Users who can access k8s cluster as admins"
}

resource "okta_group" "k8s_restricted_users" {
  name        = "k8s-restricted-users"
  description = "Users who can only view pods and services in default namespace"
}

进入全屏模式 退出全屏模式

将用户分配到组

下面的代码片段查找现有用户并将他们添加到组中。您可以在此阶段添加任意数量的用户,也可以跳过添加用户,稍后通过 Okta 管理控制台进行操作。对于本练习,我正在获取现有用户。您还可以使用okta_user资源创建新用户。

# Assign users to the groups
data "okta_user" "admin" {
  search {
    name  = "profile.email"
    value = "<your_admin_user_email>"
  }
}

resource "okta_group_memberships" "admin_user" {
  group_id = okta_group.k8s_admin.id
  users = [
    data.okta_user.admin.id
  ]
}

data "okta_user" "restricted_user" {
  search {
    name  = "profile.email"
    value = "<another_user_email>"
  }
}

resource "okta_group_memberships" "restricted_user" {
  group_id = okta_group.k8s_restricted_users.id
  users = [
    data.okta_user.restricted_user.id
  ]
}

进入全屏模式 退出全屏模式

创建OIDC应用

现在我们的组已经就位,让我们创建一个 OIDC 应用程序。我们将应用程序类型设置为native并使用 PKCE 作为客户端身份验证,这比使用客户端密码安全得多。我们还将重定向 URI 设置为localhost:8000,以便我们可以在本地使用 kubectl。我们还应该在此处将我们之前创建的组分配给此应用程序。最后,我们可以使用输出变量捕获创建的应用程序的客户端 ID。

# Create an OIDC application

resource "okta_app_oauth" "k8s_oidc" {
  label                      = "k8s OIDC"
  type                       = "native" # this is important
  token_endpoint_auth_method = "none"   # this sets the client authentication to PKCE
  grant_types = [
    "authorization_code"
  ]
  response_types = ["code"]
  redirect_uris = [
    "http://localhost:8000",
  ]
  post_logout_redirect_uris = [
    "http://localhost:8000",
  ]
  lifecycle {
    ignore_changes = [groups]
  }
}

# Assign groups to the OIDC application
resource "okta_app_group_assignments" "k8s_oidc_group" {
  app_id = okta_app_oauth.k8s_oidc.id
  group {
    id = okta_group.k8s_admin.id
  }
  group {
    id = okta_group.k8s_restricted_users.id
  }
}

output "k8s_oidc_client_id" {
  value = okta_app_oauth.k8s_oidc.client_id
}

进入全屏模式 退出全屏模式

创建授权服务器

接下来,我们需要一个授权服务器,以便我们可以定义策略和声明。我们还将在输出变量中捕获颁发者 URL。

# Create an authorization server

resource "okta_auth_server" "oidc_auth_server" {
  name      = "k8s-auth"
  audiences = ["http:://localhost:8000"]
}

output "k8s_oidc_issuer_url" {
  value = okta_auth_server.oidc_auth_server.issuer
}

进入全屏模式 退出全屏模式

向授权服务器添加声明

让我们向授权服务器添加一个声明,以便在他们进行身份验证时将用户的组添加到id_token中。我们将需要它来在 Kubernetes 端执行 RBAC。另外,请注意,我们仅将前缀为k8s-的组添加到声明中。这是为了避免添加与 Kubernetes 无关的组。

# Add claims to the authorization server

resource "okta_auth_server_claim" "auth_claim" {
  name                    = "groups"
  auth_server_id          = okta_auth_server.oidc_auth_server.id
  always_include_in_token = true
  claim_type              = "IDENTITY"
  group_filter_type       = "STARTS_WITH"
  value                   = "k8s-"
  value_type              = "GROUPS"
}

进入全屏模式 退出全屏模式

向授权服务器添加策略和规则

现在我们需要为授权服务器创建策略和规则。以下策略定义将分配给哪些 OIDC 应用程序。然后,我们为将定义 PKCE 令牌生命周期和刷新间隔的策略创建一个规则。为此,我们将这些值保留为默认值,即 1 小时生命周期和无限刷新间隔,但您可以根据需要更改它们。

# Add policy and rules to the authorization server

resource "okta_auth_server_policy" "auth_policy" {
  name             = "k8s_policy"
  auth_server_id   = okta_auth_server.oidc_auth_server.id
  description      = "Policy for allowed clients"
  priority         = 1
  client_whitelist = [okta_app_oauth.k8s_oidc.id]
}

resource "okta_auth_server_policy_rule" "auth_policy_rule" {
  name           = "AuthCode + PKCE"
  auth_server_id = okta_auth_server.oidc_auth_server.id
  policy_id      = okta_auth_server_policy.auth_policy.id
  priority       = 1
  grant_type_whitelist = [
    "authorization_code"
  ]
  scope_whitelist = ["*"]
  group_whitelist = ["EVERYONE"]
}

进入全屏模式 退出全屏模式

使用 Terraform 创建 Okta 配置

现在 Terraform 代码已准备就绪,让我们应用它。首先,运行terraform plan以查看将要进行的更改。验证plan提议的更改是否对您打算修改的资源进行了您想要的更改。然后运行terraform apply并键入yes以应用更改。您应该会看到与此类似的输出。您还可以登录 Okta 管理控制台来验证更改。

复制输出值,因为我们将在接下来的步骤中需要它们。

okta_group.k8s_admin: Creating...
okta_group.k8s_restricted_users: Creating...
okta_auth_server.oidc_auth_server: Creating...
okta_app_oauth.k8s_oidc: Creating...
okta_group.k8s_admin: Creation complete after 0s [id=00g2b0rmupxo1C1HW5d7]
okta_group.k8s_restricted_users: Creation complete after 0s [id=00g2b0q4zejpq6hbi5d7]
okta_group_memberships.restricted_user: Creating...
okta_group_memberships.admin_user: Creating...
okta_auth_server.oidc_auth_server: Creation complete after 1s [id=aus2b0ql0ihgilIh95d7]
okta_auth_server_claim.auth_claim: Creating...
okta_group_memberships.admin_user: Creation complete after 1s [id=00g2b0rmupxo1C1HW5d7]
okta_group_memberships.restricted_user: Creation complete after 1s [id=00g2b0q4zejpq6hbi5d7]
okta_app_oauth.k8s_oidc: Creation complete after 1s [id=0oa2b0qc0x38Xjxbk5d7]
okta_app_group_assignments.k8s_oidc_group: Creating...
okta_auth_server_policy.auth_policy: Creating...
okta_auth_server_claim.auth_claim: Creation complete after 0s [id=ocl2b0rc6ejmIO4KR5d7]
okta_app_group_assignments.k8s_oidc_group: Creation complete after 1s [id=0oa2b0qc0x38Xjxbk5d7]
okta_auth_server_policy.auth_policy: Creation complete after 1s [id=00p2b0qjjxsSz0Mya5d7]
okta_auth_server_policy_rule.auth_policy_rule: Creating...
okta_auth_server_policy_rule.auth_policy_rule: Creation complete after 1s [id=0pr2b0rgnfxjyu6cy5d7]

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

Outputs:

k8s_oidc_client_id = "0oa2b0qc0x38Xjxbk5d7"
k8s_oidc_issuer_url = "https://dev-xxxxxx.okta.com/oauth2/aus2b0ql0ihgilIh95d7"

进入全屏模式 退出全屏模式

如果需要,您可以运行terraform destroy来还原更改。

提示:您可以使用terraform import <resource_name.id>命令从 Okta 实例导入数据和配置。有关详细信息,请参阅这些 Okta Terraform 提供程序文档。

为 OIDC 准备集群

现在我们需要准备集群以使用 OIDC。为此,我们需要更新以下 API 服务器标志:

• oidc-issuer-url:这将是来自 Okta 授权服务器的颁发者 URL

• oidc-client-id:这是来自 Okta OIDC 应用程序的客户端 ID

• oidc-username-claim:这是用于识别用户的声明。在这种情况下,它是email。

• oidc-groups-claim:这是用于识别组的声明。在这种情况下,它是groups。

• oidc-ca-file:这是用于验证 OIDC 服务器的 CA 文件。如果您将 Okta 用作 OIDC 提供程序,则无需设置此项。

注意:如果您遇到 OIDC 组/用户与 Kubernetes 组/用户冲突的问题,您也可以设置oidc-groups-prefix和oidc-username-prefix标志。

可以在创建集群时设置标志,或者通过 SSH 修补 API 服务器,如下所述。

创建启用OIDC的集群

以下是如何使用不同工具创建启用 OIDC 的新 k8s 集群的方法。执行您正在使用的工具的命令。确保将<k8s_oidc_issuer_url>和<k8s_oidc_client_id>替换为 Terraform 步骤输出中的值。对于任何其他工具,请参阅有关如何更新 API 服务器标志的文档。

如果您使用kubeadmn,请将以下标志添加到集群配置并将它们传递给kubeadm init命令。

apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
apiServer:
  extraArgs:
    oidc-issuer-url: <k8s_oidc_issuer_url>
    oidc-client-id: <k8s_oidc_client_id>
    oidc-username-claim: email
    oidc-groups-claim: groups

进入全屏模式 退出全屏模式

kOps

对于kOps,创建具有所需配置的集群。例如,下面的代码将在 AWS 中创建一个集群。

kops create cluster \
 --authorization RBAC \
 --name $CLUSTER_NAME \
 --cloud aws \
 --state $S3_STATE_STORE

进入全屏模式 退出全屏模式

现在编辑集群配置并添加 OIDC 数据。

kops edit cluster $CLUSTER_NAME --state $S3_STATE_STORE

进入全屏模式 退出全屏模式

将此 YAML 添加到kubeAPIServer规范中。

kubeAPIServer:
  authorizationRbacSuperUser: admin
  oidcIssuerURL: <k8s_oidc_issuer_url>
  oidcClientID: <k8s_oidc_client_id>
  oidcUsernameClaim: email
  oidcGroupsClaim: groups

进入全屏模式 退出全屏模式

100,173 100,175 100,176 100,174 座位

要使用k3d创建k3s集群,请运行以下命令。

# k3d v5.0.0+
k3d cluster create $CLUSTER_NAME \
--k3s-arg "--kube-apiserver-arg=oidc-issuer-url=<k8s_oidc_issuer_url>@server:0" \
--k3s-arg "--kube-apiserver-arg=oidc-client-id=<k8s_oidc_client_id>@server:0" \
--k3s-arg "--kube-apiserver-arg=oidc-username-claim=email@server:0" \
--k3s-arg "--kube-apiserver-arg=oidc-groups-claim=groups@server:0"

进入全屏模式 退出全屏模式

更新现有集群以启用 OIDC

如果您已经有一个现有的集群,您可以使用 root 用户通过 SSH 连接到其中,并使用以下命令修补 API 服务器。

ssh root@master-node-ip

sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml

...
    command:
    - /hyperkube
    - apiserver
    - --advertise-address=x.x.x.x
...

    - --oidc-issuer-url=<k8s_oidc_issuer_url> # <-- 🔴 update this
    - --oidc-client-id=<k8s_oidc_client_id> # <-- 🔴 update this
    - --oidc-username-claim=email # <-- 🔴 update this
    - --oidc-groups-claim=groups # <-- 🔴 update this
...

进入全屏模式 退出全屏模式

如果您使用的是EKS或GKE之类的托管服务,请按照他们的说明更新 API 服务器。

配置RBAC

基于角色的访问控制允许您控制谁可以访问集群内的内容。这是一个非常强大的功能,可以用来控制对特定资源的访问。使用 OIDC 的好处是我们可以将它与 RBAC 一起使用,以实现对资源的非常精细的控制。

大多数 Kubernetes 发行版默认启用 RBAC。如果没有,请确保在继续之前启用它。在创建或修补集群时,可以使用 API 服务器的--authorization-mode标志设置它。例如,--authorization-mode=RBAC,anotherMethod。

在本练习中,我们将使用在 Okta 中创建的两个组。在集群级别,我们将管理员访问权限限制为将通过 OIDC 提供程序(在本例中为 Okta)控制的特定组。

让我们通过 kubectl 应用以下 YAML 来创建集群角色绑定。这将绑定到名为cluster-admin的内置集群角色,并限制对 Okta 中k8s-admins组中的用户的访问。现在添加到组的任何用户都可以访问集群,从组中删除某人就足以删除他们的访问权限。

kubectl apply -f - <<EOF
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: oidc-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: Group
  name: k8s-admins
EOF

进入全屏模式 退出全屏模式

在实际用例中,您可能希望进一步限制组对特定资源类型或命名空间的访问,添加具有不同权限的多个组,等等。有关不同的可能性,请参见这个。

现在,让我们创建一个只能查看默认命名空间中的 pod 和服务的 k8s 角色。

kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: restricted-user
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods", "services"]
  verbs: ["get", "watch", "list"]
EOF

进入全屏模式 退出全屏模式

现在我们可以将角色绑定到我们在 Okta 中创建的第二个组。

kubectl apply -f - <<EOF
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: oidc-cluster-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: restricted-user
subjects:
- kind: Group
  name: k8s-restricted-users
EOF

进入全屏模式 退出全屏模式

而已!集群现在已准备好执行一些 OIDC 操作。

使用kubectl连接集群

在我们继续测试之前,我们需要对 kubectl 进行一些设置,以便它知道如何进行 OIDC 身份验证。我们需要为此安装kubelogin插件。继续并使用以下任何命令安装它。

# Homebrew (macOS and Linux)
brew install int128/kubelogin/kubelogin

# Krew (macOS, Linux, Windows and ARM)
kubectl krew install oidc-login

进入全屏模式 退出全屏模式

该插件为 kubectl 启用了 OIDC 登录功能。让我们先测试一下。运行以下命令,确保将k8s_oidc_issuer_url和k8s_oidc_client_id替换为您之前在 Okta 设置期间保存的内容。

kubectl oidc-login setup --oidc-issuer-url=<k8s_oidc_issuer_url> --oidc-client-id=<k8s_oidc_client_id>

进入全屏模式 退出全屏模式

这应该产生如下所示的输出:

authentication in progress...
Opening in existing browser session.

## 2. Verify authentication

You got a token with the following claims:

{
  "sub": "00u28lpcoheT48W5A5d7",
  "ver": 1,
  "iss": "<k8s_oidc_issuer_url>",
  "aud": "<k8s_oidc_client_id>",
  "iat": 1634657188,
  "exp": 1634660788,
  "jti": "ID.AmO7M7Z4xh_rSN4IHVuQEfJ4QuoADOWHSrVHuNyn9so",
  "amr": [
    "pwd"
  ],
  "idp": "0oa28lrldhsBglcC35d7",
  "nonce": "2Rsv7E84vo_K14J6qm9IgKjNsCUxb4Hc16qgzx9CKlk",
  "auth_time": 1634649927,
  "at_hash": "veXQkvqTjCl70OkZnKZVyA",
  "groups": [
    "k8s-admins"
  ]
}

进入全屏模式 退出全屏模式

现在让我们更新 kubectl 配置以添加 OIDC 用户:

kubectl config set-credentials oidc-user \
--exec-api-version=client.authentication.k8s.io/v1beta1 \
--exec-command=kubectl \
--exec-arg=oidc-login \
--exec-arg=get-token \
--exec-arg=--oidc-issuer-url=<k8s_oidc_issuer_url> \
--exec-arg=--oidc-client-id=<k8s_oidc_client_id> \
--exec-arg=--oidc-extra-scope="email offline_access profile openid"

进入全屏模式 退出全屏模式

现在我们可以使用这个用户通过 kubectl 对集群进行身份验证。

kubectl get pods --user=oidc-user -n default

进入全屏模式 退出全屏模式

这应该会打开一个浏览器窗口来对您进行身份验证。您可以使用您的 Okta 帐户凭据登录。

通过与不同组中的不同用户一起玩来测试此 RBAC 配置。不在 Okta 中的k8s-admins组中的用户应该无法访问任何资源。仅属于restricted-users组的用户应该只能看到 pod 和服务。

您可以使用以下命令将此用户设置为当前 kubectl 上下文的默认用户。

kubectl config set-context --current --user=oidc-user

进入全屏模式 退出全屏模式

了解有关在 Kubernetes 中使用 OIDC 的更多信息

使用 OIDC 是保护 Kubernetes 集群的好方法,尤其是在大型团队中。它比任何默认的 Kubernetes 身份验证机制都更安全。最重要的是,它可以让您管理集群中的用户及其角色和权限,甚至为您的集群添加多因素身份验证。

虽然本练习向您展示了 Okta 实现,但该过程对于其他 OIDC 提供程序将非常相似。查看Okta Terraform 提供者文档,看看还有什么可以通过 Terraform 自动化。您还可以使用Kubernetes Terraform 提供程序通过 terraform 自动化 Kubernetes 部分。

如果您想了解有关 Kubernetes、OIDC 或将 OIDC 与 Kubernetes 结合使用的更多信息,请查看这些附加资源。

• OAuth 2.0 和 OpenID Connect 概述

• 管理员对 AWS EKS 集群的安全访问

• 使用 Spring Boot 和 Kubernetes 构建微服务架构

• 使用 Spring Boot 和 JHipster 将 Kubernetes 迁移到云端

• 使用 Okta 高级服务器访问和 Terraform 将身份和基础设施自动化作为代码

• 使用 Terraform Cloud 管理多个 Okta 实例

您可以在 GitHub 上的https://github.com/oktadev/okta-k8s-oidc-terraform-example找到本教程的代码。

如果您喜欢本教程,那么您很可能会喜欢我们发布的其他教程。请在 Twitter 上关注@oktadev和订阅我们的 YouTube 频道,以便在我们发布新的开发人员教程时收到通知。