A couple og missing information about the setup

[objectiflibre]

A couple og missing information about the setup

[fydrah]

Hi @nikolajbrinch,

1. Yes example.com is an example, you will need to configure your /etc/hosts (and minikube's one) to resolve the name. You can also try nip.io (used by minishift for setting up routes)

2. You can get the CA file from letsencrypt website. I think this CA is for production certs.
   You can also use a custom pki, and generate your own certs. I'll had a full example with a custom CA.

3. Which commands do you speak about ? Commands used to deploy the helm chart or commands for the kubenertes manifests ?

Regards,

[nikolajbrinch]

1. I figured it out :-) I just created a domain-name and used that including som CNAMEs for subdomains (dex, loginapp etc.), and used cert-manager for Letsencrypt. Everything works out fine - but it took a couple of days and a lot of searching around. I used the standard Dex chart and the example-app from dex to get initial bootstrapping done.
   I can't get minikube to boot using oidc konfiguration for the API server (latest version), so I droppen Minikube, and used acs-engine on Azure (that is what my company uses).
2. I never found a way to get trust into K8s, Dex & loginapp for letsencrypt staging certificates (or self signed ones) - maybe there is a way. Getting it up running with pure HTTP to begin with might be an option.
3. The kubectl commands.

Is the CRD still necessary for the authcodes? I can see that Dex itself creates a lot of CRDs when it starts.

Somewhere in one of the charts, I find that the Dex service account is given cluster-admin role, is this really a good idea og even necessary?

Thank you for your time and a great product!

[fydrah]

I can't get minikube to boot using oidc konfiguration for the API server (latest version)

Did you used the following options for minikube ?

[...]
--extra-config=apiserver.Authorization.Mode=RBAC \
 --extra-config=apiserver.Authentication.OIDC.IssuerURL=https://dex.example.com:5554/dex \
 --extra-config=apiserver.Authentication.OIDC.UsernameClaim=email \
 --extra-config=apiserver.Authentication.OIDC.ClientID="minikube" \
 --extra-config=apiserver.Authentication.OIDC.GroupsClaim=groups \
 --extra-config=apiserver.Authentication.OIDC.CAFile="/minikube-host/ssl/ca.pem" \
[...]

Getting it up running with pure HTTP to begin with might be an option.

Kubernetes will refuse to configure a non-https oidc issuer (or maybe there is an insecure option I did not see !)

3. I will add more doc + an example to easily setup the chart with minikube

Is the CRD still necessary for the authcodes? I can see that Dex itself creates a lot of CRDs when it starts.

I think yes, one of the crd created is used for authcodes.

Somewhere in one of the charts, I find that the Dex service account is given cluster-admin role, is this really a good idea og even necessary?

...where ?

Dex get is own ClusterRole with the following access rules:

rules:
- apiGroups: ["dex.coreos.com"] # API group created by dex
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["apiextensions.k8s.io"]
  resources: ["customresourcedefinitions"]
  verbs: ["create"] # To manage its own resources identity must be able to create customresourcedefinitions.

[fydrah]

Closing this issue because of inactivity.

Re-open if you have more questions.