OpenShift 4的身份认证 | 让我们重新认识OpenShift系列2

User

在OpenShift容器平台体系结构中,用户是与API Server进行交互的实体。用户资源是系统内参与者的表示。通过直接向用户或用户所属的组添加角色来分配权限。


Identity 身份识别

Identity是一种资源,用于记录来自特定用户和身份提供者的成功身份验证尝试。有关身份验证来源的任何数据都存储在身份上。仅单个用户资源与身份资源相关联。


Service Account

在OpenShift中,当无法获取用户credentials时,应用程序可以独立与API通信。为了保持普通用户credentials的完整性,不共享credentials,而是使用Service Account。Service Account使您可以控制API访问,而无需借用普通用户的credentials。


Group

组代表一组特定的用户。用户被分配到一个或多个组。在实施授权策略以同时向多个用户分配权限时,可以利用组。例如,如果要允许二十个用户访问项目中的对象,则使用组而不是单独授予每个用户访问权限是有利的。OpenShift容器平台还提供了由群集自动设置的系统组或虚拟组。


Roles

Roles是一组权限,使用户可以对一种或多种资源类型执行API操作。您可以通过向用户,组和service account分配角色来为其授予权限。



验证API请求

授权和身份验证是两个安全层,负责使用户能够与群集进行交互。当用户向API发出请求时,该用户与该请求相关联。认证层负责识别用户。然后,来自身份验证层的有关发出请求的用户的信息将由授权层使用,以确定是否满足该请求。验证用户身份后,RBAC策略将确定该用户有权执行的操作。如果API请求包含无效的身份验证,则匿名系统用户会将其认证为请求。


OpenShift API有两种用于验证请求的方法:

  • OAuth访问令牌

  • X.509客户端证书


如果请求中没有提供访问令牌或证书,则认证层会为它分配system:anonymous虚拟用户和system:unauthenticated虚拟组。


Authentication Operator

OpenShift容器平台提供了运行OAuth服务器的身份验证Operator。当用户尝试向API进行身份验证时,OAuth Server会向用户提供OAuth访问令牌。必须配置Identity Providers,并且该身份提供者可用于OAuth服务器。OAuth服务器使用Identity Providers来验证请求者的身份。服务器将用户与身份进行协调,并创建OAuth  Token,然后将其授予用户。身份和用户资源是在登录时自动创建的。


Identity Providers种类

可以将OpenShift OAuth服务器配置为使用许多Identity Providers。包括:

  • HTPasswd

    根据存储使用htpasswd生成的credentials的secret验证用户名和密码。

  • Keystone

    启用与OpenStack Keystone v3服务器的共享身份验证。

  • LDAP

    使用简单绑定身份验证,配置LDAP身份提供程序以针对LDAPv3服务器验证用户名和密码。

  • GitHub或GitHub Enterprise

    配置GitHub身份提供者以针对GitHub或GitHub Enterprises OAuth身份验证服务器验证用户名和密码。

  • OpenID连接

    使用授权代码流与OpenID Connect身份提供者集成。

    必须使用所需的身份提供者更新OAuth自定义资源。您可以在同一OAuth自定义资源上定义相同或不同种类的多个身份提供者。


如何验证集群管理员身份

必须先以群集管理员身份访问OpenShift群集,然后才能配置身份提供者和管理用户。刚刚安装的OpenShift集群提供了两种通过集群管理员特权对API请求进行身份验证的方法:

  • 使用被赋予了OAuth access token的kubeadmin虚拟用户和密码登录

  • 使用Thekubeconfig文件登录,这个文件中包含一个永不过去的X.509 client certificate


要创建其他用户并为他们授予不同的访问级别,必须配置身份提供者并将角色分配给用户。


使用X.590证书进行身份验证

kubeconfig文件是在安装过程中创建的,并且特定于集群。它存储在OpenShift安装程序在安装过程中创建的auth目录中。该文件包含CLI用来将客户端连接到正确的API服务器的特定详细信息和参数,包括X.509证书。


安装日志提供保存kubeconfig文件的位置:

export KUBECONFIG = root/auth/kubeconfig

要使用kubeconfig文件对命令进行身份验证,必须将文件复制到工作站,并设置KUBECONFIG环境变量的绝对或相对路径。然后,您无需登录OpenShift即可运行需要集群管理员权限的任何操作。


$ export KUBECONFIG=/home/user / auth/kubeconfig 



使用虚拟用户进行身份验证

安装完成后,OpenShift将创建kubeadmin虚拟用户。该虚拟用户没有用户或身份资源。kubeadminuser被硬编码为集群管理员,您不能更改其特权。它还使用来自kube-system project的存储的inkubeadmin密码进行了硬编码以进行身份验证。


kubeadmin password由安装程序动态生成,并且对于您的环境完全唯一。安装日志提供用于登录集群的kubeadmin credentials。群集安装日志还提供登录名,密码和用于控制台访问的URL。



定义身份提供者,创建新用户并为该用户分配集群管理员后,可以删除kubeadmin用户credentials以提高群集安全性。


oc delete secret kubeadmin -n kube-system


配置HTPasswd身份提供程序

HTPasswd身份提供程序根据包含来自Apache HTTP Server项目的htpasswd命令生成的用户名和密码的机密验证用户。仅允许群集管理员更改密码内部的数据。普通用户不能更改自己的密码。


使用HTPasswd身份提供程序管理用户可能只需要一小组用户的概念验证环境就足够了。但是,大多数生产环境需要与组织的身份管理系统集成的更强大的身份提供程序。


配置OAuth自定义资源

要使用HTPasswd身份提供者,必须编辑OAuth自定义资源以将条目添加到.spec.identityProviders数组中:

