金鱼哥RHCA回忆录:DO280OpenShift访问控制--管理项目和账户

简介: 第五章 DO280OpenShift访问控制--管理项目和账户
🎹 个人简介:大家好,我是 金鱼哥,CSDN运维领域新星创作者,华为云·云享专家,阿里云社区·专家博主
📚个人资质: CCNA、HCNP、CSNA(网络分析师),软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言:努力不一定成功,但要想成功就必须努力🔥

🎈支持我:可点赞👍、可收藏⭐️、可留言📝


📜Kubetcl namespace

📑namespace描述

Kubernetes namespace提供了将一组相关资源组合在一起的机制。在Red Hat OpenShift容器平台中,project是一个带有附加注释的Kubernetes namespace。

namespace提供以下特性:

  1. 命名资源,以避免基本的命名冲突;
  2. 将管理权限授予受信任的用户;
  3. 限制用户资源消耗的能力;
  4. 用户和用户组隔离。

📑project

project提供了一种机制,通过这种机制可以管理普通用户对资源的访问。project允许一组用户独立于其他组组织和管理其内容,必须允许用户访问项目。如果允许创建项目,用户将自动访问自己的项目。

项目可以有单独的name、display name和description。

  • name是项目的唯一标识符,在使用CLI工具或API时都是基于name,name的最大长度为63个字符。
  • display name是项目在web控制台中显示的方式(默认为name)。
  • description是项目的更详细描述,并且在web控制台中也可见。

以下组件适用于项目:

  • Object:pod、service、rc等;
  • Policies:决定用户可以或不能对对象执行哪些操作的规则;
  • Constraints:可以限制的每种对象的配额。

📑cluster管理

集群管理员可以创建项目并将项目的管理权限委托给任何用户。在OpenShift容器平台中,项目用于对相关对象进行分组和隔离。

管理员可以让用户访问某些项目,允许他们创建自己的项目,并在单个项目中赋予他们管理权限。

管理员可以将角色应用于允许或限制其创建项目能力的用户和组,同时可以在用户初始登录之前分配角色。

限制项目创建:从通过身份验证的用户和组中删除self-provisioning集群角色,将拒绝任何新项目的权限。

[root@master ~]$ oc adm policy remove-cluster-role-from-group \
self-provisioner \
system:authenticated \
system:authenticated:oauth

授予项目创建:项目创建授予具有self-供应者角色和self-provisione集群角色绑定的用户。默认情况下,所有经过身份验证的用户都可以使用这些角色。

[root@master ~]$ oc adm policy add-cluster-role-to-group \
self-provisioner \
system:authenticated \
system:authenticated:oauth

📑创建project

如果项目创建权限被授予用户,则可以使用oc命令创建project。

[root@master ~]$ oc new-project demoproject \
--description="Demonstrate project creation" \
--display-name="demo_project"

📜OpenShift角色

📑角色概述

role具有不同级别的访问和策略,包括集群和本地策略。user和group可以同时与多个role关联。运行oc description命令查看角色及其绑定的详细信息。

在集群策略中具有cluster-admin缺省角色的用户可以查看集群策略和所有本地策略。在给定的本地策略中具有admin缺省角色的用户可以基于per-project查看策略。

可通过以下命令查看当前的集群绑定集,其中显示绑定到不同角色的用户和组。

[root@demo ~]# oc describe clusterPolicyBindings :default

📑查看本地policy

尽管本地角色列表及其关联的规则集在本地策略中是不可查看的,但是所有缺省角色仍然适用,并且可以添加到用户或组中,cluster-admin缺省角色除外。但是,本地绑定是可见的。

可通过以下命令查看当前的本地绑定,其中显示绑定到不同角色的用户和组。

[root@demo ~]# oc describe policyBindings :default

默认情况下,在本地策略中,只会列出admin角色的绑定。但是,如果将其他默认角色添加到本地策略中的用户和组,也会列出它们。


📑管理role绑定

向用户或组添加或绑定角色,从而实现向用户或组提供角色授予的相关访问权限。可以使用oc adm policy命令在用户和组之间添加和删除角色。

当使用以下操作管理本地策略的用户和组角色时,可以使用-n选项指定项目。如果没有指定,则使用当前项目。


常见管理本地策略操作:

