dex app
v1.42.13
Dex ist ein Identitätsdienst, der OpenID Connect zur Authentifizierung für Kubernetes verwendet. Es stellt eine Verbindung zu Identitätsanbietern von Drittanbietern wie Active Directory, LDAP und GitHub her. Während der Kubernetes-API-Server nur einen einzigen Identitätsanbieter und OIDC-Token-Aussteller unterstützt, ermöglicht die Verwendung von Dex die Verwendung von Identitäten verschiedener Anbieter bei der Authentifizierung für Kubernetes.
Diese App ist standardmäßig in Giant Swarm-Verwaltungsclustern installiert und kann auch in Workload-Clustern bereitgestellt werden.
Zusätzlich zu Dex selbst bietet diese App den Dex K8s Authenticator, der bei der Konfiguration von kubectl für Cluster hilft, die über Dex authentifiziert werden.
Es gibt mehrere Möglichkeiten, diese App zu installieren.
Sie stellen Ihre Konfiguration über eine benutzerdefinierte Datei values.yaml bereit. Hier ist ein Beispiel mit dem Connector für Azure Active Directory. Weitere Anschlussbeispiele finden Sie weiter unten.
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>/callbackEinige Anmerkungen:
.service.kubernetes.api.caPem ist das CA-Zertifikat Ihres Workload-Clusters im PEM-Format. Bei Giant Swarm können Sie dieses Zertifikat über den Befehl kubectl gs login abrufen, wenn Sie ein Client-Zertifikat für den Workload-Cluster erstellen. Es landet in Base46-codierter Form in Ihrer kubectl-Konfigurationsdatei. Das CA-Zertifikat ist für den Dex K8s Authenticator erforderlich.
Der redirectURI in Ihrer Connector-Konfiguration muss den richtigen Hostnamen für den eigenen Ingress von Dex enthalten. In der Standardform enthält es den Namen des Workload-Clusters (ersetzen Sie <CLUSTER> durch den tatsächlichen Namen) und eine Basisdomäne (ersetzen Sie <BASEDOMAIN> durch die richtige Basisdomäne).
Wenn Sie mehr als einen Connector konfigurieren, stellen Sie sicher, dass Sie für jeden Connector eine eindeutige id festlegen. Beachten Sie, dass diese Version von Dex so konfiguriert ist, dass allen Benutzergruppennamen die Connector-ID vorangestellt wird. Wenn id Ihres Connectors also customer lautet, wird eine Mitgliedschaft in der Gruppe devops als customer:devops angezeigt.
Beispiel-Anschlusskonfiguration für 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>/callbackBeispiel-Connector-Konfiguration für 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>/callbackNotiz:
<GITHUB_ORG_NAME> ist der Name Ihrer GitHub-Organisation. Zum Beispiel der Teil myorg in https://github.com/myorg .<GITHUB_TEAM_SLUG> ist der Teil der Team-URL, der den Teamnamen darstellt. Zum Beispiel der Teil my-team in https://github.com/orgs/myorg/teams/my-team . Die App wird über unsere App-Plattform in Workload-Clustern installiert. Bevor Sie dies tun, erstellen Sie bitte die folgende ConfigMap Ressource im Namespace, der nach diesem Workload-Cluster benannt ist, um den Inhalt Ihrer Datei values.yaml bereitzustellen.
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>Anschließend installieren Sie die App entweder über unsere Web-Benutzeroberfläche oder erstellen eine App-Ressource im folgenden Format:
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>Hinweise:
<CONFIGMAPNAME> muss durch den Namen der oben gezeigten ConfigMap-Ressource ersetzt werden.<CLUSTER> wird durch den Namen Ihres Workload-Clusters ersetzt.Als Ergebnis sollte Dex in Ihrem Workload-Cluster bereitgestellt werden.
Die Dex-App stellt eine Webschnittstelle bereit, auf die über https zugegriffen werden kann. Daher wird ein Eingang erstellt, der mit einem von einer Zertifizierungsstelle signierten TLS-Zertifikat konfiguriert werden muss, dem die Browser vertrauen müssen. Die App besteht aus mehreren Komponenten, die auch intern über https miteinander kommunizieren können müssen. Daher müssen auch die einzelnen App-Komponenten der Zertifizierungsstelle vertrauen, die die Zertifikate signiert.
Falls eine benutzerdefinierte Zertifizierungsstelle verwendet wird, muss diese den einzelnen App-Komponenten zugänglich gemacht und als vertrauenswürdig festgelegt werden, andernfalls können die Komponenten nicht miteinander kommunizieren und die App funktioniert möglicherweise nicht wie erwartet. Basierend auf dem Cluster-Setup kann dies durch die Bereitstellung eines zusätzlichen Wertesatzes zur App-Konfiguration erreicht werden:
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 deaktivieren, wird ein Geheimnis namens dex-tls erstellt und mit den vom Benutzer bereitgestellten b64-codierten Werten weitergegeben. Alternativ kann der Benutzer die Erstellung dieses Geheimnisses selbst verwalten und seine Verwendung wie folgt aktivieren: ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true Das folgende Geheimnis muss dann auf den Namespace angewendet werden, in dem dex ausgeführt wird:
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...Falls der Datenverkehr zu Dex über einen Proxy laufen muss (z. B. wenn die App in einem privaten Cluster installiert ist), müssen die einzelnen Komponenten der App für die Verwendung des Proxys eingerichtet werden.
Das Proxy-Setup kann der App in einem bestimmten Abschnitt der Benutzerwerte-Configmap oder des Secrets mit der App-Konfiguration bereitgestellt werden:
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 Zusätzlich zu einigen vordefinierten statischen Clients unterstützt die Dex-App auch die Möglichkeit, benutzerdefinierte statische Clients zu definieren. Sie müssen als Array von Objekten in einer bestimmten Eigenschaft der Konfigurations-YAML-Datei namens extraStaticClients definiert werden. Die Struktur jedes benutzerdefinierten statischen Clientobjekts ist genau die gleiche wie im Upstream-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 "Hinweise:
id und idEnv schließen sich gegenseitig aussecret und secretEnv schließen sich gegenseitig ausnameid oder idEnvsecret oder secretEnvZusätzliche statische Clients können auch als vertrauenswürdige Peers der vordefinierten statischen Clients konfiguriert werden:
Fügen Sie die zusätzliche statische Client-ID zur Liste der trustedPeers im vordefinierten statischen Client hinzu:
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 "Es wird die gleiche Konfiguration erzeugt:
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 : trueDuplikate werden verhindert, wenn die ID eines zusätzlichen vertrauenswürdigen Peers einer automatisch vorab ausgefüllten vertrauenswürdigen Peer-ID entspricht.
Giant Swarm erstellt derzeit die dex -App aus einem Fork des ursprünglichen Projekts. Wir implementieren zusätzliche Logik, die die Connector-ID als Präfix zu Benutzergruppen hinzufügt. Um das in diesem Diagramm verwendete Bild zu aktualisieren, müssen derzeit die folgenden Schritte in unserem Fork-Repo ausgeführt werden:
Dann in diesem Repo:
values.yaml sicher, dass values.schema.json aktualisiert wird, um alle Werte und ihre Typen korrekt wiederzugeben.master#release#v<major.minor.patch> , warten Sie, bis die entsprechende Release-PR erstellt wurde, genehmigen Sie sie und führen Sie sie zusammen.