apiVersion: config.openshift.io/v1

kind: OAuth

metadata:

  name: cluster

spec:

  identityProviders:

  - name: my_htpasswd_provider 1

    mappingMethod: claim 2

    type: HTPasswd

    htpasswd:

      fileData:

        name: htpass-secret 3


1:该提供程序名称以提供程序用户名为前缀,以形成身份名称。

2:控制如何在提供者身份和用户对象之间建立映射。

3:现有机密,其中包含使用htpasswd命令生成的数据。


更新OAuth自定义资源

要编辑更新的OAuth自定义资源,请使用oc get命令将现有的OAuth群集资源导出到YAML格式的文件中。


oc get -o yaml oauth cluster > oauth.yaml


然后,在文本编辑器中打开生成的文件,并对嵌入式标识提供程序设置进行必要的更改。

OpenShift 4的身份认证 | 让我们重新认识OpenShift系列2

完成修改并保存文件后,必须使用oc replace命令应用新的自定义资源。


$ oc create -f oauth.yaml


HTPasswd Secret

要使用HTPasswd提供程序,必须创建一个包含htpasswd文件数据的密钥。在以下示例中,该机密名为htp-secret。

oc create secret generic htp-secret --from-file htpasswd=/home/user/htpasswd -n openshift-config


更新HTPasswd secret

添加,更改或删除用户后,必须更新机密。机密内的所有数据都必须使用base64进行编码。编码数据的一种方法是使用theoc create secret,就像您要创建一个新的秘密并将输出YAML发送到标准输出一样。然后,您可以将该输出传递给toc replace命令以更新现有机密。要更新名为htp-secret的机密,请运行以下命令:

oc create secret generic htp-secret --from-file htpasswd=/path/to/your/file  --dry-run -o yaml | oc replace -n openshift-config -f -


当您在更新密码后尝试登录时,可能会收到错误消息。如果发生这种情况,请稍等片刻,然后尝试再次登录。成功完成oc create secret命令后,OAuth操作符将重新加载,并且需要一些时间来更新密钥中的数据。

提取秘密数据


添加或删除用户时,管理员无法假定本地htpasswd文件的有效性。此外,管理员甚至可能不在具有htpasswd文件的系统上。在现实世界中,管理员应该使用oc extract命令。extract命令将配置映射或密钥的内容下载到目录中。然后可以将数据重定向到文件或显示为标准输出。要从机密中提取数据并将其重定向到文件名temp,请使用以下命令:

 extract secret/htp-secret -n openshift-config --to - > temp


使用HTPasswd身份提供商管理用户

使用HTPasswd身份提供程序管理用户凭据需要创建一个临时的htpasswd文件,对文件进行更改,并将这些更改应用于机密。


创建一个HTPasswd文件

Thehtpasswdutility是httpd-utils软件包的一部分,必须已安装且在系统上可用。


创建或更新htpasswd文件。

htpasswd -c -B -b htpasswd student redhat123

添加或更新凭据。

htpasswd -b htpasswd student redhat1234

创建HTPasswd秘密

要使用HTPasswd提供程序,必须创建一个包含htpasswd文件数据的密钥。在以下示例中,该机密名为htp-secret。

oc create secret generic htp-secret \>--from-file htpasswd=/home/user/htpasswd -n openshift-config

更新HTPasswd机密

添加,更改或删除用户后,必须更新机密。 机密内的所有数据都必须使用base64进行编码。 编码数据的一种方法是使用theoc create secret,就像您要创建一个新的秘密并将输出YAML发送到标准输出一样。 然后,您可以将该输出通过管道传递给theoc replace命令以更新现有机密。 要更新名为htp-secret的机密,请运行以下命令:

[user@demo ~]$oc create secret generic htp-secret \>--from-file htpasswd=/path/to/your/file  --dry-run -o yaml \>| oc replace -n openshift-config -f -

当您在更新密码后尝试登录时,可能会收到错误消息。 如果发生这种情况,请稍等片刻,然后尝试再次登录。 成功完成previousoc create secret命令后,OAuth操作符将重新加载,并且需要一些时间来更新密钥中的数据。


提取秘密数据

添加或删除用户时,管理员无法假定本地htpasswd文件的有效性。 此外,管理员甚至可能不在具有htpasswd文件的系统上。 在现实世界中,管理员应该使用theoc extract命令。 extract命令将配置映射或密钥的内容下载到目录中。 然后可以将数据重定向到文件或显示为标准输出。 要从机密中提取数据并将其重定向到文件名temp,请使用以下命令:

oc extract secret/htp-secret -n openshift-config \>--to - > temp


删除Users和Identities

当我们要删除用户的时候,光在 identity provider中删除用户是不够的。user 和identity resources 也必须被删除。

必须从htpasswd secret中删除用户的密码;用户名必须从l htpasswd file中删除。然后secret 必须更新。

从htpasswd中删除用户:

htpasswd -D temp manager

更新密码以删除用户密码的所有残余。

$oc create secret generic htp-secret \>--from-file htpasswd=/home/user/temp  --dry-run -o yaml \>| oc replace -n openshift-config -f -

使用以下命令删除用户资源:

$oc delete user manager

要删除所有身份资源,请运行以下命令:

$oc delete identity manager

群集范围内的群集管理角色向用户和组授予群集管理特权。它使用户可以对集群中的任何资源执行任何操作。在下面的示例中,将群集管理员分配给特定用户:

$oc adm policy add-cluster-role-to-user cluster-admin david

 


上一篇:「Nginx」- 配置基本认证(Basic Authentication) @20210217


下一篇:nginx 高级应用