dex app
v1.42.13
Dex は、OpenID Connect を使用して Kubernetes の認証を処理するアイデンティティ サービスです。 Active Directory、LDAP、GitHub などのサードパーティ ID プロバイダーに接続します。 Kubernetes API サーバーは単一の ID プロバイダーと OIDC トークン発行者のみをサポートしますが、Dex を使用すると、Kubernetes の認証時にさまざまなプロバイダーの ID を使用できます。
このアプリはデフォルトで Giant Swarm 管理クラスターにインストールされ、ワークロード クラスターにデプロイする準備もできています。
Dex 自体に加えて、このアプリは Dex K8s Authenticator を提供します。これは、Dex 経由で認証されたクラスターのkubectlの構成に役立ちます。
このアプリをインストールするにはいくつかの方法があります。
カスタムの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 コマンドを使用してこの証明書を取得できます。 kubectl 構成ファイルでは Base46 でエンコードされた形式になります。 CA 証明書は Dex K8s Authenticator に必要です。
コネクタ構成の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>/callbackGitHub のコネクタ構成の例:
- 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部分。アプリは、アプリ プラットフォームを介してワークロード クラスターにインストールされます。これを行う前に、そのワークロード クラスターにちなんで名付けられた名前空間に次の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 がデプロイされていることがわかります。
Dex アプリは、https 経由でアクセスできる Web インターフェイスを公開します。したがって、イングレスを作成します。イングレスは、認証局によって署名された TLS 証明書を使用して構成する必要があり、ブラウザーによって信頼される必要があります。アプリはいくつかのコンポーネントで構成されており、https 経由で内部的に相互通信できる必要もあります。したがって、証明書に署名する認証局は、個々のアプリ コンポーネントからも信頼される必要があります。
カスタム証明機関を使用する場合は、それを個々のアプリ コンポーネントに公開し、信頼できるものとして設定する必要があります。そうしないと、コンポーネントが相互に通信できなくなり、アプリが期待どおりに動作しなくなる可能性があります。これは、クラスターのセットアップに基づいて、アプリ構成に追加の値のセットを提供することで実現できます。
ingress :
tls :
letsencrypt : false
caPemB64 : " base64-encoded CA certificate " 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 または Secret の特定のセクションでアプリに提供できます。
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プロパティは相互に排他的ですnameidまたはidEnvsecretまたは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追加の信頼できるピアの ID が、自動的に事前設定された信頼できるピア ID と等しい場合、重複は防止されます。
Giant Swarm は現在、元のプロジェクトのフォークからdexアプリを構築しています。コネクタ ID をプレフィックスとしてユーザー グループに追加する追加ロジックを実装します。このチャートで使用されているイメージを更新するには、現時点ではフォーク リポジトリで次の手順を実行する必要があります。
次に、このリポジトリでは次のようになります。
values.yamlを変更する場合は、すべての値とその型を正しく反映するように、 values.schema.jsonが更新されていることを確認してください。master#release#v<major.minor.patch>を作成し、対応するリリース PR が作成されるのを待ち、承認してマージします。
