kubevela
/
kubevela.github.io
mirror of https://github.com/kubevela/kubevela.github.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Docs: update the SSO document 

Signed-off-by: barnettZQG <barnett.zqg@gmail.com>
This commit is contained in:
barnettZQG 2022-08-11 17:19:17 +08:00
parent 6a9da7e341
commit cf397ead13
12 changed files with 110 additions and 94 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
docs/tutorials/sso.md
View File

@ -6,19 +6,19 @@ title: SSO Login
In KubeVela V1.3, we provide two methods to login: local login and SSO.
Local login uses the username and password stored in the local database to log in, and SSO integrates [Dex](https://dexidp.io/), which can be configured by configuring Dex's [OpenID Connect](https://dexidp.io/docs/openid-connect) to implement many different ways to log in, such as: GitHub, LDAP, etc.
Local login uses the username and password stored in the local database to log in, and SSO integrates [Dex](https://dexidp.io/), which can be configured by configuring Dex's [OpenID Connect](https://dexidp.io/docs/openid-connect) to implement many different ways to log in, such as GitHub, LDAP, Gitlab, Oidc, Saml, Google etc.
After the platform is initialized, local login is used by default. Platform administrators can configure SSO through the platform configuration page. In this tutorial, we'll use the GitHub and LDAP Connector to show how to use SSO with KubeVela.
After the platform is initialized, local login is used by default. Platform administrators can configure SSO through the platform configuration page. In this tutorial, we'll use GitHub and LDAP Connector to show how to use SSO with KubeVela.
## Enable Dex Addon
You need to enable the Dex Addon in the Addon list first to use SSO:
1. You need to enable the Dex Addon in the Addon list first to use SSO:
![alt](https://static.kubevela.net/images/1.3/dex-addon.png)
After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option:
2. After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option:
![alt](https://static.kubevela.net/images/1.3/upgrade-velaux.png)
![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png)
## Configure Dex Connectors
@ -51,13 +51,17 @@ If your LDAP does not provide anonymous authentication access, then you need to
## Platform setting
Users who login in through SSO will be automatically bound to the users who have the same email in the local database, otherwise a new user will be created.
Users who log in through SSO will be automatically bound to the users who have the same email in the local database, otherwise, a new user will be created.
Since the newly logged in user does not have any permissions, we need to set an email address for the platform administrator first. After that, when you use a user with the same email address for SSO login, you can automatically have platform administrator privileges.
Since the newly logged-in user does not have any permissions, we need to set an email address for the platform administrator first. After that, when you use a user with the same email address for SSO login, you can automatically have platform administrator privileges.
After configuring the user email, we can change the login method to SSO login in the platform configuration page.
> The admin user also could log in from the dex with the email and password.
![alt](https://static.kubevela.net/images/1.3/platform-setting.png)
After configuring the user email, we can change the login method to SSO login on the platform configuration page. Before updating the configuration, it is strongly recommended to click `Click me to test open the dex page` to verify that the dex connector configuration is ready.
![alt](https://static.kubevela.net/images/1.5/platform-setting.jpg)
On this page, you could set the default project and roles for the users who log in through SSO.
## Use SSO Login
@ -65,8 +69,8 @@ Log out and refresh the page again, you can see that we have entered the Dex log
![alt](https://static.kubevela.net/images/1.3/dex-login.png)
Then, you select GitHub or LDAP to login.
Then, you select GitHub or LDAP to log in.
![alt](https://static.kubevela.net/images/1.3/dex-grant-access.png)
So far, we have successfully completed SSO login with GitHub. At this point, if the email of the logged in user can be associated with the email of the previously logged in user, the newly logged in user will inherit the permissions of the previous user.
So far, we have completed SSO login with GitHub. At this point, if the email of the log-in user can be associated with the email of the previously log-in user, the newly log-in user will inherit the permissions of the previous user.

16
i18n/zh/docusaurus-plugin-content-docs/current/tutorials/sso.md
View File

@ -4,11 +4,11 @@ title: 单点登录
## 简介
在 KubeVela 1.3 版本中，默认提供了两种方式：本地登录以及单点登录。
在 KubeVela 1.3 及以后的版本中，默认提供了两种方式：本地登录以及单点登录。
本地登录使用本地数据库中存储的用户名密码进行登录，而单点登录集成了 [Dex](https://dexidp.io/)，可以通过配置 Dex 的 [OpenID Connect](https://dexidp.io/docs/openid-connect) 来实现多种不同方式的登录，如：GitHub、LDAP 等等。
本地登录使用本地数据库中存储的用户名密码进行登录，而单点登录集成了 [Dex](https://dexidp.io/)，可以通过配置 Dex 的 [OpenID Connect](https://dexidp.io/docs/openid-connect) 来实现多种不同方式的登录，如：GitHub, LDAP, Gitlab, Oidc, Saml, Google 等等。
平台初始化后，默认使用本地登录。平台管理员可以通过平台配置页面，配置单点登录。在本教程中，我们将分别使用 GitHub 和 LDAP Connector 来演示单点登录。
平台初始化后，默认使用本地登录。平台管理员可以通过平台配置页面，配置单点登录。在本教程中，本文我们将分别使用 GitHub 和 LDAP Connector 来演示单点登录。其他类型只有配置参数的差异，启动流程一致。
## 开启 Dex 插件
@ -18,7 +18,7 @@ title: 单点登录
开启完毕后，我们还需要更新一下 VelaUX 插件，打开其 Dex 选项。同样，我们在插件列表中找到 VelaUX，进行更新：
![alt](https://static.kubevela.net/images/1.3/upgrade-velaux.png)
![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png)
## 配置 Dex Connectors
@ -56,9 +56,13 @@ title: 单点登录
由于新登入的用户没有任何权限，因此，我们需要先为平台管理员设置一个邮箱地址。之后，再使用拥有相同邮箱地址的用户进行单点登录时，便能自动拥有平台管理员的权限。
配置完用户邮箱后，我们可以在平台配置页面中，将登录方式修改为 SSO 登录。
配置完用户邮箱后，我们可以在平台配置页面中，将登录方式修改为 SSO 登录。在提交之前强烈建议先点击策略链接跳转到 Dex 登录页面进行登录测试。
![alt](https://static.kubevela.net/images/1.3/platform-setting.png)
> 请注意，admin 用户可以通过 Dex 的邮箱登录途径进行登录，使用你配置的邮箱和密码即可。
![alt](https://static.kubevela.net/images/1.5/platform-setting.jpg)
在该页面中，你还可以未单点登录的用户配置初始化权限，设置默认加入的项目和角色。如果不设置，初次登录的用户将无任何权限。
### 使用单点登录

16
i18n/zh/docusaurus-plugin-content-docs/version-v1.5/tutorials/sso.md
View File

@ -4,11 +4,11 @@ title: 单点登录
## 简介
在 KubeVela 1.3 版本中，默认提供了两种方式：本地登录以及单点登录。
在 KubeVela 1.3 及以后的版本中，默认提供了两种方式：本地登录以及单点登录。
本地登录使用本地数据库中存储的用户名密码进行登录，而单点登录集成了 [Dex](https://dexidp.io/)，可以通过配置 Dex 的 [OpenID Connect](https://dexidp.io/docs/openid-connect) 来实现多种不同方式的登录，如：GitHub、LDAP 等等。
本地登录使用本地数据库中存储的用户名密码进行登录，而单点登录集成了 [Dex](https://dexidp.io/)，可以通过配置 Dex 的 [OpenID Connect](https://dexidp.io/docs/openid-connect) 来实现多种不同方式的登录，如：GitHub, LDAP, Gitlab, Oidc, Saml, Google 等等。
平台初始化后，默认使用本地登录。平台管理员可以通过平台配置页面，配置单点登录。在本教程中，我们将分别使用 GitHub 和 LDAP Connector 来演示单点登录。
平台初始化后，默认使用本地登录。平台管理员可以通过平台配置页面，配置单点登录。在本教程中，本文我们将分别使用 GitHub 和 LDAP Connector 来演示单点登录。其他类型只有配置参数的差异，启动流程一致。
## 开启 Dex 插件
@ -18,7 +18,7 @@ title: 单点登录
开启完毕后，我们还需要更新一下 VelaUX 插件，打开其 Dex 选项。同样，我们在插件列表中找到 VelaUX，进行更新：
![alt](https://static.kubevela.net/images/1.3/upgrade-velaux.png)
![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png)
## 配置 Dex Connectors
@ -56,9 +56,13 @@ title: 单点登录
由于新登入的用户没有任何权限，因此，我们需要先为平台管理员设置一个邮箱地址。之后，再使用拥有相同邮箱地址的用户进行单点登录时，便能自动拥有平台管理员的权限。
配置完用户邮箱后，我们可以在平台配置页面中，将登录方式修改为 SSO 登录。
配置完用户邮箱后，我们可以在平台配置页面中，将登录方式修改为 SSO 登录。在提交之前强烈建议先点击策略链接跳转到 Dex 登录页面进行登录测试。
![alt](https://static.kubevela.net/images/1.3/platform-setting.png)
> 请注意，admin 用户可以通过 Dex 的邮箱登录途径进行登录，使用你配置的邮箱和密码即可。
![alt](https://static.kubevela.net/images/1.5/platform-setting.jpg)
在该页面中，你还可以未单点登录的用户配置初始化权限，设置默认加入的项目和角色。如果不设置，初次登录的用户将无任何权限。
### 使用单点登录

14
versioned_docs/version-v1.5/platform-engineers/components/custom-component.md
View File

@ -35,8 +35,8 @@ vela def init stateless -t component --template-yaml ./stateless.yaml -o statele
It generates a file:
```shell
$ cat stateless.cue
```cue
// $ cat stateless.cue
stateless: {
annotations: {}
attributes: workload: definition: {
@ -76,7 +76,7 @@ In detail:
Add parameters in this auto-generated custom component file :
```
```cue
stateless: {
annotations: {}
attributes: workload: definition: {
@ -126,8 +126,8 @@ vela def init task -t component -o task.cue
It generates a file:
```shell
$ cat task.cue
```cue
// $ cat task.cue
task: {
annotations: {}
attributes: workload: definition: {
@ -147,7 +147,7 @@ template: {
Edit the generated component file:
```
```cue
task: {
annotations: {}
attributes: workload: definition: {
@ -324,7 +324,7 @@ outputs: <unique-name>:
Below is the example for `webserver` definition:
```
```cue
webserver: {
annotations: {}
attributes: workload: definition: {

54
versioned_docs/version-v1.5/platform-engineers/cue/basic.md
View File

@ -28,7 +28,7 @@ Please make sure below CLIs are present in your environment:
Below is the basic CUE data, you can define both schema and value in the same file with the almost same format:
```
```cue
a: 1.5
a: float
b: 1
@ -68,7 +68,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
```shell
cue eval first.cue
```
```console
```cue
a: 1.5
b: 1
d: [1, 2, 3]
@ -102,7 +102,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
```shell
cue export first.cue
```
```console
```json
{
"a": 1.5,
"b": 1,
@ -122,7 +122,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
```shell
cue export first.cue --out yaml
```
```console
```yaml
a: 1.5
b: 1
d:
@ -138,7 +138,7 @@ CUE has powerful CLI commands. Let's keep the data in a file named `first.cue` a
```shell
cue export -e g first.cue
```
```console
```cue
{
"h": "abc"
}
@ -150,7 +150,7 @@ For now, you have learned all useful CUE cli operations.
* Data structure: Below is the basic data structure of CUE.
```shell
```cue
// float
a: 1.5
@ -191,13 +191,13 @@ Let's name it `second.cue`. Then the `cue export` won't complain as the `#abc` i
```shell
cue export second.cue
```
```console
```json
{}
```
You can also define a more complex custom struct, such as:
```
```cue
#abc: {
x: int
y: string
@ -216,7 +216,7 @@ Let's try to define a CUE template with the knowledge just learned.
1. Define a struct variable `parameter`.
```shell
```cue
parameter: {
name: string
image: string
@ -227,7 +227,7 @@ Let's save it in a file called `deployment.cue`.
2. Define a more complex struct variable `template` and reference the variable `parameter`.
```
```cue
template: {
apiVersion: "apps/v1"
kind: "Deployment"
@ -255,7 +255,7 @@ Add it into the `deployment.cue`.
3. Then, let's add the value by adding following code block:
```
```cue
parameter:{
name: "mytest"
image: "nginx:v1"
@ -267,7 +267,7 @@ parameter:{
```shell
cue export deployment.cue -e template --out yaml
```
```console
```yaml
apiVersion: apps/v1
kind: Deployment
spec:
@ -291,7 +291,7 @@ spec:
- A list like `[...string]` means it can hold multiple string elements.
If we don't add `...`, then `[string]` means the list can only have one `string` element in it.
- A struct like below means the struct can contain unknown fields.
```
```cue
{
abc: string
...
@ -299,19 +299,19 @@ spec:
```
* Operator `|`, it represents a value could be both case. Below is an example that the variable `a` could be in string or int type.
```shell
```cue
a: string | int
```
* Default Value, we can use `*` symbol to represent a default value for variable. That's usually used with `|`,
which represents a default value for some type. Below is an example that variable `a` is `int` and it's default value is `1`.
```shell
```cue
a: *1 | int
```
* Optional Variable. In some cases, a variable could not be used, they're optional variables, we can use `?:` to define it.
In the below example, `a` is an optional variable, `x` and `z` in `#my` is optional while `y` is a required variable.
```
```cue
a ?: int
#my: {
@ -323,7 +323,7 @@ spec:
Optional variables can be skipped, that usually works together with conditional logic.
Specifically, if some field does not exist, the CUE grammar is `if _variable_ != _|_`, the example is like below:
```
```cue
#Config: {
name: string
value: string
@ -351,7 +351,7 @@ Specifically, if some field does not exist, the CUE grammar is `if _variable_ !=
* Operator `&`, it used to calculate two variables.
```shell
```cue
a: *1 | int
b: 3
c: a & b
@ -364,7 +364,7 @@ You can evaluate the result by using `cue eval`:
```shell
cue eval third.cue
```
```console
```cue
a: 1
b: 3
c: 3
@ -373,7 +373,7 @@ c: 3
* Conditional statement, it's really useful when you have some cascade operations that different value affects different results.
So you can do `if..else` logic in the template.
```shell
```cue
price: number
feel: *"good" | string
// Feel bad if price is too high
@ -390,14 +390,14 @@ You can evaluate the result by using `cue eval`:
```shell
cue eval fourth.cue
```
```console
```cue
price: 200
feel: "bad"
```
Another example is to use bool type as parameter.
```
```cue
parameter: {
name: string
image: string
@ -443,7 +443,7 @@ output: {
}
```
- Loop for type
```
```cue
#a: {
"hello": "Barcelona"
"nihao": "Shanghai"
@ -481,7 +481,7 @@ output: {
}
```
- If clause in Loop {}
```
```cue
parameter: [
{
name: "empty"
@ -497,14 +497,14 @@ output: {
}]
```
the result is:
```
```console
cue eval ../blog/a.cue -e dataFrom
[{}, {
name: "xx1"
}]
```
- If clause in Loop with condition
```
```cue
parameter: [
{
name: "empty"
@ -518,7 +518,7 @@ output: {
}]
```
the result is:
```
```console
cue eval ../blog/a.cue -e dataFrom
[{
name: "xx1"

4
versioned_docs/version-v1.5/platform-engineers/cue/definition-edit.md
View File

@ -10,7 +10,7 @@ In KubeVela CLI, `vela def` command group provides a series of convenient defini
`vela def init` is a command that helps users bootstrap new definitions. To create an empty trait definition, run `vela def init my-trait -t trait --desc "My trait description."`
```json
```cue
"my-trait": {
annotations: {}
attributes: {
@ -83,7 +83,7 @@ spec:
Running `vela def init my-comp -t component --desc "My component." --template-yaml ./my-deployment.yaml` to get the CUE-format ComponentDefinition
```json
```cue
"my-comp": {
annotations: {}
attributes: workload: definition: {

14
versioned_docs/version-v1.5/platform-engineers/cue/patch-strategy.md
View File

@ -18,7 +18,7 @@ If you want to add multiple environment variables for a specific container, you
Apply the following definition to your cluster:
```yaml
```cue
myenv: {
type: "trait"
annotations: {}
@ -75,7 +75,7 @@ spec:
Before using the `myenv` patch trait, the `env` in the application is like:
```
```yaml
spec:
containers:
- env:
@ -85,7 +85,7 @@ spec:
After using the `myenv` patch trait, the `env` in the application is like:
```
```yaml
spec:
containers:
- env:
@ -105,7 +105,7 @@ The strategy of this annotation is similar to the Kubernetes official [retainKey
> In the following example, `+patchKey=name` specifies which container the patch should be applied to, while `+patchStrategy=retainKeys` specifies that when merge environment variables, if a duplicate environment variable name is specified, the environment variable value will be overwritten.
```yaml
```cue
myenv: {
type: "trait"
annotations: {}
@ -198,7 +198,7 @@ If you wish to replace the entire env array directly, you can use the `+patchStr
> In the following example, `+patchKey=name` specifies which container the patch should be applied to, while `+patchStrategy=replace` specifies that when merge the arrays, the entire array of environment variables will be replaced directly.
```yaml
```cue
myenv: {
type: "trait"
annotations: {}
@ -258,7 +258,7 @@ spec:
Before using the `myenv` patch trait, the `env` in the application is like:
```
```yaml
spec:
containers:
- env:
@ -270,7 +270,7 @@ spec:
After using the `myenv` patch trait, the `env` in the application is like:
```
```yaml
spec:
containers:
- env:

4
versioned_docs/version-v1.5/platform-engineers/policy/custom-policy.md
View File

@ -16,8 +16,8 @@ vela def init my-plc -t policy --desc "My ingress route policy." > myroute.cue
The content of the scaffold expected to be:
```
$ cat myroute.cue
```cue
// $ cat myroute.cue
"my-plc": {
annotations: {}
attributes: {}

20
versioned_docs/version-v1.5/platform-engineers/system-operation/velaql.md
View File

@ -18,7 +18,7 @@ KubeVela command has supported a `vela ql` command to query resources.
You can specify a query file in cue like below:
```ql.cue
```cue
import (
"vela/ql"
)
@ -102,7 +102,7 @@ vela kube apply -f query-configmap.yaml
Create a file named `my-view.cue` with:
```yaml
```cue
import (
"vela/ql"
)
@ -193,7 +193,7 @@ The current view in VelaQL relies on configMap in k8s as a storage medium, You c
Every time you use VelaQL, the system will look for the configMap with the same name as the view under the vela-system namespace, and extract the template for query operations, so please ensure that your custom view is stored under vela-system.
​
The structure of a template is as follows:
```
```cue
import (
"vela/ql"
)
@ -229,7 +229,7 @@ List all resources created by Application
- list: after the operation is successful, this field will be filled. `list` is a list of all resources, the k8s description of the resource is stored in the object field.
- err: if an error occurs in the operation, the error message will be displayed as a string.
```
```cue
#ListResourcesInApp: {
app: {
name: string
@ -252,7 +252,7 @@ List all resources created by Application
#### Usage
```
```cue
import (
"vela/ql"
)
@ -299,7 +299,7 @@ List all pods created by the workload
- list: after the operation is successful, this field will be filled. `list` is a list of all pod resources
- err: if an error occurs in the operation, the error message will be displayed as a string.
```
```cue
#CollectPods: {
value: {...}
cluster: string
@ -309,7 +309,7 @@ List all pods created by the workload
```
#### Usage
```
```cue
import (
"vela/ql"
)
@ -338,7 +338,7 @@ Get resource in Kubernetes cluster.
- value: the resource metadata to be get. And after successful execution, value will be updated with resource definition in cluster.
- err: if an error occurs, the err will contain the error message.
```
```cue
#Read: {
value: {}
err?: string
@ -347,7 +347,7 @@ Get resource in Kubernetes cluster.
### Usage
```
```cue
// You can use configmap.value.data after this action.
configmap: ql.#Read & {
value: {
@ -371,7 +371,7 @@ List resources in the k8s cluster.
- filter: namespace is used to select a namespace, and the matchingLabels field is used to filter labels
- err: if an error occurs, the err will contain the error message.
```
```cue
#List: {
cluster: *"" | string
resource: {

4
versioned_docs/version-v1.5/platform-engineers/traits/customize-trait.md
View File

@ -18,8 +18,8 @@ vela def init my-route -t trait --desc "My ingress route trait." > myroute.cue
The content of the scaffold expected to be:
```
$ cat myroute.cue
```cue
// $ cat myroute.cue
"my-route": {
annotations: {}
attributes: {

6
versioned_docs/version-v1.5/platform-engineers/workflow/workflow.md
View File

@ -41,8 +41,8 @@ vela def init my-helm -t workflow-step --desc "Apply helm charts and wait till i
```
The result is as follows：
```shell
$ cat my-helm.cue
```cue
// $ cat my-helm.cue
"my-helm": {
annotations: {}
@ -58,7 +58,7 @@ template: {
Import `vela/op` and complete the Cue code in `template`:
```
```cue
import (
"vela/op"
)

26
versioned_docs/version-v1.5/tutorials/sso.md
View File

@ -6,19 +6,19 @@ title: SSO Login
In KubeVela V1.3, we provide two methods to login: local login and SSO.
Local login uses the username and password stored in the local database to log in, and SSO integrates [Dex](https://dexidp.io/), which can be configured by configuring Dex's [OpenID Connect](https://dexidp.io/docs/openid-connect) to implement many different ways to log in, such as: GitHub, LDAP, etc.
Local login uses the username and password stored in the local database to log in, and SSO integrates [Dex](https://dexidp.io/), which can be configured by configuring Dex's [OpenID Connect](https://dexidp.io/docs/openid-connect) to implement many different ways to log in, such as GitHub, LDAP, Gitlab, Oidc, Saml, Google etc.
After the platform is initialized, local login is used by default. Platform administrators can configure SSO through the platform configuration page. In this tutorial, we'll use the GitHub and LDAP Connector to show how to use SSO with KubeVela.
After the platform is initialized, local login is used by default. Platform administrators can configure SSO through the platform configuration page. In this tutorial, we'll use GitHub and LDAP Connector to show how to use SSO with KubeVela.
## Enable Dex Addon
You need to enable the Dex Addon in the Addon list first to use SSO:
1. You need to enable the Dex Addon in the Addon list first to use SSO:
![alt](https://static.kubevela.net/images/1.3/dex-addon.png)
After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option:
2. After enabling the Dex Addon, we also need to upgrade the VelaUX addon and open its Dex option:
![alt](https://static.kubevela.net/images/1.3/upgrade-velaux.png)
![alt](https://static.kubevela.net/images/1.5/enable-dex-in-velaux.png)
## Configure Dex Connectors
@ -51,13 +51,17 @@ If your LDAP does not provide anonymous authentication access, then you need to
## Platform setting
Users who login in through SSO will be automatically bound to the users who have the same email in the local database, otherwise a new user will be created.
Users who log in through SSO will be automatically bound to the users who have the same email in the local database, otherwise, a new user will be created.
Since the newly logged in user does not have any permissions, we need to set an email address for the platform administrator first. After that, when you use a user with the same email address for SSO login, you can automatically have platform administrator privileges.
Since the newly logged-in user does not have any permissions, we need to set an email address for the platform administrator first. After that, when you use a user with the same email address for SSO login, you can automatically have platform administrator privileges.
After configuring the user email, we can change the login method to SSO login in the platform configuration page.
> The admin user also could log in from the dex with the email and password.
![alt](https://static.kubevela.net/images/1.3/platform-setting.png)
After configuring the user email, we can change the login method to SSO login on the platform configuration page. Before updating the configuration, it is strongly recommended to click `Click me to test open the dex page` to verify that the dex connector configuration is ready.
![alt](https://static.kubevela.net/images/1.5/platform-setting.jpg)
On this page, you could set the default project and roles for the users who log in through SSO.
## Use SSO Login
@ -65,8 +69,8 @@ Log out and refresh the page again, you can see that we have entered the Dex log
![alt](https://static.kubevela.net/images/1.3/dex-login.png)
Then, you select GitHub or LDAP to login.
Then, you select GitHub or LDAP to log in.
![alt](https://static.kubevela.net/images/1.3/dex-grant-access.png)
So far, we have successfully completed SSO login with GitHub. At this point, if the email of the logged in user can be associated with the email of the previously logged in user, the newly logged in user will inherit the permissions of the previous user.
So far, we have completed SSO login with GitHub. At this point, if the email of the log-in user can be associated with the email of the previously log-in user, the newly log-in user will inherit the permissions of the previous user.