dex app下载 - dex app源码下载

右旋糖酐

Dex 是一种身份服务，使用 OpenID Connect 处理 Kubernetes 的身份验证。它连接到第三方身份提供商，例如 Active Directory、LDAP 和 GitHub。虽然 Kubernetes API 服务器仅支持单个身份提供商和 OIDC 令牌颁发者，但使用 Dex 允许在对 Kubernetes 进行身份验证时使用来自不同提供商的身份。

该应用程序默认安装在 Giant Swarm 管理集群中，也可以部署在工作负载集群中。

除了 Dex 本身之外，该应用程序还提供 Dex K8s Authenticator，它有助于为通过 Dex 进行身份验证的集群配置kubectl 。

安装中

有多种方法可以安装此应用程序。

使用我们的网络界面
在管理集群中创建App资源。有关详细信息，请查看应用程序平台入门指南。

配置

您可以通过自定义values.yaml文件提供配置。以下是使用 Azure Active Directory 连接器的示例。下面可以找到更多连接器示例。

 isWorkloadCluster : true
services :
  kubernetes :
    api :
      caPem : |
        -----BEGIN CERTIFICATE-----
        M...=
        -----END CERTIFICATE-----
oidc :
  expiry :
    signingKeys : 6h
    idTokens : 30m
  customer :
    connectors :
    - id : customer
      connectorName : test
      connectorType : microsoft
      connectorConfig : |-
        clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
        clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
        tenant: <TENANT-SET-SET-IN--YOUR-IdP>
        redirectURI: https://dex.<CLUSTER>.<BASEDOMAIN>/callback

一些注意事项：

.service.kubernetes.api.caPem是 PEM 格式的工作负载集群的 CA 证书。在 Giant Swarm，您可以在为工作负载集群创建客户端证书时通过 kubectl gs login 命令检索此证书。它最终以 Base46 编码的形式出现在您的 kubectl 配置文件中。 Dex K8s Authenticator 需要 CA 证书。
连接器配置中的redirectURI必须包含Dex自己的入口的正确主机名。在默认形式中，它包含工作负载集群名称（将<CLUSTER>替换为实际名称）和基本域（将<BASEDOMAIN>替换为正确的基本域）。
如果您配置多个连接器，请确保为每个连接器设置唯一的id 。请注意，此版本的 Dex 配置为在所有用户组名称前添加连接器 ID 前缀。因此，如果您的连接器的id是customer ， devops组中的成员资格将显示为customer:devops 。

其他连接器类型

Keycloak 的连接器配置示例：

    - id : customer
      connectorName : test
      connectorType : oidc
      connectorConfig : |-
        clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
        clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
        insecureEnableGroups: true
        scopes:
        - email
        - groups
        - profile
        issuer: https://<IDP_ENDPOINT>/auth/realms/master
        redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callback

GitHub 的连接器配置示例：

    - id : customer
      connectorName : test
      connectorType : github
      connectorConfig : |-
        clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
        clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
        loadAllGroups: false
        teamNameField: slug
        orgs:
        - name: <GITHUB_ORG_NAME>
          teams:
          - <GITHUB_TEAM_SLUG>
        redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callback

笔记：

<GITHUB_ORG_NAME>是您的 GitHub 组织名称。例如https://github.com/myorg中的myorg部分。
<GITHUB_TEAM_SLUG>是团队 URL 中代表团队名称的部分。例如， https://github.com/orgs/myorg/teams/my-team中的my-team部分。

在 Giant Swarm 工作负载集群中安装 Chart

该应用程序通过我们的应用程序平台安装在工作负载集群中。在此之前，请在以该工作负载集群命名的命名空间中创建以下ConfigMap资源，以提供values.yaml文件的内容。

 apiVersion : v1
kind : ConfigMap
metadata :
  name : dex-app-user-values
  namespace : <CLUSTER>
data :
  values : |
    <content of values.yaml>

然后，您可以通过我们的 Web UI 安装应用程序，也可以按以下格式创建应用程序资源：

 apiVersion : application.giantswarm.io/v1alpha1
kind : App
metadata :
  labels :
    app.kubernetes.io/name : dex-app
  name : dex-app
  namespace : <CLUSTER>
spec :
  catalog : giantswarm-playground
  name : dex-app
  namespace : dex
  userConfig :
    configMap :
      name : <CONFIGMAPNAME>
      namespace : <CLUSTER>

