Skip to main content

Configuring Dex to use Microsoft as its upstream Identity Provider in Kommander 2.X

Sadiel Ortega
  • Updated

In this article we outline which parameters should be included in the Kommander 2.X configuration file to use Microsoft as Dex upstream identity provider [1]. 

 

To configure a Dex connector that uses Microsoft to perform the necessary OAuth2 flows to determine the user’s attributes (email, username, etc), the DKP operator should define the following  parameters in the kommander configuration file: 

apiVersion: config.kommander.mesosphere.io/v1alpha1
kind: Installation
apps:
  dex:
    values: |
      config:
        connectors:
        - type: microsoft
          id: microsoft
          name: microsoft
          config:
            clientID: <Client ID>
            clientSecret: <Client Secret>
            redirectURI: https://LB-type Service IP Address/dex/callback
            tenant: <Tenant ID>

clientID: this is the application Id, please refer to [2] if in doubt of where to find this parameter. 

clientSecret: refers to the credential that allows the registered application to authenticate as itself, for further details please refer to the Azure documentation [3].

 

redirectURI: in general, a redirect URI is the location where the Microsoft identity platform redirects a user's client and sends security tokens after authentication [4]. In our case, it is the Dex issuer URL plus “callback”, that is, the ip address is the metallb ip address, in case is an on-premise DKP cluster, or the FQDN of the cloud Load Balancer, in case of a cluster deployed in a cloud provider. In any case, the following command can be used to get the endpoint:

kubectl -n kommander get svc kommander-traefik -o go-template='https://{{with index .status.loadBalancer.ingress 0}}{{or .hostname .ip}}{{end}}/dkp/kommander/dashboard{{ "\n"}}' 


tenant: refers to the Azure AD tenant, please refer to Azure documentation for further details [5].

 

As users from an external IdP do not have access to kubernetes resources, privileges must be granted by binding to a role that grants an specific level of access to resources in the cluster [6]. 

 

Below, an example of a cluster role binding that assigns the cluster role “cluster-admin” [7] to a user. Please note that in the “subjects.name” field a User principal name [8] attribute is specified. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: sadiel-admin-microsoft
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: <UserPrincipalName>


References:
[1] https://dexidp.io/docs/connectors/microsoft/

[2] https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#register-an-application

[3] https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-credentials

[4] https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-a-redirect-uri

[5] https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant

[6] https://docs.d2iq.com/dkp/konvoy/1.8/access-authentication/rbac/#the-basics

[7] https://docs.d2iq.com/dkp/konvoy/1.8/access-authentication/rbac/#default-roles

[8] https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-userprincipalname