命令 描述
oc adm policy who-can verb resource 设置哪些用户可以对资源执行操作
oc adm policy add-role-to-user role username 将指定角色绑定到指定用户
oc adm policy remove-role-from-user role username 从指定用户中移除给定角色
oc adm policy remove-user username 删除指定的用户及其所有角色
oc adm policy add-role-to-group role groupname 将指定的角色绑定到指定的组
oc adm policy remove-role-from-group role groupname 从指定组中移除给定角色
oc adm policy remove-group groupname 删除指定的组及其所有角色

还可以使用如下所示的的操作管理cluster policy的role binding,这类命令不需要-n选项,因为cluster policy不在namespace级别上操作。


常见管理cluster policy操作:

命令 描述
oc adm policy add-cluster-role-to-user role username 将集群中所有项目的指定角色绑定到指定用户
oc adm policy remove-cluster-role-from-user role username 为集群中的所有项目从指定用户中删除指定角色
oc adm policy add-cluster-role-to-group role groupname 为集群中的所有项目将指定的角色绑定到指定的组
oc adm policy remove-cluster-role-from-group role groupname 从集群中所有项目的指定组中移除给定角色

提示:oc policy命令应用于当前项目,而oc adm policy命令应用于集群范围的操作。


示例:在example项目中为developer用户提供admin角色。

[root@demo ~]# oc adm policy add-role-to-user admin developer -n example
[root@demo ~]# oc describe policybindings :default -n example              # 检查绑定

📜安全上下文约束(SCCS)

📑SCCS概述

OpenShift提供安全上下文约束(SCCS security context constraints),它控制pod可以执行的操作和它可以访问的资源。默认情况下,任何容器的执行都只授予受限制的SCC定义的功能。

SCCS相关命令:

[user@demo ~]$ oc get scc                                    # 列出可用的SCC
[user@demo ~]$ oc describe scc scc_name                        # 现实特定SCC详细信息
[user@demo ~]$ oc adm policy add-scc-to-user scc_name user_name
[user@demo ~]$ oc adm policy add-scc-to-group scc_name group_name    # 要授予用户或组特定的SCC
[user@demo ~]$ oc adm policy remove-scc-from-user scc_name user_name
[user@demo ~]$ oc adm policy remove-scc-from-group scc_name group_name    # 从特定的SCC中删除用户或组

📜服务账户

📑服务账户

service account提供了一种灵活的方法来控制API访问,而无需共享常规用户的凭据。如果应用程序需要访问受限制的SCC未授予的功能,可创建一个新的、特定的service account并将其添加到适当的SCC中。

例如,在缺省情况下,OpenShift不支持部署需要提升特权的应用程序。若有此需求,可创建一个service account,修改dc,然后添加service account至SCC。

示例:将anyuid配置为在容器中作为root用户运行。

[user@demo ~]$ oc create serviceaccount useroot  # 创建一个名为useroot的新服务帐户
[user@demo ~]$ oc patch dc/demo-app \
--patch '{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}'  # 修改应用程序的DC
[user@demo ~]$ oc adm policy add-scc-to-user anyuid -z useroot   # 将useroot服务帐户添加到anyuid SCC中,作为容器中的根用户运行

📑Web管理user成员

OCP平台的默认配置是,在用户首次登录成功时,自动创建该用户对象。

要管理允许访问项目的用户,请以项目管理员或集群管理员的身份登录到web控制台,并选择要管理的项目。在左侧窗格中,单击Resources——>membership进入项目member页面。

在Users列中,在突出显示的文本框中输入用户名。在“添加另一个角色”列中,从用户所在行的列表中选择一个角色,然后单击“添加”。

在这里插入图片描述


📑Cli管理user成员

CLI中如果自动创建对象功能被关闭,集群管理员可通过如下方式创建新用户:

[root@master ~]$ oc create user demo-user

同时还需要在身份认证软件中创建用户,如为HTPasswdIdentityProvider才用户命令如下:

[root@master ~]$ htpasswd /etc/origin/openshift-passwd demo-user

要向用户添加项目角色,首先使用oc project命令输入项目,然后使用oc policy add-role-to-user命令:

[root@master ~]$ oc policy add-role-to-user edit demo-user

要从用户中删除项目角色,使用oc policy remove-role-from-user命令:

[root@master ~]$ oc policy remove-role-from-user edit demo-user

并不是所有OpenShift角色都由项目限定范围。要分配这些规则,请使用oc adm policy command命令。

[root@master ~]$ oc adm policy add-cluster-role-to-user cluster-admin admin

📑身份验证和授权

身份验证层标识与对OpenShift容器平台API的请求相关联的用户,然后授权层使用关于请求用户的身份信息来确定是否应该允许该请求。


  • user和group

