Add en multi-tanancy and update its zhcn version

Signed-off-by: Sherlock113 <sherlockxu@yunify.com>
This commit is contained in:
Sherlock113 2020-12-09 16:37:15 +08:00
parent fb32728a4b
commit f1d72ea829
9 changed files with 85 additions and 29 deletions

View File

@ -4,7 +4,7 @@ keywords: "LDAP, identity provider"
description: "How to configure identity provider"
linkTitle: "Configure Authentication"
weight: 12100
weight: 12200
---
## Objective

View File

@ -0,0 +1,59 @@
---
title: "Multi-Tenancy in KubeSphere"
keywords: "Kubernetes, Kubesphere, multi-tenancy"
description: "Understand multi-tenancy in KubeSphere."
linkTitle: "Multi-Tenancy in KubeSphere"
weight: 12100
---
Kubernetes helps you orchestrate applications and schedule containers, greatly improving resource utilization. However, there are various challenges facing both enterprises and individuals in resource sharing and security as they use Kubernetes, which is different from how they managed and maintained clusters in the past.
The first and foremost challenge is how to define multi-tenancy in an enterprise and the security boundary of tenants. [The discussion about multi-tenancy](https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY) has never stopped in the Kubernetes community, while there is no definite answer to how a multi-tenant system should be structured.
## Challenges in Kubernetes Multi-Tenancy
Multi-tenancy is a common software architecture. Resources in a multi-tenant environment are shared by multiple users, also known as "tenants", with their respective data isolated from each other. The administrator of a multi-tenant cluster must minimize the damage that a compromised or malicious tenant can do to others and make sure resources are fairly allocated.
No matter how an enterprise multi-tenant system is structured, it always comes with the following two building blocks: logical resource isolation and physical resource isolation.
Logically, resource isolation mainly entails API access control and tenant-based permission control. [Role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in Kubernetes and namespaces provide logic isolation. Nevertheless, they are not applicable in most enterprise environments. Tenants in an enterprise often need to manage resources across multiple namespaces or even clusters. Besides, the ability to provide auditing logs for isolated tenants based on their behavior and event queries is also a must in multi-tenancy.
The isolation of physical resources includes nodes and networks, while it also relates to container runtime security. For example, you can create [NetworkPolicy](../../pluggable-components/network-policy/) resources to control traffic flow and use PodSecurityPolicy objects to control container behavior. [Kata Containers](https://katacontainers.io/) provides a more secure container runtime.
## Multi-Tenancy in KubeSphere
To solve the issues above, KubeSphere provides a multi-tenant management solution based on Kubernetes.
![multi-tenancy-architecture](/images/docs/access-control-and-account-management/multi-tanancy-in-kubesphere/multi-tenancy-architecture.png)
In KubeSphere, the [workspace](../../workspace-administration/what-is-workspace/) is the smallest tenant unit. A workspace enables users to share resources across clusters and projects. Workspace members can create projects in an authorized cluster and invite other members to cooperate in the same project.
A **user** is the instance of a KubeSphere account. Users can be appointed as platform administrators to manage clusters or added to workspaces to cooperate in projects.
Multi-level access control and resource quota limits underlie resource isolation in KubeSphere. They decide how the multi-tenant architecture is built and administered.
### Logical isolation
Similar to Kubernetes, KubeSphere uses RBAC to manage permissions granted to users, thus logically implementing resource isolation.
![rbac](/images/docs/access-control-and-account-management/multi-tanancy-in-kubesphere/rbac.png)
The access control in KubeSphere is divided into three levels: platform, workspace and project. You use roles to control what permissions users have at different levels for different resources.
1. [Platform roles](/docs/quick-start/create-workspace-and-project): Control what permissions platform users have for platform resources, such as clusters, workspaces and platform members.
2. [Workspace roles](/docs/workspace-administration/role-and-member-management): Control what permissions workspace members have for workspace resources, such as projects (i.e. namespaces) and DevOps projects.
3. [Project roles](/docs/project-administration/role-and-member-management): Control what permissions project members have for project resources, such as workloads and pipelines.
### Network isolation
Apart from logically isolating resources, KubeSphere also allows you to set [network isolation policies](../../pluggable-components/network-policy/) for workspaces and projects.
### Auditing
KubeSphere also provides [auditing logs](../../pluggable-components/auditing-logs/) for users.
### Authentication and authorization
For a complete authentication and authorization chain in KubeSphere, see the following diagram. KubeSphere has expanded RBAC rules using the Open Policy Agent (OPA). The KubeSphere team looks to integrate [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) to provide more security management policies.
![request-chain](/images/docs/access-control-and-account-management/multi-tanancy-in-kubesphere/request-chain.jpg)

View File

@ -1,63 +1,60 @@
---
title: "KubeSphere中的多租户"
keywords: "kubernetes, kubesphere, multi-tenancy"
description: "Multi-tenancy in KubeSphere"
linkTitle: "KubeSphere中的多租户"
title: "KubeSphere 中的多租户"
keywords: "Kubernetes, KubeSphere, 多租户"
description: "理解 KubeSphere 中的多租户"
linkTitle: "KubeSphere 中的多租户"
weight: 12100
---
K8s 解决了应用编排、容器调度的难题,极大的提高了资源的利用率。有别与传统的集群运维方式,在使用 K8s 的过程中,我们将在资源共享和安全性方面面临诸多挑战。
Kubernetes 解决了应用编排、容器调度的难题,极大地提高了资源的利用率。有别于传统的集群运维方式,在使用 Kubernetes 的过程中,企业和个人用户在资源共享和安全性方面均面临着诸多挑战。
首当其冲的就是企业环境中多租户形态该如何定义租户的安全边界该如何划分。K8s 社区[关于多租户的讨论](https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY)从未停歇,但到目前为止最终的形态尚无定论。
首当其冲的就是企业环境中多租户形态该如何定义租户的安全边界该如何划分。Kubernetes 社区[关于多租户的讨论](https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY)从未停歇,但到目前为止最终的形态尚无定论。
## K8s 多租户面临的挑战
## Kubernetes 多租户面临的挑战
多租户是一种常见的软件架构,简单概括就是在多用户环境下实现资源共享,并保证各用户间数据的隔离性。在多租户集群环境中,我们需要最大程度的避免恶意租户对其他租户的攻击,公平地分配集群资源。
多租户是一种常见的软件架构,简单概括就是在多用户环境下实现资源共享,并保证各用户间数据的隔离性。在多租户集群环境中,集群管理员需要最大程度地避免恶意租户对其他租户的攻击,公平地分配集群资源。
无论企业的多租户形态如何,多租户都无法避免以下两个层面的问题:逻辑层面的资源隔离;物理资源的隔离。
逻辑层面的资源隔离主要包括API的访问控制针对用户的权限控制。K8s 中 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 和 namespace 提供了基本的逻辑隔离能力,这在大部分企业环境中并不适用。企业中的租户往往需要跨多个 namespace 甚至是多个集群进行资源管理。除此之外,针对用户的行为审计、租户隔离的日志、事件查询也是不可或缺的能力。
逻辑层面的资源隔离主要包括 API 的访问控制针对用户的权限控制。Kubernetes 中的 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 和命名空间 (namespace) 提供了基本的逻辑隔离能力,但在大部分企业环境中并不适用。企业中的租户往往需要跨多个命名空间甚至是多个集群进行资源管理。除此之外,针对用户的行为审计、租户隔离的日志、事件查询也是不可或缺的能力。
物理资源的隔离主要包括节点、网络的隔离,当然也包括容器运行时安全。我们可以通过 NetworkPolicy 对网络进行划分,通过 PodSecurityPolicy 限制容器的行为Kata Containers 也提供了更安全的容器运行时。
物理资源的隔离主要包括节点、网络的隔离,当然也包括容器运行时安全。您可以通过 [NetworkPolicy](../../pluggable-components/network-policy/) 对网络进行划分,通过 PodSecurityPolicy 限制容器的行为,[Kata Containers](https://katacontainers.io/) 也提供了更安全的容器运行时。
## KubeSphere中的多租户
## KubeSphere 中的多租户
为了解决上述问题KubeSphere 提供了基于 K8s 的多租户管理方案。
为了解决上述问题KubeSphere 提供了基于 Kubernetes 的多租户管理方案。
![multi-tenancy-architecture.png](/images/docs/access-control-and-account-management/multi-tenancy-architecture.png)
![multi-tenancy-architecture](/images/docs/zh-cn/access-control-and-account-management/multi-tanancy-in-kubesphere/multi-tenancy-architecture.png)
首先我们来看看 KubeSphere 中对租户的定义,在 KubeSphere 中 `Workspace` 是最小的租户单元Workspace 提供了跨集群、跨 namespace 资源共享的能力。Workspace 中的成员可以在授权集群中创建项目,并通过邀请授权的方式参与项目协同。
在 KubeSphere 中[企业空间](../../workspace-administration/what-is-workspace/)是最小的租户单元,企业空间提供了跨集群、跨项目(即 Kubernetes 中的命名空间)共享资源的能力。企业空间中的成员可以在授权集群中创建项目,并通过邀请授权的方式参与项目协同。
**用户**是 KubeSphere 的账户实例,可以被设置为平台层面的管理员参与集群的管理,也可以被添加到 Workspace 中参与项目协同。
**用户**是 KubeSphere 的帐户实例,可以被设置为平台层面的管理员参与集群的管理,也可以被添加到企业空间中参与项目协同。
多级的权限控制和资源配额限制是 KubeSphere 中资源隔离的基础,奠定了多租户最基本的形态。
### 逻辑隔离
与 K8s 一致 KubeSphere 通过 RBAC 对用户的权限加以控制,实现逻辑层面的资源隔离。
与 Kubernetes 相同,KubeSphere 通过 RBAC 对用户的权限加以控制,实现逻辑层面的资源隔离。
![rbac.png](/images/docs/access-control-and-account-management/rbac.png)
![rbac](/images/docs/zh-cn/access-control-and-account-management/multi-tanancy-in-kubesphere/rbac.png)
KubeSphere 中的权限控制分为平台、企业空间、项目三个层级,通过角色来控制用户在不同层级的资源访问权限。
1. [平台角色](/docs/quick-start/create-workspace-and-project):主要控制用户对平台资源的访问权限,如集群的管理、企业空间的管理、平台用户的管理等等.
2. [企业空间角色](/docs/workspace-administration/role-and-member-management)主要控制企业空间成员在企业空间下的资源访问权限如企业空间下namespace、DevOps Project的管理等等。
3. [项目角色](/docs/project-administration/role-and-member-management):主要控制项目下资源的访问权限,如工作负载的管理、流水线的管理等等。
1. [平台角色](../../quick-start/create-workspace-and-project):主要控制用户对平台资源的访问权限,如集群的管理、企业空间的管理、平台用户的管理等。
2. [企业空间角色](../../workspace-administration/role-and-member-management)主要控制企业空间成员在企业空间下的资源访问权限如企业空间下项目、DevOps 工程的管理等。
3. [项目角色](../../project-administration/role-and-member-management):主要控制项目下资源的访问权限,如工作负载的管理、流水线的管理等。
### 网络隔离
除了逻辑层面的资源隔离KubeSphere 中还可以可以针对企业空间、项目设置[网络隔离策略](/docs/pluggable-components/network-policy/)。
除了逻辑层面的资源隔离KubeSphere 中还可以针对企业空间和项目设置[网络隔离策略](../../pluggable-components/network-policy/)。
### 操作审计
KubeSphere 还提供了针对用户的的[操作审计](/docs/pluggable-components/auditing-logs/)。
KubeSphere 还提供了针对用户的[操作审计](../../pluggable-components/auditing-logs/)。
### 更多
### 认证鉴权
KubeSphere 完整的认证鉴权链路如下图所示,可以通过 OPA 拓展 K8s 的 RBAC 规则。我们计划集成 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 以支持更为丰富的安全管控策略。
KubeSphere 完整的认证鉴权链路如下图所示,可以通过 OPA 拓展 Kubernetes 的 RBAC 规则。KubeSphere 团队计划集成 [Gatekeeper](https://github.com/open-policy-agent/gatekeeper) 以支持更为丰富的安全管控策略。
![request-chain.png](/images/docs/access-control-and-account-management/request-chain.jpg)
![request-chain](/images/docs/zh-cn/access-control-and-account-management/multi-tanancy-in-kubesphere/request-chain.jpg)

Binary file not shown.

After

Width:  |  Height:  |  Size: 265 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 194 KiB