什么是Kubernetes RBAC？为什么需要它？
目录
什么是Kubernetes RBAC?
如何启用Kubernetes RBAC
1.服务帐户
2.角色和集群角色
3.角色绑定和集群角色绑定
Kubernetes RBAC的好处
1.适当的授权
2.职责分离
3.100%遵守法规
Kubernetes RBAC的缺点
企业软件开发工具
什么是Kubernetes RBAC?
当组织开始走上Kubernetes之旅时，在通常情况下，他们希望实现最低权限角色和适当的授权来保护他们的基础设施。这就是实现Kubernetes RBAC以保护Kubernete资源的地方，例如敏感数据，包括部署细节、持久存储设置和机密。Kubernetes RBAC提供了控制谁能够以何种访问方式访问每个API资源的能力。组织可以为人类用户（个人或组）和非人类用户（服务帐户）使用RBAC来定义他们对各种Kubernetes资源的访问类型。
例如，有Dev、Staging和Production三个不同的环境，必须向团队(例如开发人员、DevOps人员、SRE、应用程序所有者和产品经理)提供访问权限。
在开始之前需要强调一下，从抽象的角度来看，将把用户和服务帐户视为相同的——每个请求，无论是来自用户还是服务帐户，最终都是HTTP请求。人们知道Kubernetes中的用户和服务帐户（针对非人类用户）本质上是不同的。
如何启用Kubernetes RBAC
可以在Kubernetes中启用RBAC，这种方法是启动带有授权模式标志的API服务器。用于向用户应用RBAC的Kubernetes资源有：
- 角色（Role）
- 集群角色（ClusterRole）
- 角色绑定（RoleBinding）
- 集群角色绑定（ClusterRoleBinding）
1.服务帐户
为了管理用户，Kubernetes提供了一种身份验证机制，但通常建议将Kubernetes与企业用户身份管理(如Active Directory或LDAP)集成在一起。当涉及到Kubernetes集群中的非人类用户(或机器或服务)时，就出现了服务帐户的概念。
例如，Kubernetes资源需要由Spinnaker或Argo等持续交付(CD)应用程序访问才能部署应用程序，或者服务A的一个pod需要与服务B的另一个pod对话。在这种情况下，服务帐户用于创建非人类用户的帐户并指定所需授权（使用角色绑定或集群角色绑定）。
可以通过创建如下所示的yaml来创建一个服务帐户：
YAML
apiVersion: v1
kind: ServiceAccount
metadata:
name: nginx-sa
spec:
automountServiceAccountToken: false然后应用它。
Shell
$ kubectl apply -f nginx-sa.yaml
serviceaccount/nginx-sa created现在，必须为部署资源中的pod提供服务帐户。
YAML
kind: Deployment
metadata:
name: nginx1
labels:
app: nginx1
spec:
replicas: 2
selector:
matchLabels:
app: nginx1
template:
metadata:
labels:
app: nginx1
spec:
serviceAccountName: nginx-sa
containers:
- name: nginx1
image: nginx
ports:
- containerPort: 80如果没有在部署资源中指定服务帐户名称（serviceAccountName），那么pod将属于默认的服务帐户。需要注意的是，每个命名空间都有一个默认的服务帐户，集群也有一个默认的服务帐户。默认服务帐户的所有默认授权策略将应用于未提及服务帐户信息的pod。
以下可以看到如何使用角色绑定和集群角色绑定为服务帐户分配各种权限。
2.角色和集群角色
角色（Role）和集群角色（ClusterRole）是Kubernetes资源分别用于定义用户可以在命名空间或集群中执行的操作列表。
在Kubernetes中，参与者(如用户、组或服务帐户)被称为主题。主体的动作，如创建、读取、写入、更新和删除，称为操作。
YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: read-only
namespace: dev-namespace
rules:
- apiGroups:
- ""
resources: ["*"]
verbs:
- get
- list
- watch在上面的角色资源中，指定了只读角色仅适用于deb-ns命名空间和命名空间内的所有资源。任何绑定到只读角色的服务帐户或用户都可以执行这些操作——获取、列出和监视。
类似地，集群角色（资源将允许创建与集群相关的角色）。下面是一个例子：
YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: chief-role
rules:
- apiGroups:
- ""
resources: ["*"]
verbs:
- get
- list
- watch
- create
- update
- patch
- delete任何绑定到chief-role的用户/组/服务帐户都可以在集群中执行任何操作。
在下一节中，将看到如何使用角色绑定和集群角色绑定向主题授予角色。
另外，Kubernetes允许使用角色资源配置自定义角色，或者使用默认的面向用户的角色，如下所示：
- 集群管理员（Cluster-admin）：对于集群管理员，Kubernetes提供了一个超级用户角色。集群管理员可以对集群中的任何资源执行任何操作。可以在集群角色绑定中使用超级用户来授予对集群(和所有命名空间)中的每个资源的完全控制权，也可以在角色绑定中使用超级用户来授予对各自命名空间中的每个资源的完全控制权。
- 管理员（Admin）：Kubernetes提供了一个管理员角色，允许对命名空间内的资源进行无限制的读/写访问。管理员角色可以在特定的命名空间内创建角色和角色绑定。它不允许对命名空间本身进行写访问。这可以在角色绑定的资源中使用。
- 编辑（Edit）：编辑角色在给定的Kubernetes命名空间内授予读/写访问权限。它无法查看或修改角色或角色绑定。
- 视图（View）：视图角色允许在给定的命名空间内进行只读访问。它不允许查看或修改角色或角色绑定。
3.角色绑定和集群角色绑定
要将角色应用于主题（用户/组/服务帐号），必须定义角色绑定。这将使用角色配置中定义的权限为用户提供对命名空间内所需资源的最低权限访问。
YAML
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: Role-binding-dev
roleRef:
kind: Role
name: read-only #The role name you defined in the Role configuration
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: Roy #The name of the user to give the role to
apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
name: nginx-sa#The name of the ServiceAccount to give the role to
apiGroup: rbac.authorization.k8s.io类似地，可以创建集群角色绑定资源来定义用户的角色。需要注意的是，使用了Kubernetes提供的默认超级用户集群角色引用，而不是使用自定义角色。这可以应用于集群管理员。
YAML
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: superuser-binding
roleRef:
kind: ClusterRole
name: superuser
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: Aditi
apiGroup: rbac.authorization.k8s.ioKubernetes RBAC的好处
Kubernetes RBAC的优势在于它允许“原生”实现对集群中各种用户和机器的最小权限。主要的好处是：
1.适当的授权
通过对各种用户和服务帐户授予Kubernetes资源的最小权限，是DevOps和架构师可以实现零信任的主要支柱之一。组织可以减少数据泄露和数据泄露的风险，还可以避免内部员工意外删除或操纵任何关键资源。
2.职责分离
在Kubernetes资源上应用RBAC将始终有助于组织中用户(例如开发人员、DevOps、测试人员、SRE等)的职责分离。例如，为了在开发环境中创建/删除新资源，开发人员不应该依赖于管理员。同样，将新应用程序部署到测试服务器并在测试后删除pod不应该成为DevOps或测试人员的瓶颈。将授权和权限应用到用户(如开发人员和CI/CD部署代理)各自的工作空间(如命名空间或集群)将减少依赖并减少懈怠。
3.100%遵守法规
许多行业法规（例如HIPAA、GDPR、SOX等）都要求软件领域有严格的认证和授权机制。使用Kubernetes RBAC，DevOps和架构师可以快速地将RBAC实现到他们的Kubernetes集群中，并改进他们的设置以遵守这些标准。
Kubernetes RBAC的缺点
对于中小型企业来说，使用Kubernetes RBAC是合理的，但不建议使用Kubernetes RBAC，其原因如下：
- 可能有许多用户和机器，并且应用Kubernetes RBAC可能难以实现和维护。
- 很难看到谁执行了什么操作。例如，大型企业可能需要诸如违反RBAC权限或恶意尝试之类的信息。
企业软件开发工具
JNPF开发平台，很多人都用过它，它是功能的集大成者，任何信息化系统都可以基于它开发出来。
原理是将开发过程中某些重复出现的场景、流程，具象化成一个个组件、api、数据库接口，避免了重复造轮子。因而极大的提高了程序员的生产效率。
官网：http://www.jnpfsoft.com/?csdn，如果你有闲暇时间，可以做个知识拓展。
这是一个基于Java Boot/.Net Core构建的简单、跨平台快速开发框架。前后端封装了上千个常用类，方便扩展；集成了代码生成器，支持前后端业务代码生成，满足快速开发，提升工作效率；框架集成了表单、报表、图表、大屏等各种常用的Demo方便直接使用；后端框架支持Vue2、Vue3。平台即可私有化部署，也支持K8S部署。
为了支撑更高技术要求的应用开发，从数据库建模、Web API构建到页面设计，与传统软件开发几乎没有差异，只是通过低代码可视化模式，减少了构建“增删改查”功能的重复劳动。