OCP容器平台中的用户是一个可以向OpenShift API发出请求的实体。通常,这表示与OpenShift交互的developer或administrator的帐户。

可以将用户分配给一个或多个组,每个组表示一组特定的角色(或权限)。当需要通过管理授权策略给多个客户授权时候,group会比较合适。例如允许访问项目中的对象,而不是单独授予用户。


  • Authentication Tokens

API调用必须使用访问令牌或X.509证书进行身份验证,会话token表示用户,并且是短期的,默认情况下在24小时内到期。

可以通过运行oc whoami命令来验证经过身份验证的用户。

[root@master ~]$ oc login -u demo-user
[root@master ~]$ oc whoami
demo-user

📑身份验证类型

本环境中,身份验证由HTPasswdIdentityProvider模块提供,该模块根据使用htpasswd命令生成的文件验证用户名和密码。

OpenShift容器平台支持的其他认证类型包括:

  • Basic Authentication (Remote)

一种通用的后端集成机制,允许用户使用针对远程标识提供者验证的凭据登录到OpenShift容器平台。用户将他们的用户名和密码发送到OpenShift容器平台,OpenShift平台通过到服务器的请求验证这些凭据,并将凭据作为基本的Auth头传递。这要求用户在登录过程中向OpenShift容器平台输入他们的凭据。


  • Request Header Authentication

用户使用请求头值(如X-RemoteUser)登录到OpenShift容器平台。它通常与身份验证代理结合使用,身份验证代理对用户进行身份验证,然后通过请求头值为OpenShift容器平台提供用户标识。


  • Keystone Authentication

Keystone是一个OpenStack项目,提供标识、令牌、目录和策略服务。OpenShift容器平台与Keystone集成,通过配置OpenStack Keystone v3服务器将用户存储在内部数据库中,从而支持共享身份验证。这种配置允许用户使用Keystone凭证登录OpenShift容器平台。


  • LDAP Authentication

用户使用他们的LDAP凭证登录到OpenShift容器平台。在身份验证期间,LDAP目录将搜索与提供的用户名匹配的条目。如果找到匹配项,则尝试使用条目的专有名称(DN)和提供的密码进行简单绑定。


  • GitHub Authentication

GitHub使用OAuth,它允许与OpenShift容器平台集成使用OAuth身份验证来促进令牌交换流。这允许用户使用他们的GitHub凭证登录到OpenShift容器平台。为了防止使用GitHub用户id的未授权用户登录到OpenShift容器平台集群,可以将访问权限限制在特定的GitHub组织中。


📜课本练习

📑环境准备

[student@workstation ~]$ lab install-prepare setup
[student@workstation ~]$ cd /home/student/do280-ansible
[student@workstation do280-ansible]$ ./install.sh

提示:若已经拥有一个完整环境,可不执行。


📑本练习准备

[student@workstation ~]$ lab secure-resources setup

📑创建htpasswd账户

[student@workstation ~]$ ssh root@master
Last login: Tue Mar  2 19:43:11 2021 from workstation.lab.example.com
[root@master ~]# htpasswd -b /etc/origin/master/htpasswd user1 redhat
Adding password for user user1
[root@master ~]# htpasswd -b /etc/origin/master/htpasswd user2 redhat
Adding password for user user2
# 添加基于htpasswd形式的user1和user2,密码都为redhat。

📑设置策略

