dex app
v1.42.13
Dex es un servicio de identidad que utiliza OpenID Connect para gestionar la autenticación de Kubernetes. Se conecta a proveedores de identidad de terceros como Active Directory, LDAP y GitHub. Si bien el servidor API de Kubernetes solo admite un único proveedor de identidad y un emisor de token OIDC, el uso de Dex permite utilizar identidades de varios proveedores al autenticarse en Kubernetes.
Esta aplicación se instala en los clústeres de administración de Giant Swarm de forma predeterminada y también está lista para implementarse en clústeres de cargas de trabajo.
Además del propio Dex, esta aplicación proporciona Dex K8s Authenticator, que ayuda a configurar kubectl para clústeres autenticados a través de Dex.
Hay varias formas de instalar esta aplicación.
Usted proporciona su configuración a través de un archivo values.yaml personalizado. A continuación se muestra un ejemplo que utiliza el conector para Azure Active Directory. A continuación se pueden encontrar más ejemplos de conectores.
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>/callbackAlgunas notas:
.service.kubernetes.api.caPem es el certificado de CA de su clúster de carga de trabajo en formato PEM. En Giant Swarm, puede recuperar este certificado mediante el comando kubectl gs login, al crear un certificado de cliente para el clúster de carga de trabajo. Termina en formato codificado en Base46 en su archivo de configuración de kubectl. El certificado CA es requerido por Dex K8s Authenticator.
El redirectURI en la configuración de su conector debe contener el nombre de host adecuado para el ingreso de Dex. En el formato predeterminado, contiene el nombre del clúster de carga de trabajo (reemplace <CLUSTER> con el nombre real) y un dominio base (reemplace <BASEDOMAIN> con el dominio base adecuado).
Si configura más de un conector, asegúrese de establecer una id única para cada uno. Tenga en cuenta que esta versión de Dex está configurada para anteponer a todos los nombres de grupos de usuarios el ID del conector. Entonces, si id de su conector es customer , la membresía en el grupo devops aparecerá como customer:devops .
Ejemplo de configuración del conector para 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>/callbackEjemplo de configuración del conector para 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>/callbackNota:
<GITHUB_ORG_NAME> es el nombre de su organización GitHub. Por ejemplo, la parte myorg en https://github.com/myorg .<GITHUB_TEAM_SLUG> es la parte de la URL del equipo que representa el nombre del equipo. Por ejemplo, la parte my-team en https://github.com/orgs/myorg/teams/my-team . La aplicación se instala en grupos de cargas de trabajo, a través de nuestra plataforma de aplicaciones. Antes de hacerlo, cree el siguiente recurso ConfigMap en el espacio de nombres que lleva el nombre de ese clúster de carga de trabajo para proporcionar el contenido de su archivo values.yaml .
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>Luego, instala la aplicación a través de nuestra interfaz de usuario web o crea un recurso de aplicación en el siguiente formato:
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>Notas:
<CONFIGMAPNAME> debe reemplazarse con el nombre del recurso ConfigMap que se muestra arriba.<CLUSTER> se reemplaza con el nombre de su clúster de carga de trabajo.Como resultado, debería ver Dex implementado en su clúster de cargas de trabajo.
La aplicación Dex expone una interfaz web a la que se puede acceder a través de https. Por lo tanto, crea una entrada, que debe configurarse con un certificado TLS firmado por una autoridad de certificación, en la que los navegadores deben confiar. La aplicación consta de varios componentes, que también deben poder comunicarse entre sí internamente a través de https. Por lo tanto, los componentes individuales de la aplicación también deben confiar en la autoridad de certificación que firma los certificados.
En caso de que se utilice una autoridad de certificación personalizada, es necesario exponerla a los componentes individuales de la aplicación y configurarla como confiable; de lo contrario, los componentes no podrán comunicarse entre sí y es posible que la aplicación no funcione como se esperaba. Según la configuración del clúster, esto se puede lograr proporcionando un conjunto adicional de valores a la configuración de la aplicación:
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 , se creará un secreto llamado dex-tls y se propagará con los valores codificados en b64 proporcionados por el usuario. Alternativamente, el usuario puede gestionar la creación de este secreto por sí mismo y habilitar su uso de esta manera: ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true Luego se debe aplicar el siguiente secreto al espacio de nombres en el que se ejecuta dex :
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...En caso de que el tráfico a Dex deba pasar a través de un proxy (por ejemplo, cuando la aplicación está instalada en un clúster privado), los componentes individuales de la aplicación deben configurarse para usar el proxy.
La configuración del proxy se puede proporcionar a la aplicación en una sección específica del mapa de configuración de valores del usuario o en un secreto con la configuración de la aplicación:
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 Además de algunos clientes estáticos predefinidos, la aplicación Dex también admite la posibilidad de definir clientes estáticos personalizados. Deben definirse como una matriz de objetos en una propiedad específica del archivo yaml de configuración llamada extraStaticClients . La estructura de cada objeto de cliente estático personalizado es exactamente la misma que en Dex ascendente:
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 "Notas:
id e idEnv son mutuamente excluyentessecret y secretEnv son mutuamente excluyentesnameid o idEnvsecret o secretEnvLos clientes estáticos adicionales también se pueden configurar como pares confiables de los clientes estáticos predefinidos:
Agregue la identificación del cliente estático adicional a la lista de trustedPeers en el cliente estático predefinido:
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 "Producirá la misma configuración:
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 : trueSe evitan duplicidades en caso de que un ID de cualquier par de confianza adicional sea igual a un ID de par de confianza rellenado automáticamente.
Giant Swarm actualmente está construyendo la aplicación dex a partir de una bifurcación del proyecto original. Implementamos lógica adicional que agrega la identificación del conector como prefijo a los grupos de usuarios. Para actualizar la imagen utilizada en este gráfico, actualmente es necesario realizar los siguientes pasos en nuestro repositorio fork:
Luego en este repositorio:
values.yaml , asegúrese de que values.schema.json esté actualizado para reflejar todos los valores y sus tipos correctamente.master#release#v<major.minor.patch> , espere a que se cree el PR de versión correspondiente, apruebe y fusione.
