The purpose of this knowledge base article is to describe which parameters should be specified in the Kommander 2.X configuration file to use GitHub as Dex upstream identity provider.
To instruct the Dex connector to use GitHub to perform the necessary OAuth2 flows to determine the user’s attributes (email, username, etc), the DKP operator must define the following parameters in the kommander configuration file [1]:
apiVersion: config.kommander.mesosphere.io/v1alpha1
kind: Installation
apps:
dex:
values: |
config:
connectors:
- type: github
id: github
name: Github
config:
clientID: <Client ID>
clientSecret: <Client Secret>
redirectURI: https://<LB-type Service IP Address>/dex/callback
To register an OAuth Apps in GitHub, the user should go to Settings/Developer settings and add a new OAuth App. During registration, the following parameters must be provided (not optional):
Application name: Please provide your app name (Let’s call it kommander-dex-github).
HomePage URL: LB-type Service IP Address
Authorization callback URL: LB-type Service IP Address/dell/callback
For additional details on how to create an OAuth app in Github please refer to our documentation [2].
Once the OAuth app has been created, the user should go to Settings / Developer settings /
kommander-dex-github where a Client ID is provided and Client Secret has to be generated.
The Client ID is the Application Id, while Client Secret refers to the credential that allows the registered application to authenticate as itself.
As to redirectURI, it is the location where the GitHub identity platform redirects a user's client and sends security tokens after authentication. This parameter refers to the ip address of 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"}}'
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. Below, we provide an example of a cluster role binding that assigns the cluster role “cluster-admin” to a user. Please note that in the “subjects.name” field the email attribute is specified.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-github
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: <email>
References:
[1] https://dexidp.io/docs/connectors/github/
[2] https://docs.d2iq.com/dkp/kommander/2.2/tutorials/authorize-all-users/