[student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com    #使用管理员登录
[student@workstation ~]$ oc adm policy remove-cluster-role-from-group self-provisioner system:authenticated system:authenticated:oauth
#删除所有赋予普通创建项目的功能,该命令可参考本环境如下目录中的命令。
[student@workstation ~]$ cat /home/student/DO280/labs/secure-resources/configure-policy.sh
#!/bin/bash
oc adm policy remove-cluster-role-from-group \
    self-provisioner system:authenticated system:authenticated:oauth

温馨提示:可参考环境PDF资料 《cluster-administration》中的第10章,可使用oc describe clusterrolebinding.rbac | more 命令进行辅助。


📑验证策略

[student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com
Login successful.

You don't have any projects. Contact your system administrator to request a project.
[student@workstation ~]$ oc new-project test
Error from server (Forbidden): You may not request a new project via this API.

📑创建项目

[student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com
[student@workstation ~]$ oc new-project project-user1
[student@workstation ~]$ oc new-project project-user2

📑将项目与user关联

#选择项目1
[student@workstation ~]$ oc project project-user1
Now using project "project-user1" on server "https://master.lab.example.com:443".
[student@workstation ~]$ oc policy add-role-to-user admin user1        # 将user1添加为项目1的管理员
role "admin" added: "user1"
[student@workstation ~]$ oc policy add-role-to-user edit user2        # 将user2添加为项目1的开发员
role "edit" added: "user2"
[student@workstation ~]$ oc project project-user2                    # 选择项目2
Now using project "project-user2" on server "https://master.lab.example.com:443".
[student@workstation ~]$ oc policy add-role-to-user edit user2        # 将user2添加为项目2的开发员
role "edit" added: "user2"

📑验证访问

[student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com    # 使用user1登录
[student@workstation ~]$ oc project project-user1                    # 验证项目1的访问
Already on project "project-user1" on server "https://master.lab.example.com:443".
[student@workstation ~]$ oc project project-user2                    # 验证项目2的访问
error: You are not a member of project "project-user2".
You have one project on this server: project-user1
[student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com    # 使用user2登录
[student@workstation ~]$ oc project project-user1          # 验证项目1的访问
Already on project "project-user1" on server "https://master.lab.example.com:443".    
[student@workstation ~]$ oc project project-user2          # 验证项目2的访问
Now using project "project-user2" on server "https://master.lab.example.com:443".    

📑部署特权应用

[student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com
Login successful.

You have access to the following projects and can switch between them with 'oc project <projectname>':

    project-user1
  * project-user2

Using project "project-user2".

[student@workstation ~]$ oc project project-user1
Now using project "project-user1" on server "https://master.lab.example.com:443".


[student@workstation ~]$ oc new-app --name=nginx --docker-image=registry.lab.example.com/nginx:latest
--> Found Docker image c825216 (2 years old) from registry.lab.example.com for "registry.lab.example.com/nginx:latest"

    * An image stream will be created as "nginx:latest" that will track this image
    * This image will be deployed in deployment config "nginx"
    * Port 80/tcp will be load balanced by service "nginx"
    * Other containers can access this service through the hostname "nginx"
    * WARNING: Image "registry.lab.example.com/nginx:latest" runs as the 'root' user which may not be permitted by your cluster administrator
# 使用在项目1上不具备admin权限的用户user2登录,并部署应用,会出现的提示。
--> Creating resources ...
    imagestream "nginx" created
    deploymentconfig "nginx" created
    service "nginx" created
--> Success
    Application is not exposed. You can expose services to the outside world by executing one or more of the commands below:
     'oc expose svc/nginx' 
    Run 'oc status' to view your app.

📑验证部署

[student@workstation ~]$ oc get pods
NAME             READY     STATUS             RESTARTS   AGE
nginx-1-66tqq    0/1       CrashLoopBackOff   4          1m
nginx-1-deploy   1/1       Running            0          1m

结论:由上可知,部署失败是因为容器镜像需要root用户,pod以CrashLoopBackOff或错误状态结束。


📑故障排除

若要解决此故障需要减少特定项目的安全限制。

要使用特权访问运行容器,可创建一个允许pod使用操作系统普通用户运行的service account。

如下部分需要具有项目管理员特权的用户执行,而另一些操作需要具有集群管理员特权的用户执行。

本环境中,相关操作命令可以从/home/student/DO280/labs/secure-resources文件夹中的configure-sc.sh脚本运行或复制。

[student@workstation ~]$ oc login -u user1 -p redhat https://master.lab.example.com    # 使用项目1的admin账户登录
[student@workstation ~]$ oc create serviceaccount useroot          # 创建服务账户
serviceaccount "useroot" created
[student@workstation ~]$ oc login -u admin -p redhat https://master.lab.example.com    # 使用集群管理员登录
[student@workstation ~]$ oc project project-user1                  # 选择项目1
Already on project "project-user1" on server "https://master.lab.example.com:443".
[student@workstation ~]$ oc adm policy add-scc-to-user anyuid -z useroot  # 设置SCC策略
scc "anyuid" added to: ["system:serviceaccount:project-user1:useroot"]    # 将服务帐户与anyuid安全上下文关联,此操作需要集群管理员用户。

在这里插入图片描述

[student@workstation ~]$ oc login -u user2 -p redhat https://master.lab.example.com    # 切换user2用户
[student@workstation ~]$ oc project project-user1
Already on project "project-user1" on server "https://master.lab.example.com:443".
[student@workstation ~]$ oc patch dc nginx --patch='{"spec":{"template":{"spec":{"serviceAccountName": "useroot"}}}}'
# 可使用oc edit deploymentconfig nginx 来进行修改

📑验证确认

[student@workstation ~]$ oc get pods
NAME             READY     STATUS    RESTARTS   AGE
nginx-1-deploy   0/1       Error     0          45m
nginx-2-c2wfp    1/1       Running   0          2m

📑暴露服务

[student@workstation ~]$ oc expose svc nginx 
route "nginx" exposed
[student@workstation ~]$ oc get svc
NAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx     ClusterIP   172.30.195.234   <none>        80/TCP    47m
[student@workstation ~]$ oc get route 
NAME      HOST/PORT                                  PATH      SERVICES   PORT      TERMINATION   WILDCARD
nginx     nginx-project-user1.apps.lab.example.com             nginx      80-tcp                  None

📑测试访问

[student@workstation ~]$ curl http://nginx-project-user1.apps.lab.example.com
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
……………

📑策略删除演示

\#为所有常规用户重新启用项目创建,即重置为初始状态。本环境中,相关操作命令可以从/home/student/DO280/labs/secure-resources文件夹中的restore-policy.sh脚本运行或复制。

[student@workstation ~]$ oc login -u admin -p redhat
[student@workstation ~]$ oc adm policy add-cluster-role-to-group self-provisioner system:authenticated system:authenticated:oauth
cluster role "self-provisioner" added: ["system:authenticated" "system:authenticated:oauth"]
[student@workstation ~]$ oc delete project project-user1
[student@workstation ~]$ oc delete project project-user2

[root@master ~]# htpasswd -D /etc/origin/master/htpasswd user1
[root@master ~]# htpasswd -D /etc/origin/master/htpasswd user2

💡总结

RHCA认证需要经历5门的学习与考试,还是需要花不少时间去学习与备考的,好好加油,可以噶🤪。

以上就是【金鱼哥】对 第五章 DO280OpenShift访问控制--管理项目和账户 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾 红帽认证专栏系列:
RHCSA专栏: 戏说 RHCSA 认证
RHCE专栏: 戏说 RHCE 认证
此文章收录在RHCA专栏: RHCA 回忆录

如果这篇【文章】有帮助到你,希望可以给【金鱼哥】点个赞👍,创作不易,相比官方的陈述,我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣,也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️,我将会给你带来巨大的【收获与惊喜】💕💕!

相关实践学习
云安全基础课 - 访问控制概述
课程大纲 课程目标和内容介绍视频时长 访问控制概述视频时长 身份标识和认证技术视频时长 授权机制视频时长 访问控制的常见攻击视频时长
目录
相关文章
|
存储 应用服务中间件 开发工具
Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径(四)|学习笔记
快速学习 Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径
132 0
Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径(四)|学习笔记
|
监控 Ubuntu JavaScript
Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径(三)
Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径(三)
381 0
Nginx location 基础使用、四层访问控制、账户认证及自定义日志路径(三)
|
运维 安全 关系型数据库
金鱼哥RHCA回忆录:DO280OpenShift访问控制--security policy和章节实验
第五章 DO280OpenShift访问控制--security policy和章节实验
160 0
金鱼哥RHCA回忆录:DO280OpenShift访问控制--security policy和章节实验
|
存储 运维 关系型数据库
金鱼哥RHCA回忆录:DO280OpenShift访问控制--加密和ConfigMap
第五章 DO280OpenShift访问控制--加密和ConfigMap
182 0
金鱼哥RHCA回忆录:DO280OpenShift访问控制--加密和ConfigMap
|
安全 Java 数据管理
基于角色访问控制RBAC权限模型的动态资源访问权限管理实现
前面主要介绍了元数据管理和业务数据的处理,通常一个系统都会有多个用户,不同用户具有不同的权限,本文主要介绍基于RBAC动态权限管理在crudapi中的实现。RBAC权限模型(Role-Based Access Control)即:基于角色的权限控制。模型中有几个关键的术语: 用户:系统接口及访问的操作者 权限:能够访问某接口或者做某操作的授权资格 角色:具有一类相同操作权限的用户的总称 。 #### 用户角色权限关系 一个用户有一个或多个角色 一个角色包含多个用户 一个角色有多种权限 一个权限属于多个角色
665 0
基于角色访问控制RBAC权限模型的动态资源访问权限管理实现
|
安全 数据安全/隐私保护 网络虚拟化