笔记：

<CONFIGMAPNAME>必须替换为上面显示的 ConfigMap 资源的名称。
<CLUSTER>替换为您的工作负载集群的名称。

因此，您应该会看到 Dex 部署在您的工作负载集群中。

Ingress、TLS 和自定义证书颁发机构

Dex 应用程序公开了一个 Web 界面，可通过 https 访问。因此，它创建了一个入口，该入口需要配置由证书颁发机构签名的 TLS 证书，该证书需要被浏览器信任。该应用程序由多个组件组成，这些组件还需要能够通过 https 进行内部通信。因此，签署证书的证书颁发机构也需要受到各个应用程序组件的信任。

如果使用自定义证书颁发机构，则需要将其公开给各个应用程序组件并将其设置为受信任，否则组件将无法相互通信，并且应用程序可能无法按预期工作。根据集群设置，这可以通过向应用程序配置提供一组附加值来实现：

将证书颁发机构的 Base64 编码证书添加到用户值配置映射或密钥中。在集群中使用自定义自签名证书时，此选项非常有用：

 ingress :
  tls :
    letsencrypt : false
    caPemB64 : " base64-encoded CA certificate "

提供对现有 Secret 资源的引用，其中包含自定义证书颁发机构。此选项对于集群设置很有用，其中由自定义证书颁发机构签名的 TLS 证书由外部服务提供：

 ingress :
  tls :
    letsencrypt : false

trustedRootCA :
  name : " name-of-the property-in-the-secret "
  secretName : " name-of-the-custom-ca-secret "

禁用letsencrypt时，将创建一个名为dex-tls机密，并使用用户提供的 b64 编码值进行传播。或者，用户可以自己管理此秘密的创建并启用其使用，如下所示：

 ingress :
  tls :
    letsencrypt : false
    externalSecret :
      enabled : true

然后需要将以下秘密应用于运行dex命名空间：

 apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
  name : dex-tls
data :
  ca.crt : ...
  tls.crt : ...
  tls.key : ...

代理配置

如果到 Dex 的流量需要通过代理（例如，当应用程序安装在私有集群中时），则需要将应用程序的各个组件设置为使用代理。

代理设置可以通过应用程序配置在用户值 configmap 或机密的特定部分中提供给应用程序：

 cluster :
  proxy :
    http : " https://proxy.host:4040 " # hostname of the proxy for HTTP traffic
    https : " https://proxy.host:4040 " # hostname of the proxy for HTTPS traffic
    noProxy : " kubernetes-api-ip-range " # comma-separated list of hostnames and IP ranges, whose traffic should not go through the proxy. # Kubernetes API IP range needs to be defined here in order for Dex to work correctly

静态客户端

除了一些预定义的静态客户端之外，Dex 应用程序还支持定义自定义静态客户端的可能性。它们需要在名为extraStaticClients的配置 yaml 文件的特定属性中定义为对象数组。每个自定义静态客户端对象的结构与上游 Dex 中的结构完全相同：

 extraStaticClients :
- id : " client-id "
  secret : " client-secret "
  trustedPeers :
  - " https://example.com "
  public : true
  name : " client-name-1 "
  logoURL : " https://example.com/logo "
- idEnv : " CLIENT_ID "
  secretEnv : " CLIENT_SECRET "
  redirectURIs :
  - " https://example.com/redirect "
  name : " client-name-2 "

笔记：

id和idEnv属性是互斥的
secret和secretEnv属性是互斥的
所需属性：
- name
- id或idEnv
- secret或secretEnv

额外的静态客户端还可以配置为预定义静态客户端的可信对等体：

将额外的静态客户端 ID 添加到预定义静态客户端中的trustedPeers列表中：

 staticClients :
  dexK8SAuthenticator :
    clientAddress : " dex.installation.basedomain.io "
    clientSecret : " default-client-dex-authenticator-secret "
    trustedPeers :
    - " client-id " 
extraStaticClients :
- id : " client-id "
  name : " client-name-1 "
  secret : " client-secret "

它将产生相同的配置：

 staticClients :
- id : dex-k8s-authenticator
  name : dex-k8s-authenticator
  secret : default-client-dex-authenticator-secret
  trustedPeers :
  - client-id
- id : client-id
  name : client-name-1
  secret : client-secret
  public : true