Fix: add procedure image & fix bugs in doc
Signed-off-by: Yin Da <yd219913@alibaba-inc.com>
This commit is contained in:
Yin Da
parent
49ee620d08
commit
93b75adde7
|
|
@ -39,6 +39,10 @@ c3 X509Certificate <c3 apiserver url> true
|
|||
c2 X509Certificate <c2 apiserver url> true
|
||||
```
|
||||
|
||||
The following procedures are illustrated in the following figure. The operations below are associated with different users, which are identified by switching `KUBECONFIG` environment variable. (Each `KUBECONFIG` corresponds to one user.)
|
||||
|
||||
|
||||
|
||||
### Create User
|
||||
|
||||
1. Let's start with a new coming user named Alice. As the system administrator, you can assign a KubeConfig for Alice to use.
|
||||
|
|
@ -54,10 +58,12 @@ Signed certificate retrieved.
|
|||
|
||||
### Grant Privileges
|
||||
|
||||
2. Now alice is unabled to do anything in the cluster with the given KubeConfig. We can grant her the privileges of Read/Write resources in the `dev` namespace of the control plane and managed cluster `c2`.
|
||||
2. Now alice is unable to do anything in the cluster with the given KubeConfig. We can grant her the privileges of Read/Write resources in the `dev` namespace of the control plane and managed cluster `c2`.
|
||||
|
||||
```bash
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=c2 --create-namespace
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=local,c2 --create-namespace
|
||||
ClusterRole kubevela:writer created in local.
|
||||
RoleBinding dev/kubevela:writer:binding created in local.
|
||||
ClusterRole kubevela:writer created in c2.
|
||||
RoleBinding dev/kubevela:writer:binding created in c2.
|
||||
Privileges granted.
|
||||
|
|
@ -69,7 +75,15 @@ Privileges granted.
|
|||
$ vela auth list-privileges --user alice --cluster local,c2
|
||||
User=alice
|
||||
├── [Cluster] local
|
||||
│ └── no privilege found
|
||||
│ └── [ClusterRole] kubevela:writer
|
||||
│ ├── [Scope]
|
||||
│ │ └── [Namespaced] dev (RoleBinding kubevela:writer:binding)
|
||||
│ └── [PolicyRules]
|
||||
│ ├── APIGroups: *
|
||||
│ │ Resources: *
|
||||
│ │ Verb: get, list, watch, create, update, patch, delete
|
||||
│ └── NonResourceURLs: *
|
||||
│ Verb: get, list, watch, create, update, patch, delete
|
||||
└── [Cluster] c2
|
||||
└── [ClusterRole] kubevela:writer
|
||||
├── [Scope]
|
||||
|
|
@ -82,8 +96,6 @@ User=alice
|
|||
Verb: get, list, watch, create, update, patch, delete
|
||||
```
|
||||
|
||||
Alice don't have any privilege in local cluster while she have read/write capability in namespace(dev) of cluster(c2).
|
||||
|
||||
### Use Privileges
|
||||
|
||||
4. Alice can create an application in the dev namespace now. The application can also dispatch resources into the dev namespace of cluster `c2`.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
|
|
@ -41,6 +41,10 @@ c3 X509Certificate <c3 apiserver url> true
|
|||
c2 X509Certificate <c2 apiserver url> true
|
||||
```
|
||||
|
||||
下图概括了下述的流程。在下文的介绍中，相关命令将会通过使用 `KUBECONFIG` 环境变量来切换身份，代表不同身份（用户）的操作。（不同的 `KUBECONFIG` 代表不同的用户身份。）
|
||||
|
||||
|
||||
|
||||
### 创建用户组（用户）
|
||||
|
||||
```
|
||||
|
|
@ -58,13 +62,15 @@ Signed certificate retrieved.
|
|||
### 对用户组授权
|
||||
|
||||
```
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=c2 --create-namespace
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=local,c2 --create-namespace
|
||||
ClusterRole kubevela:writer created in local.
|
||||
RoleBinding dev/kubevela:writer:binding created in local.
|
||||
ClusterRole kubevela:writer created in c2.
|
||||
RoleBinding dev/kubevela:writer:binding created in c2.
|
||||
Privileges granted.
|
||||
```
|
||||
|
||||
这里采用了 KubeVela 简化的权限能力，对 c2 集群授权了 `dev` 命名空间的“读/写”权限，同时还可以方便的创建命名空间。授权命令可以多次执行，用于增加权限。
|
||||
这里采用了 KubeVela 简化的权限能力，对 local 和 c2 集群授权了 `dev` 命名空间的“读/写”权限，同时还可以方便的创建命名空间。授权命令可以多次执行，用于增加权限。
|
||||
|
||||
|
||||
### 查看用户组权限
|
||||
|
|
@ -73,7 +79,15 @@ Privileges granted.
|
|||
$ vela auth list-privileges --user alice --cluster local,c2
|
||||
User=alice
|
||||
├── [Cluster] local
|
||||
│ └── no privilege found
|
||||
│ └── [ClusterRole] kubevela:writer
|
||||
│ ├── [Scope]
|
||||
│ │ └── [Namespaced] dev (RoleBinding kubevela:writer:binding)
|
||||
│ └── [PolicyRules]
|
||||
│ ├── APIGroups: *
|
||||
│ │ Resources: *
|
||||
│ │ Verb: get, list, watch, create, update, patch, delete
|
||||
│ └── NonResourceURLs: *
|
||||
│ Verb: get, list, watch, create, update, patch, delete
|
||||
└── [Cluster] c2
|
||||
└── [ClusterRole] kubevela:writer
|
||||
├── [Scope]
|
||||
|
|
@ -86,7 +100,7 @@ User=alice
|
|||
Verb: get, list, watch, create, update, patch, delete
|
||||
```
|
||||
|
||||
你可以一目了然的看到这个用户组在不同集群中的权限，在 local 集群中无权限。
|
||||
你可以一目了然的看到这个用户组在不同集群中的权限。
|
||||
|
||||
|
||||
### 使用权限
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
|
|
@ -41,6 +41,10 @@ c3 X509Certificate <c3 apiserver url> true
|
|||
c2 X509Certificate <c2 apiserver url> true
|
||||
```
|
||||
|
||||
下图概括了下述的流程。在下文的介绍中，相关命令将会通过使用 `KUBECONFIG` 环境变量来切换身份，代表不同身份（用户）的操作。（不同的 `KUBECONFIG` 代表不同的用户身份。）
|
||||
|
||||
|
||||
|
||||
### 创建用户组（用户）
|
||||
|
||||
```
|
||||
|
|
@ -58,13 +62,15 @@ Signed certificate retrieved.
|
|||
### 对用户组授权
|
||||
|
||||
```
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=c2 --create-namespace
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=local,c2 --create-namespace
|
||||
ClusterRole kubevela:writer created in local.
|
||||
RoleBinding dev/kubevela:writer:binding created in local.
|
||||
ClusterRole kubevela:writer created in c2.
|
||||
RoleBinding dev/kubevela:writer:binding created in c2.
|
||||
Privileges granted.
|
||||
```
|
||||
|
||||
这里采用了 KubeVela 简化的权限能力，对 c2 集群授权了 `dev` 命名空间的“读/写”权限，同时还可以方便的创建命名空间。授权命令可以多次执行，用于增加权限。
|
||||
这里采用了 KubeVela 简化的权限能力，对 local 和 c2 集群授权了 `dev` 命名空间的“读/写”权限，同时还可以方便的创建命名空间。授权命令可以多次执行，用于增加权限。
|
||||
|
||||
|
||||
### 查看用户组权限
|
||||
|
|
@ -73,7 +79,15 @@ Privileges granted.
|
|||
$ vela auth list-privileges --user alice --cluster local,c2
|
||||
User=alice
|
||||
├── [Cluster] local
|
||||
│ └── no privilege found
|
||||
│ └── [ClusterRole] kubevela:writer
|
||||
│ ├── [Scope]
|
||||
│ │ └── [Namespaced] dev (RoleBinding kubevela:writer:binding)
|
||||
│ └── [PolicyRules]
|
||||
│ ├── APIGroups: *
|
||||
│ │ Resources: *
|
||||
│ │ Verb: get, list, watch, create, update, patch, delete
|
||||
│ └── NonResourceURLs: *
|
||||
│ Verb: get, list, watch, create, update, patch, delete
|
||||
└── [Cluster] c2
|
||||
└── [ClusterRole] kubevela:writer
|
||||
├── [Scope]
|
||||
|
|
@ -86,7 +100,7 @@ User=alice
|
|||
Verb: get, list, watch, create, update, patch, delete
|
||||
```
|
||||
|
||||
你可以一目了然的看到这个用户组在不同集群中的权限，在 local 集群中无权限。
|
||||
你可以一目了然的看到这个用户组在不同集群中的权限。
|
||||
|
||||
|
||||
### 使用权限
|
||||
|
|
|
|||
|
|
@ -1,20 +1,21 @@
|
|||
---
|
||||
title: 系统集成
|
||||
title: Systems Integration
|
||||
---
|
||||
|
||||
即使没有启用[权限验证](./basic)功能，KubeVela 应用程序本身也支持 Kubernetes 角色扮演。这意味着当权限验证功能被禁用时，你可以在应用程序的注释字段中手动设置要扮演的身份。例如，以下指南将举例说明如何手动将应用程序角色扮演为指定账号 ServiceAccount。
|
||||
## 例子
|
||||
KubeVela application natively supports impersonation even without the Authentication flag enabled. That means when the Authentication flag is disabled, you can manually set the identity to impersonate in the application's annotation fields. For example, the following guide will give an example on how to manually set the application to impersonate as a ServiceAccount.
|
||||
|
||||
假设我们有两个命名空间:
|
||||
## Example
|
||||
|
||||
- `demo-service`: 用于管理应用程序
|
||||
- `demo-service-prod`: 为生产环境部署组件
|
||||
Let's assume that we have two namespaces:
|
||||
|
||||
在这个例子, 我们将使应用程序使用特定的 ServiceAccount，而不是控制器 ServiceAccount。
|
||||
- `demo-service`: for managing application
|
||||
- `demo-service-prod`: to deploy components for the production environment
|
||||
|
||||
### 创建 ServiceAccount
|
||||
In this example, we will make the Application use a specific ServiceAccount instead of the controller ServiceAccount.
|
||||
|
||||
在 `demo-service` 命名空间里，创建 `deployer` ServiceAccount .
|
||||
### Creating ServiceAccount
|
||||
|
||||
Create `deployer` ServiceAccount in `demo-service` namespace.
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -24,11 +25,11 @@ metadata:
|
|||
namespace: demo-service
|
||||
```
|
||||
|
||||
### 创建 Role/RoleBinding
|
||||
### Creating Role/RoleBinding
|
||||
|
||||
允许在 `demo-service` 里的类型为ServiceAccount的`deployer` 通过创建 Role/RoleBinding 管理在 `demo-service-prod` 里的部署
|
||||
Allow `deployer` ServiceAccount in `demo-service` to manage Deployments in `demo-service-prod` by creating Role/RoleBinding.
|
||||
|
||||
> 注意 KubeVela 应用程序需要模拟身份才能具有写入ControllerRevision的权限。如果在KubeVela控制器中使用`--optimize-disable-component-revision` ，则可以忽略此要求。
|
||||
> Notice that KubeVela application requires the identity to impersonate to have the privileges for writing ControllerRevision. If you use `--optimize-disable-component-revision` in the KubeVela controller, you can ignore this requirement.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
|
|
@ -56,7 +57,7 @@ subjects:
|
|||
namespace: demo-service
|
||||
```
|
||||
|
||||
### 使用ServiceAccount部署应用程序
|
||||
### Deploying an Application with ServiceAccount
|
||||
|
||||
```yaml
|
||||
apiVersion: core.oam.dev/v1beta1
|
||||
|
|
@ -99,7 +100,7 @@ spec:
|
|||
env: prod
|
||||
```
|
||||
|
||||
部署应用程序后，您可以检查应用程序是否已成功部署。
|
||||
After deploying the Application, you can check the Application is deployed successfully.
|
||||
|
||||
```bash
|
||||
$ vela status multi-env-demo-with-service-account -n demo-service
|
||||
|
|
@ -132,12 +133,12 @@ Services:
|
|||
No trait applied
|
||||
```
|
||||
|
||||
如果你将非授权的ServiceAccount设置为标注 , 则可以在应用程序状态中找到如下错误消息。
|
||||
If you set non-authorized ServiceAccount to the annotation, you can find an error message like below in the Application status.
|
||||
|
||||
```
|
||||
Dispatch: Found 1 errors. [(cannot get object: deployments.apps "nginx-server" is forbidden: User "system:serviceaccount:demo-service:non-authorized-account" cannot get resource "deployments" in API group "apps" in the namespace "demo-service-prod")]
|
||||
```
|
||||
|
||||
## 模拟为 User/Groups
|
||||
## Impersonate as User/Groups
|
||||
|
||||
如果您想让应用程序模拟为特定的用户和组，您可以分别在应用程序中设置注释为`app.oam.dev/username` and `app.oam.dev/group`。
|
||||
If you would like to let the application to impersonate as specific user and group, you can set the annotation `app.oam.dev/username` and `app.oam.dev/group` in the application respectively.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
|
|
@ -39,6 +39,10 @@ c3 X509Certificate <c3 apiserver url> true
|
|||
c2 X509Certificate <c2 apiserver url> true
|
||||
```
|
||||
|
||||
The following procedures are illustrated in the following figure. The operations below are associated with different users, which are identified by switching `KUBECONFIG` environment variable. (Each `KUBECONFIG` corresponds to one user.)
|
||||
|
||||
|
||||
|
||||
### Create User
|
||||
|
||||
1. Let's start with a new coming user named Alice. As the system administrator, you can assign a KubeConfig for Alice to use.
|
||||
|
|
@ -54,10 +58,12 @@ Signed certificate retrieved.
|
|||
|
||||
### Grant Privileges
|
||||
|
||||
2. Now alice is unabled to do anything in the cluster with the given KubeConfig. We can grant her the privileges of Read/Write resources in the `dev` namespace of the control plane and managed cluster `c2`.
|
||||
2. Now alice is unable to do anything in the cluster with the given KubeConfig. We can grant her the privileges of Read/Write resources in the `dev` namespace of the control plane and managed cluster `c2`.
|
||||
|
||||
```bash
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=c2 --create-namespace
|
||||
$ vela auth grant-privileges --user alice --for-namespace dev --for-cluster=local,c2 --create-namespace
|
||||
ClusterRole kubevela:writer created in local.
|
||||
RoleBinding dev/kubevela:writer:binding created in local.
|
||||
ClusterRole kubevela:writer created in c2.
|
||||
RoleBinding dev/kubevela:writer:binding created in c2.
|
||||
Privileges granted.
|
||||
|
|
@ -69,7 +75,15 @@ Privileges granted.
|
|||
$ vela auth list-privileges --user alice --cluster local,c2
|
||||
User=alice
|
||||
├── [Cluster] local
|
||||
│ └── no privilege found
|
||||
│ └── [ClusterRole] kubevela:writer
|
||||
│ ├── [Scope]
|
||||
│ │ └── [Namespaced] dev (RoleBinding kubevela:writer:binding)
|
||||
│ └── [PolicyRules]
|
||||
│ ├── APIGroups: *
|
||||
│ │ Resources: *
|
||||
│ │ Verb: get, list, watch, create, update, patch, delete
|
||||
│ └── NonResourceURLs: *
|
||||
│ Verb: get, list, watch, create, update, patch, delete
|
||||
└── [Cluster] c2
|
||||
└── [ClusterRole] kubevela:writer
|
||||
├── [Scope]
|
||||
|
|
@ -82,8 +96,6 @@ User=alice
|
|||
Verb: get, list, watch, create, update, patch, delete
|
||||
```
|
||||
|
||||
Alice don't have any privilege in local cluster while she have read/write capability in namespace(dev) of cluster(c2).
|
||||
|
||||
### Use Privileges
|
||||
|
||||
4. Alice can create an application in the dev namespace now. The application can also dispatch resources into the dev namespace of cluster `c2`.
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ There are three approaches to denote one or a group of workload types.
|
|||
|
||||
If this field is omitted, it means this trait is allowed to apply to any workload types.
|
||||
|
||||
KubeVela will raise an error if a trait is applied to a workload type which is NOT included in the `appliesToWorkloads`.
|
||||
For now, this field is not checked when applying application. Strict checking is planed to be implemented in the KubeVela 1.6.
|
||||
|
||||
|
||||
### `.spec.conflictsWith`
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 301 KiB |
Loading…
Reference in New Issue