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