dex app
v1.42.13
Dex é um serviço de identidade que usa OpenID Connect para lidar com autenticação para Kubernetes. Ele se conecta a provedores de identidade de terceiros, como Active Directory, LDAP e GitHub. Embora o servidor API Kubernetes suporte apenas um único provedor de identidade e emissor de token OIDC, o uso de Dex permite usar identidades de vários provedores ao autenticar para Kubernetes.
Este aplicativo é instalado em clusters de gerenciamento do Giant Swarm por padrão e também está pronto para ser implementado em clusters de carga de trabalho.
Além do próprio Dex, este aplicativo fornece o Dex K8s Authenticator, que ajuda a configurar kubectl para clusters autenticados via Dex.
Existem várias maneiras de instalar este aplicativo.
Você fornece sua configuração por meio de um arquivo values.yaml personalizado. Aqui está um exemplo usando o conector para Azure Active Directory. Mais exemplos de conectores podem ser encontrados abaixo.
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>/callbackAlgumas notas:
.service.kubernetes.api.caPem é o certificado CA do seu cluster de carga de trabalho no formato PEM. No Giant Swarm, você pode recuperar esse certificado por meio do comando kubectl gs login, ao criar um certificado de cliente para o cluster de carga de trabalho. Ele termina no formato codificado em Base46 em seu arquivo de configuração kubectl. O certificado CA é exigido pelo autenticador Dex K8s.
O redirectURI na configuração do seu conector deve conter o nome de host adequado para a entrada do próprio Dex. No formato padrão, ele contém o nome do cluster de carga de trabalho (substitua <CLUSTER> pelo nome real) e um domínio base (substitua <BASEDOMAIN> pelo domínio base adequado).
Se você configurar mais de um conector, defina um id exclusivo para cada um. Esteja ciente de que esta versão do Dex está configurada para prefixar todos os nomes de grupos de usuários com o ID do conector. Portanto, se id do seu conector for customer , uma associação ao grupo devops aparecerá como customer:devops .
Exemplo de configuração de 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>/callbackExemplo de configuração de 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>/callbackObservação:
<GITHUB_ORG_NAME> é o nome da sua organização GitHub. Por exemplo, a parte myorg em https://github.com/myorg .<GITHUB_TEAM_SLUG> é a parte da URL da equipe que representa o nome da equipe. Por exemplo, a parte my-team em https://github.com/orgs/myorg/teams/my-team . O aplicativo é instalado em clusters de carga de trabalho, por meio de nossa plataforma de aplicativos. Antes de fazer isso, crie o seguinte recurso ConfigMap no namespace nomeado após esse cluster de carga de trabalho para fornecer o conteúdo do seu arquivo values.yaml .
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>Em seguida, você instala o aplicativo por meio de nossa IU da web ou cria um recurso de aplicativo no seguinte 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> deve ser substituído pelo nome do recurso ConfigMap mostrado acima.<CLUSTER> é substituído pelo nome do cluster de carga de trabalho.Como resultado, você deverá ver o Dex implantado em seu cluster de carga de trabalho.
O aplicativo Dex expõe uma interface web, que pode ser acessada por https. Portanto, ele cria um ingresso, que precisa ser configurado com um certificado TLS assinado por uma autoridade certificadora, que precisa ser confiável para os navegadores. O aplicativo consiste em vários componentes, que também precisam ser capazes de se comunicar entre si internamente por meio de https. Portanto, a autoridade de certificação que assina os certificados também precisa ser confiável para os componentes individuais do aplicativo.
Caso uma autoridade de certificação personalizada seja usada, ela precisa ser exposta aos componentes individuais do aplicativo e definida como confiável, caso contrário, os componentes não conseguirão se comunicar entre si e o aplicativo poderá não funcionar conforme o esperado. Com base na configuração do cluster, isso pode ser conseguido fornecendo um conjunto adicional de valores à configuração do aplicativo:
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 , um segredo chamado dex-tls será criado e propagado com os valores codificados em b64 fornecidos pelo usuário. Alternativamente, o usuário pode gerenciar a criação deste segredo por conta própria e habilitar seu uso da seguinte forma: ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true O seguinte segredo precisa ser aplicado ao namespace dex em execução:
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...Caso o tráfego para Dex precise passar por um proxy (por exemplo, quando o aplicativo está instalado em um cluster privado), os componentes individuais do aplicativo precisam ser configurados para usar o proxy.
A configuração do proxy pode ser fornecida ao aplicativo em uma seção específica do mapa de configuração ou segredo dos valores do usuário com a configuração do aplicativo:
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 Além de alguns clientes estáticos predefinidos, o aplicativo Dex também suporta a possibilidade de definir clientes estáticos personalizados. Eles precisam ser definidos como uma matriz de objetos em uma propriedade específica do arquivo yaml de configuração chamada extraStaticClients . A estrutura de cada objeto cliente estático personalizado é exatamente a mesma do Dex upstream:
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 são mutuamente exclusivassecret e secretEnv são mutuamente exclusivasnameid ou idEnvsecret ou secretEnvClientes estáticos extras também podem ser configurados como pares confiáveis dos clientes estáticos predefinidos:
Adicione o ID do cliente estático extra à lista de trustedPeers no 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 "Ele produzirá a mesma configuração:
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 : trueDuplicidades são evitadas caso um ID de qualquer peer confiável adicional seja igual a um ID de peer confiável pré-preenchido automaticamente.
Giant Swarm está atualmente construindo o aplicativo dex a partir de uma bifurcação do projeto original. Implementamos uma lógica adicional que adiciona o ID do conector como prefixo aos grupos de usuários. Para atualizar a imagem usada neste gráfico, atualmente é necessário executar as seguintes etapas em nosso repositório fork:
Então neste repositório:
values.yaml , certifique-se de que values.schema.json esteja atualizado para refletir todos os valores e seus tipos corretamente.master#release#v<major.minor.patch> , aguarde a criação do PR de lançamento correspondente, aprove-o e mescle-o.
