dex app
v1.42.13
Dex est un service d'identité qui utilise OpenID Connect pour gérer l'authentification pour Kubernetes. Il se connecte à des fournisseurs d'identité tiers comme Active Directory, LDAP et GitHub. Alors que le serveur API Kubernetes ne prend en charge qu'un seul fournisseur d'identité et émetteur de jetons OIDC, l'utilisation de Dex permet d'utiliser les identités de différents fournisseurs lors de l'authentification pour Kubernetes.
Cette application est installée par défaut dans les clusters de gestion Giant Swarm et est également prête à être déployée dans les clusters de charge de travail.
En plus de Dex lui-même, cette application fournit Dex K8s Authenticator, qui permet de configurer kubectl pour les clusters authentifiés via Dex.
Il existe plusieurs façons d'installer cette application.
Vous fournissez votre configuration via un fichier values.yaml personnalisé. Voici un exemple utilisant le connecteur pour Azure Active Directory. D’autres exemples de connecteurs peuvent être trouvés ci-dessous.
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>/callbackQuelques remarques :
.service.kubernetes.api.caPem est le certificat CA de votre cluster de charge de travail au format PEM. Chez Giant Swarm, vous pouvez récupérer ce certificat via la commande kubectl gs login, lors de la création d'un certificat client pour le cluster de charge de travail. Il se retrouve sous forme codée en Base46 dans votre fichier de configuration kubectl. Le certificat CA est requis par Dex K8s Authenticator.
Le redirectURI dans la configuration de votre connecteur doit contenir le nom d'hôte approprié pour la propre entrée de Dex. Dans le formulaire par défaut, il contient le nom du cluster de charge de travail (remplacez <CLUSTER> par le nom réel) et un domaine de base (remplacez <BASEDOMAIN> par le domaine de base approprié).
Si vous configurez plusieurs connecteurs, assurez-vous de définir un id unique pour chacun. Sachez que cette version de Dex est configurée pour préfixer tous les noms de groupes d'utilisateurs avec l'ID du connecteur. Ainsi, si id de votre connecteur est customer , une adhésion au groupe devops apparaîtra sous la forme customer:devops .
Exemple de configuration de connecteur pour 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>/callbackExemple de configuration de connecteur pour 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>/callbackNote:
<GITHUB_ORG_NAME> est le nom de votre organisation GitHub. Par exemple, la partie myorg dans https://github.com/myorg .<GITHUB_TEAM_SLUG> est la partie de l'URL de l'équipe représentant le nom de l'équipe. Par exemple, la partie my-team dans https://github.com/orgs/myorg/teams/my-team . L'application est installée dans des clusters de charges de travail, via notre plateforme d'applications. Avant de le faire, veuillez créer la ressource ConfigMap suivante dans l'espace de noms nommé d'après ce cluster de charge de travail pour fournir le contenu de votre fichier values.yaml .
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>Ensuite, soit vous installez l'application via notre interface utilisateur Web, soit vous créez une ressource d'application au format suivant :
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>Remarques :
<CONFIGMAPNAME> doit être remplacé par le nom de la ressource ConfigMap indiqué ci-dessus.<CLUSTER> est remplacé par le nom de votre cluster de charge de travail.Par conséquent, vous devriez voir Dex déployé dans votre cluster de charge de travail.
L'application Dex expose une interface Web accessible via https. Par conséquent, il crée une entrée qui doit être configurée avec un certificat TLS signé par une autorité de certification, qui doit être approuvée par les navigateurs. L'application se compose de plusieurs composants qui doivent également pouvoir communiquer entre eux en interne via https. Ainsi, l'autorité de certification qui signe les certificats doit également être approuvée par les composants individuels de l'application.
Si une autorité de certification personnalisée est utilisée, elle doit être exposée aux composants individuels de l'application et définie comme étant fiable, sinon les composants ne pourront pas communiquer entre eux et l'application risque de ne pas fonctionner comme prévu. En fonction de la configuration du cluster, cela peut être réalisé en fournissant un ensemble de valeurs supplémentaires à la configuration de l'application :
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 , un secret appelé dex-tls sera créé et propagé avec les valeurs codées en b64 fournies par l'utilisateur. Alternativement, l'utilisateur peut gérer lui-même la création de ce secret et permettre son utilisation comme suit : ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true Le secret suivant doit ensuite être appliqué à l'espace de noms dans lequel dex s'exécute :
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...Si le trafic vers Dex doit passer par un proxy (par exemple lorsque l'application est installée dans un cluster privé), les composants individuels de l'application doivent être configurés pour utiliser le proxy.
La configuration du proxy peut être fournie à l'application dans une section spécifique de la carte de configuration ou du secret des valeurs utilisateur avec la configuration de l'application :
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 En plus de quelques clients statiques prédéfinis, l'application Dex prend également en charge la possibilité de définir des clients statiques personnalisés. Ils doivent être définis comme un tableau d'objets dans une propriété spécifique du fichier de configuration yaml appelée extraStaticClients . La structure de chaque objet client statique personnalisé est exactement la même que dans Dex en amont :
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 "Remarques :
id et idEnv s'excluent mutuellementsecret et secretEnv s'excluent mutuellementnameid ou idEnvsecret ou secretEnvDes clients statiques supplémentaires peuvent également être configurés en tant que pairs de confiance des clients statiques prédéfinis :
Ajoutez l'ID client statique supplémentaire à la liste des trustedPeers dans le client statique prédéfini :
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 "Il produira la même configuration :
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 : trueLes duplications sont évitées dans le cas où l'ID d'un homologue de confiance supplémentaire est égal à un ID d'homologue de confiance automatiquement prérempli.
Giant Swarm construit actuellement l'application dex à partir d'un fork du projet original. Nous implémentons une logique supplémentaire qui ajoute l'identifiant du connecteur comme préfixe aux groupes d'utilisateurs. Afin de mettre à jour l'image utilisée dans ce graphique, il est actuellement nécessaire de suivre les étapes suivantes dans notre dépôt fork :
Puis dans ce dépôt :
values.yaml , assurez-vous que values.schema.json est mis à jour pour refléter correctement toutes les valeurs et leurs types.master#release#v<major.minor.patch> , attendez que la version PR correspondante soit créée, approuvez-la, fusionnez-la.
