mintel/dex-k8s-authenticator

A Kubernetes Dex Client Authenticator

Dex K8s Authenticator

A helper web-app which talks to one or more Dex Identity services to generate kubectl commands for creating and modifying a kubeconfig.

The Web UI supports generating tokens against multiple cluster such as Dev / Staging / Production.

Also provides

• Helm Charts
• SSL Support
• Linux/Mac/Windows instructions

Documentation

• Developing and Running
• Configuration Options
• Using the Helm Charts
• SSL Support

Screen shots

Contributing

Feel free to raise feature-requests and bugs. PR's are also very welcome.

Alternatives

• https://github.com/heptiolabs/gangway
• https://github.com/micahhausler/k8s-oidc-helper
• https://github.com/negz/kuberos
• https://github.com/negz/kubehook
• https://github.com/fydrah/loginapp

This application is based on the original example-app available in the CoreOS Dex repo.

dex-k8s-authenticator's Issues

Add an automated build to Docker Hub or Quay

It would be nice to provide a reference build of the dex-k8s-authenticator container image somewhere.

I have made an automated build of my fork. You could do the same thing for this repo instead.
https://hub.docker.com/r/whereisaaron/dex-k8s-authenticator/

We should also start make SemVer releases, so e.g. apply a 'v0.1' tag and get Docker Hub to build each SemVer tag.

Add copy-to-clipboard option for selecting kubectl config commands

If you're using multipel clients (i.e. different laptops to connect to the same cluster), then your'll need to generate a new re-fresh token each time (unless you have some centralized store)

It's easy to incorrectly copy the credentials (mostly because they go off the page).

helm installation of Dex does not deploy functional Dex server

Deployed Dex using

$ helm upgrade --install --namespace dex-server-ns --values dex-server.yaml dex-server-helm charts/dex
Release "dex-server-helm" does not exist. Installing it now.
NAME:   dex-server-helm
LAST DEPLOYED: Wed Jul 11 17:18:32 2018
NAMESPACE: dex-server-ns
STATUS: DEPLOYED

RESOURCES:
==> v1/Secret
NAME             TYPE    DATA  AGE
dex-server-helm  Opaque  7     0s

==> v1beta1/Ingress
NAME             HOSTS                                        ADDRESS  PORTS  AGE
dex-server-helm  dex.ingress.dex-server.example.com  80, 443  0s

==> v1/Pod(related)
NAME                              READY  STATUS             RESTARTS  AGE
dex-server-helm-75f46d4cf9-9jbdp  0/1    ContainerCreating  0         0s

==> v1/ConfigMap
NAME             DATA  AGE
dex-server-helm  1     0s

==> v1/ServiceAccount
NAME              SECRETS  AGE
dex-sa-server-pd  1        0s

==> v1beta1/ClusterRole
NAME             AGE
dex-server-helm  0s

==> v1beta1/ClusterRoleBinding
NAME             AGE
dex-server-helm  0s

==> v1beta1/Role
NAME             AGE
dex-server-helm  0s

==> v1beta1/RoleBinding
NAME             AGE
dex-server-helm  0s

==> v1/Service
NAME             TYPE       CLUSTER-IP    EXTERNAL-IP  PORT(S)   AGE
dex-server-helm  ClusterIP  10.8.0.58  <none>       5556/TCP  0s

==> v1/Deployment
NAME             DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
dex-server-helm  1        1        1           0          0s


NOTES:
1. Get the application URL by running these commands:
  https://dex.ingress.dex-server.example.com/

Accessing https://dex.ingress.dex-server.example.com/ in the browser thrown 404 error
Accessing https://dex.ingress.dex-server.example.com/callback in the browser throws error "Bad Request. User session error."
Accessing https://dex.ingress.dex-server.example.com/healthz in the browser works fine, "Health check passed in 24.320217ms"

Processes running on Pod and running config.yaml

$ kubectl exec dex-server-helm-75f46d4cf9-9jbdp -n dex-server-ns -- ps aux
PID   USER     TIME   COMMAND
    1 root       0:01 /usr/local/bin/dex serve /etc/dex/config.yaml

$ kubectl exec dex-server-helm-75f46d4cf9-9jbdp -n dex-server-ns -- cat /etc/dex/config.yaml
issuer: https://dex.ingress.dex-server.example.com

storage:
  type: kubernetes
  config:
    inCluster: true

web:
  http: 0.0.0.0:5556

frontend:
  theme: "coreos"
  issuer: "PD Company"
  issuerUrl: "https://dex.ingress.dex-server.example.com"
  #logoUrl: https://dex-server.example.com/images/logo-250x25.png

expiry:
  signingKeys: "6h"
  idTokens: "24h"

logger:
  level: debug
  format: json

oauth2:
  responseTypes: ["code", "token", "id_token"]
  skipApprovalScreen: true

# Remember you can have multiple connectors of the same 'type' (with different 'id's)
# If you need e.g. logins with groups for two different Microsoft 'tenants'
connectors:
# Microsoft App Dev account, 'Add an app'
# 'Application Secrets' -> 'Generate new password'
# 'Platforms' -> 'Add Platform' -> 'Web', add the callback URL
# https://apps.dev.microsoft.com/
- type: microsoft
  id: microsoft
  name: Microsoft
  config:
    clientID: AzureAD-ServerWebAppReg-id
    clientSecret: AzureAD-ServerWebAppReg-secret
    redirectURI: https://dex.ingress.dex-server.example.com/callback

enablePasswordDB: True
staticPasswords:
- email: "[email protected]"
  # bcrypt hash of the string "password"
  hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
  username: "admin"
  userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"

API Server Config

- --oidc-issuer-url=https://dex.ingress.dex-server.example.com
- --oidc-client-id=AzureAD-ServerWebAppReg-id

Deployment status

$ kubectl get ns
NAME            STATUS    AGE
default         Active    2h
dex-server-ns   Active    1h
kube-public     Active    2h
kube-system     Active    2h

$ kubectl get all -n dex-server-ns
NAME                                   READY     STATUS    RESTARTS   AGE
pod/dex-server-helm-75f46d4cf9-9jbdp   1/1       Running   1          1h

NAME                      TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/dex-server-helm   ClusterIP   10.8.0.58   <none>        5556/TCP   1h

NAME                              DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/dex-server-helm   1         1         1            1           1h

NAME                                         DESIRED   CURRENT   READY     AGE
replicaset.apps/dex-server-helm-75f46d4cf9   1         1         1         1h

Configured dex using https://github.com/coreos/dex/blob/master/Documentation/connectors/microsoft.md. Executing kubectl prompts for https://microsoft.com/devicelogin instead of https://dex.ingress.dex-server.example.com

Support Dex Web TLS options in Helm Chart

Example here: https://github.com/coreos/dex/blob/master/examples/k8s/dex.yaml

Should end up with a Dex config like:

  https: 0.0.0.0:443
  tlsCert: /etc/dex/ssl/dex.crt
  tlsKey: /etc/dex/ssl/dex.key

tlsCert and tlsKey can be mounted by k8s volumes.

Also pay attention to service ports (http vs https). We're currently binding to 5556 (we should probably use port 80 or 443 by default).

Dex repo has moved (as coreos is now owned by redhat).

https://github.com/dexidp/dex

Check location of images (as I suspect they will change too) and we'll need to adjust our chart values.

Ingress with path rule does not work

It looks like the code has hard-coded absolute paths for the static assets (/static), so if you use a path rule in the ingress, only the index page loads, but the assets don't. I'm using the NXING ingress controller and tried different combinations of annotations hoping that would fix the problem, but couldn't make it work.

Sample ingress config:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/add-base-url: "true"
    nginx.ingress.kubernetes.io/base-url-scheme: https
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
  labels:
    # ...
  name: dex-login-dex-k8s-authenticator
  namespace: dex
spec:
  rules:
  - host: infra.hppipeline.com
    http:
      paths:
      - backend:
          serviceName: dex-login-dex-k8s-authenticator
          servicePort: 5555
        path: /login

P.S. Thanks for contributing this -- it's a pretty useful tool!

Specifying caCerts in Helm chart values results in unused CA certificates

Just tested this with the following:

caCerts:
  enabled: true
  secrets:
    # Array of Self Signed Certificates
    # cat CA.crt | base64 -w 0
    #
    #     name: The internal k8s name of the secret we create. It's also used in
    #     the volumeMount name. It must respect the k8s naming convension (avoid
    #     upper-case and '.' to be safe).
    #
    #     filename: The filename of the CA to be mounted. It must end in .crt for
    #     update-ca-certificates to work
    #
    #     value: The base64 encoded value of the CA
    #
    - name: ca-cert1
      filename: ca1.crt
      value: "XXXX.....base64 cert 1 here..."
    - name: ca-cert2
      filename: ca2.crt
      value: "XXXX.....base64 cert 2 here..."

It looks like the Deployment does end up with these listed as mounts:

    Mounts:
      /app/config.yaml from config (rw)
      /certs/ca1.crt from login-dex-k8s-authenticator-ca-cert1 (rw)
      /certs/ca2.crt from login-dex-k8s-authenticator-ca-cert2 (rw)

However, I still get validation errors. You can see that these files are actually mounted as directories inside the Pod:

# ls -lAR /certs/*
/certs/ca1.crt:
total 0

/certs/ca2.crt:
total 0

If we inspect the file location on the Kubernetes host machine, we can see that it treats only the name as the true filename, while ca1.crt and ca2.crt are directories:

core@ip-123-45-6-78 ~ $ sudo ls -lA /var/lib/kubelet/pods/9a98a5d0-7405-11e8-a008-0eb17fad7d94/volumes/kubernetes.io~secret/login-dex-k8s-authenticator-ca-cert1/
total 0
drwxr-xr-x. 2 root root 60 Jun 19 21:13 ..2018_06_19_21_13_25.540309803
lrwxrwxrwx. 1 root root 31 Jun 19 21:13 ..data -> ..2018_06_19_21_13_25.540309803
lrwxrwxrwx. 1 root root 15 Jun 19 21:13 ca-cert1 -> ..data/ca-cert1
drwxrwxrwt. 2 root root 40 Jun 19 21:13 ca1.crt

core@ip-123-45-6-78 ~ $ sudo ls -lA /var/lib/kubelet/pods/9a98a5d0-7405-11e8-a008-0eb17fad7d94/volumes/kubernetes.io~secret/login-dex-k8s-authenticator-ca-cert2/
total 0
drwxr-xr-x. 2 root root 60 Jun 19 21:13 ..2018_06_19_21_13_25.626894990
lrwxrwxrwx. 1 root root 31 Jun 19 21:13 ..data -> ..2018_06_19_21_13_25.626894990
lrwxrwxrwx. 1 root root 15 Jun 19 21:13 ca-cert2 -> ..data/ca-cert2
drwxrwxrwt. 2 root root 40 Jun 19 21:13 ca2.crt

So, only those names ca-cert2 and ca-cert1 are valid files as far as the mountable Secret data content on the host looks.

Looks like issues assumed fixed in #35 & #36 are still problems?

As it turns out, the subPath attribute for a volume mount does not actually work on files (see: kubernetes/kubernetes#62156 ). This may be a bug in kubernetes, yet it it's current functional state, trying to use caCerts in this Helm chart does not work. This subPath as directory mount behavior matches my experience since subPath was introduced, but the docs don't make it clear that plain file mounts are not yet supported.

kubectl_version don't get from env variable

I setup config.yaml with env variable, but at result page kubectl download link look like

https://storage.googleapis.com/kubernetes-release/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl

my config:

clusters:
  ...
listen: http://0.0.0.0:5555
web_path_prefix: /
kubectl_version: ${KUBECTL_VERSION}
debug: true

authenticator and dex don't pick the new config automatically

When there is change in authenticator app config or dex server config the pods does not pick the config automatically. Users have to delete the pod so that new pod comes up with latest config.

Helm Chart network-policy

This probably requires more thought.

Communication from dex to dex-k8s-authenticator would be over http/https (going via the ingress using redirects), so this is probably is not a candidate that requires a network policy.

Where it would be useful is between dex and it's connectors, such as ldap.

Should we still maintain our dex chart?

It looks like there's a Dex chart in the k8s charts repo now (not tried it yet).

https://github.com/kubernetes/charts/tree/master/stable/dex

Any thoughts on whether we should keep our own Dex chart? I don't see it requiring regular changes...but I like the idea of contributing to the official Dex chart - or pointing people in that direction (assuming it gets maintained and takes PR's).

Create helm charts for dex + dex-k8s-authenticator

I just wanted to call out that I have created helm charts to deploy dex and dex-k8s-authenticator, optionally in their own namespace, and including RBAC. Handles arbitrary numbers of connectors (including multiple of the same type) and connector secrets.

I'll offer them here, as soon as I get a chance to write the README's.

Why the need to define the redirect_uri in the config

It looks like this could be auto-generated by using the name field which is defined per cluster.

Perhaps instead define a server_name or hostname field, and construct the callback URL from that.

Fix dex health check probes to support ingress paths at non-root

The readiness and liveliness probes are hardcoded at /in the helm charts.

If you want to serve dex at a different url (usually via an ingress path), this needs to be customisable.

At the moment if you define a non root path, the checks fail and the pod gets killed.

We should introduce dedicated helm chart options for this.

Also make consistent with the dex-k8s-authenticator chart.

#51

Add sources and maintainers to Helm charts

Added PR #16 to tweak charts. @nabadger Add yourself to the maintainers lists in Chart.yaml

Secret naming problem

Hello. I try to start chart with secret data:
secrets:

  - name: CA.crt
    value:   LS0.....Cg==

But got an error:
Error: release authz failed: Secret "authz-dex-k8s-authenticator-CA.crt" is invalid: metadata.name: Invalid value: "authz-dex-k8s-authenticator-CA.crt": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

kubectl command include IDP cert argument, even if no IDP cert is specified

I offer PR #5 to fix one small bug and slightly improve the HTML of the kubeconfig HTML template

1. Only include IDP certificate in kubectl if one is specified
2. Add short description of result page title
3. Tweak CSS styles (for wrapping) and HTML templates (for language)

Token page improvements

I think some improvements on the token page are needed.

• The token should also be displayed in a seperate box with a link to the Kubernetes Dashboard if you have it deployed and available via ingress.
• The first command for retrieving the k8s-ca.crt is assuming you are in .kube directory already, which fails if you are somewhere else when running the command.

From:

kubectl config set-cluster my-cluster \
  --certificate-authority=certs/my-cluster/k8s-ca.crt \
  --server=https://kube-k8s.example.com:6443

To:

kubectl config set-cluster my-cluster \
  --certificate-authority=~/.kube/certs/my-cluster/k8s-ca.crt \
  --server=https://kube-k8s.example.com:6443

• Would be nice (if possible) to provide a way to just download the kubeconfig file. This would be useful if the user is running on Windows platform or want to use the kubeconfig to log into the Dashboard directly.

use ENV vars in config file

I'd love to be able use ENV vars from a kubernetes secret in the config file.
Right now we have to make the whole config secret instead of configmap.

I saw this in the change log:

Added envar substitutions. Can now generate a config based on values in the environment (useful for the client_secret).

would this unreleased feature allow me drop client_secret: <redacted> from my configmap and just use an ENV var to specifiy the client_secret.

Also love the tool. It makes it so much easy for our developers gain kubectl access. Thanks for writing this tool!.

Get Docker version numbers without the 'v'

Docker image version numbers conventionally don't have any prefix, like 'v' or 'v.' or 'ver'. But Github versions usually do have a 'v'. You can do both by having the 'v' in GitHub and using this pattern in Docker hub.

Add additional documentation regarding web_path_prefix

• Add information on why it's useful
• Add information on how the Dex redirectURI values should change
• Add information on on how the Ingress path would should (typically should match web-prefix-path)

Given an example of how the Dex redirectURI

[Question] How to get Dex to reload config file into CRDs?

Hi @nabadger, sorry to open an issue to ask a question, but I was hoping you may have experience with this scenario and might be able to point me in the right direction...

We've been using your charts for dex and dex-k8s-authenticator (thanks again for those!), and everything was working fine until we had to add a new OAuth2 Client in dex's config. We can't seem to make dex pick up new values in the file, and so are getting a "Redirect URL not registered" error during the authentication flow, or at least that's my theory... I've recreated the dex pod to force it to re-read config, but no luck.

I'm not very experienced with Kubernetes Custom Resource Definitions (which is the dex storage implementation I'm using), or with dex's internals, but when I query the API for OAuth2Clients I get an empty list:

$ kubectl get --raw "/apis/dex.coreos.com/v1/oauth2clients/"
{"apiVersion":"dex.coreos.com/v1","items":[],"kind":"OAuth2ClientList","metadata":{"continue":"","resourceVersion":"3326407","selfLink":"/apis/dex.coreos.com/v1/oauth2clients/"}}

...which can't be true because I'm still able to complete the flow for another client I had previously configured in the file.

Maybe there's something else I'm missing or messed up in my config. Was just curious if you ever came across this and could help me debug.

Feel free to close this whenever you like.

Token page: supply 'certificate-authority-data' base64 encoded CA as an option to the 'certificate-authority' CA file

Being able to supply the base64 encoded K8s API CA in the config.yaml and Helm values would negate the need for hosting the CA file on we separate web service.

For example not only:
k8s_ca_uri
but also a second option:
k8s_ca_cert

• Means one can skip the first Token page step altogether "Copy Kubernetes CA certificate".
• Also windows clients don't need curl.

Question about certs in Helm config

In the helm config, there are values for tlsCert, tlsKey and k8s_ca_uri. I understanding that it needs the Kubernetes CA cert in order to generate the kubeconfig, but is there a way to just put that into the config as a base64 value instead of having to host it somewhere? Also, what exactly are the tlsCert and tlsKey supposed to be? Since the authenticator will be sitting behind a TLS secured ingress rule, it still needs a set of cert and key?

ClientID is used as cluster name value in templates

Hi!

First - thank yo so much for this project and especially for helm charts which you provided for both of dex and dex-k8s-authenticator ! 👍

But when I looked on the page with kubectl commands rendered after the successful authentication, I've noticed that in some places it uses .ClientID instead of .ClusterName (when the latter looks more reasonable). For example:

dex-k8s-authenticator/templates/linux-mac-common.html

Lines 80 to 82 in ab246db

	<pre><code class="hljs">kubectl config set-context {{ .Username }}-{{ .ClientID }} \
	--cluster={{ .ClientID }} \
	--user={{ .Username}}-{{.ClientID }}</code></pre>

and

dex-k8s-authenticator/templates/linux-mac-common.html

Line 90 in ab246db

<pre><code class="hljs">kubectl config use-context {{ .Username }}-{{ .ClientID}}</code></pre>

Actual Behavior

That is how it looks in my case:

# dex.yaml  - values file for the dex chart
# <...>

config: |-
  staticClients:
  - id: dex-k8s-authenticator
    name: my-k8s-cluster.com
    secret: "my-secret"
    redirectURIs:
    - https://login.my-k8s-cluster.com/callback/my-k8s-cluster.com

# <...>

# dex-k8s-authenticator.yaml  - values file for the dex-k8s-authenticator chart
# <...>

dexK8sAuthenticator:
  clusters:
  - name: my-k8s-cluster.com
    issuer: https://dex.my-k8s-cluster.com
    k8s_master_uri: https://my-k8s-cluster.com
    client_id: dex-k8s-authenticator
    client_secret: my-secret
    redirect_uri: https://login.my-k8s-cluster.com/callback/my-k8s-cluster.com

# <...>

And that's how commands are rendered on the page:

kubectl config set-cluster dex-k8s-authenticator \
    --certificate-authority=${HOME}/.kube/certs/my-k8s-cluster.com/k8s-ca.crt \
    --server=https://my-k8s-cluster.com

kubectl config set-credentials legal90-dex-k8s-authenticator \
    --auth-provider=oidc \
    --auth-provider-arg=idp-issuer-url=https://dex.my-k8s-cluster.com \
    --auth-provider-arg=client-id=dex-k8s-authenticator \
    --auth-provider-arg=client-secret=my-secret \
<...>

kubectl config set-context legal90-dex-k8s-authenticator \
    --cluster=dex-k8s-authenticator \
    --user=legal90-dex-k8s-authenticator

kubectl config use-context legal90-dex-k8s-authenticator

As we can see, there is dex-k8s-authenticator instead of my-k8s-cluster.com, the cluster name set in the config. I guess that will cause actual problems on the multi-cluster installations, when a single dex-k8s-authenticator instance is used to talk with multiple dex installations - each per cluster. In that case the client_id could be the same (theoretically).

Expected Behavior

I would expect the cluster name being an actual cluster identifier in my kubeconfig:

kubectl config set-cluster my-k8s-cluster.com \
    --certificate-authority=${HOME}/.kube/certs/my-k8s-cluster.com/k8s-ca.crt \
    --server=https://my-k8s-cluster.com

kubectl config set-credentials legal90-my-k8s-cluster.com \
    --auth-provider=oidc \
    --auth-provider-arg=idp-issuer-url=https://dex.my-k8s-cluster.com \
    --auth-provider-arg=client-id=dex-k8s-authenticator \
    --auth-provider-arg=client-secret=my-secret \
<...>

kubectl config set-context legal90-my-k8s-cluster.com \
    --cluster=my-k8s-cluster.com \
    --user=legal90-my-k8s-cluster.com

kubectl config use-context legal90-my-k8s-cluster.com

I can send a PR without any problem, but first I just want to make sure - is that a valid point, or I missed something?

Thank you!

livenessProbe and readinessProbe paths

-     chart: dex-k8s-authenticator-0.1.2
+     chart: dex-k8s-authenticator-1.1.1
      release: dex-k8s-authenticator
      heritage: Tiller
  spec:
    template:
      metadata:
        labels:
          app: dex-k8s-authenticator
      spec:
        containers:
        - name: dex-k8s-authenticator
          image: "mintel/dex-k8s-authenticator:1.1.0"
          livenessProbe:
            httpGet:
-             path: /
+             path: /healthz
              port: http
          readinessProbe:
            httpGet:
-             path: /
+             path: /healthz
              port: http

Is that what it should be set to by default?
curl for /healthz shows the same "Generate Kubernetes Token" page as before.

Consider drop-downs for selecting a cluster

< 5 clusters is fine in the current interface, but what if you have a lot more...the current UI would make it annoying.

Bump dex to v2.10.0

Update our dex-chart to use the latest release by default

Release notes

https://github.com/coreos/dex/releases/tag/v2.10.0

You must be logged in to the server

Hello,

I've installed both dex and dex-k8s-authenticator to use Google's service to login. The entire flow works however the generated components don't even let me make a request to the API server.

I get the following error:
error: You must be logged in to the server (Unauthorized)

I set up my apiServer configurations using KOPS and used the certificate it creates when creating the cluster. Not really sure how to debug this.

dex-k8s-authenticator Helm chart image issue

dex-k8s-authenticator helm chart user below Docker image

image:
  repository: mintel/dex-k8s-authenticator
  tag: latest
  pullPolicy: Always

But when the helm chart is deployed the container never comes up, error CrashLoopBackOff

# deployed helm using
$ helm upgrade --install --namespace dex-server-ns --values dex-k8s-authenticator-dex-server.yaml dex-server-app-helm charts/dex
$ kubectl get all -n dex-server-ns
NAME                                      READY     STATUS             RESTARTS   AGE
pod/dex-server-app-helm-dd68bcc69-9l7w9   0/1       CrashLoopBackOff   8          20m

Error

oci runtime error: container_linux.go:265: starting container process caused "exec: \"/usr/local/bin/dex\": stat /usr/local/bin/dex: no such file or directory"

Full events

Events:
  Type     Reason                 Age                 From                                                               Message
  ----     ------                 ----                ----                                                               -------
# Default values for dex-k8s-authenticator.
  Normal   Scheduled              20m                 default-scheduler                                                  Successfully assigned dex-server-app-helm-dd68bcc69-9l7w9 to dex-server-cpu-worker-7f765cf5dd-tcnjp
  Normal   SuccessfulMountVolume  20m                 kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  MountVolume.SetUp succeeded for volume "config"
  Normal   SuccessfulMountVolume  20m                 kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  MountVolume.SetUp succeeded for volume "dex-server-app-helm-token-64sgl"
  Normal   Pulling                19m (x4 over 20m)   kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  pulling image "mintel/dex-k8s-authenticator:latest"
  Normal   Pulled                 19m (x4 over 20m)   kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  Successfully pulled image "mintel/dex-k8s-authenticator:latest"
  Normal   Created                19m (x4 over 20m)   kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  Created container
  Warning  Failed                 19m (x4 over 20m)   kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  Error: failed to start container "dex": Error response from daemon: oci runtime error: container_linux.go:265: starting container process caused "exec: \"/usr/local/bin/dex\": stat /usr/local/bin/dex: no such file or directory"
  Warning  BackOff                31s (x95 over 20m)  kubelet, dex-server-cpu-worker-7f765cf5dd-tcnjp  Back-off restarting failed container

Add option to provide idp-certificate-authority inline

At the moment we only support IDPCaURI

We should support this inline, in a similar way to K8sCaPem

By doing this, we avoid any need to reference files hosted on external sites.

Error: apiVersion "apps/v1beta2" in dex/templates/deployment.yaml is not available

Is v1beta2 really necessary?

Added extra-scopes to kubeconfig once generated

Code calls

scopes = append(scopes, "openid", "profile", "email", "offline_access", "groups")

Should add this to the generated kubeconfig as well:

- name: ...
  user:
    auth-provider:
      config:
        client-id: ...
        client-secret: ...
        extra-scopes: openid,profile,email,offline_access,groups

Add Windows commands to kubeconfig screen

I'd like to extend the kubeconfig template to document, not just Linux/Mac shell commands, but also Powershell commands for Windows. Will need to use either use one line commands, or use the back-tick continuation for Powershell. $HOME works for both. Could add cmd.exe commands also I guess.

I'd also like to include download links for the appropriate kubectl / kubectl.exe

I'd like it to be a tabbed display in the HTML template, is a small clean and optional Javascript library can be used.

client secret configuration

Hello!

I'm using dex deployed via your charts except I'm using Ambassador to serve it. I'm looking at authenticator tools and this one is the natural choice. However, I'm a bit confused on how to configure it.

The configuration ask for a client_secret property, where would this come from?

Helm - add option to supply custom labels on the deployment

This has various use-cases (ours for example is to ensure the NetworkPolicy gets applied correctly via the pod-selector).

This applies for Dex and dex-k8s-authenticator.

Helm chart does not support a way to specify listen on https

chart hardcodes listen option like so:

listen: http://0.0.0.0:{{ default "5555" .port }}

Should just be able to support listen addess in chart-values, such that we end up with:

listen: {{ default "http://0.0.0.0" .listenAddress }}:{{ default "5555" .port }}

Note, requests only served on SSL if protocol is https (as well as supplying tls-cert/keys)

Improve documentation

There's some new functionality that isn't documented

• k8s_pem_ca: enables you to embed the k8s-ca in the config (and avoid having to setup an external hosting solution
• trusted_root_ca
• idp_ca_uri
• Updates to Dex helm chart to support TLS
• web_path_prefix option (which is sitting in a PR currently)

Get dex-k8s-authenticator chart listed in hub.helm.sh

Getting dex-k8s-authenticator listed in hub.helm.sh (https://github.com/helm/hub/blob/master/Repositories.md) would allow "easy" installation from helm, and even easier installation when helm goes decentralized in a few months.

make "charts" a helm/helmsman repo

The charts cannot be directly used with helm/helmsman. Need to make the charts directory a helm repo.

*config1

helmRepos:
  dex-k8s-authenticator: "https://github.com/mintel/dex-k8s-authenticator/tree/master/charts"
Error:
2018/09/05 13:59:34 ERROR: while adding repo [dex]: Error: Looks like "https://github.com/mintel/dex-k8s-authenticator/tree/master/charts" is not a valid chart repository or cannot be reached: Failed to fetch https://github.com/mintel/dex-k8s-authenticator/tree/master/charts/index.yaml : 404 Not Found

*config2

helmRepos:
  dex-k8s-authenticator: "https://github.com/mintel/dex-k8s-authenticator"
Error:
2018/09/05 14:00:17 ERROR: while adding repo [dex]: Error: Looks like "https://github.com/mintel/dex-k8s-authenticator" is not a valid chart repository or cannot be reached: Failed to fetch https://github.com/mintel/dex-k8s-authenticator/index.yaml : 404 Not Found

Dex chart should be removed from repository

It is redundant to keep Dex Helm chart in this repository, we should leave dex-k8s-authenticator chart and a good explanation of how to integrate it with Dex chart taken from stable/Dex repository.

Does dex-k8s-authenticator support SAML settings?

I am using Okta to login with DEX

In dex configurations i got login successful

But using dex-k8s-authenticator i got this error:

my configuration:

dexK8sAuthenticator:
  port: 5555
  debug: true
  web_path_prefix: /
  clusters:
  - name: XXXX
    short_description: "XXXX"
    description: "XXXX"
    issuer: http://k8s-dex.domain:5556/
    k8s_master_uri: https://api.k8s.domain
    client_id: XXXX
    client_secret: secret
    redirect_uri: http://k8s-login.domain:5555/callback/
    k8s_ca_pem: XYZ

service:
  annotations:
    dns.alpha.kubernetes.io/internal: "k8s-login.domain"
    service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0
  type: ClusterIP
  port: 5555

I am reading the dex-k8s-authenticator code, but i not found SAML support settings.

Does dex-k8s-authenticator support SAML settings?

Create a new 1.x release

There's been numerous changes since the last release - master has some breaking changes so we should cut a new release.

• Create 1.0.0
• Update chart versions to match
• Update Makefile (just tag as latest)
• Update changelog
• Be stricter with semantic versioning for any future releases

Extract and display useful information from the token

ref issue #8

We currently dump the entire contents of the token for the user to validate.

The fields of interest are:

• email
• email_verified (maybe)
• groups
• name (maybe)

Extract this information and display it in a nicer format.

Helm chart does not support a way to pass in tls_cert / tls_key

If we generate self-signed certs, the dex-k8s-authenticator helm chart does not provide a way to pass these in.

client secret

I'm trying to understand how dex-k8s-authenticator can be properly setup to work with the cli. My understanding is cli clients should be marked public for security reasons. This means they don't have a client secret. dex-k8s-authenticator is a web app, and should be a non public client with a redirect url defined. I would think dex-k8s-authenticator would give back a token for the public client and thus not have a secret. but in the documentation it is shown passing a client secret. Isn't this a problem?

Support nodePort 'port' specification via helm chart

This is fairly useful for debugging / testing.

At the moment we can specify the service type to be NodePort, but we don't have way specific the nodePort in the service template.

No page styling when running authenticator under a path

I am trying to deploy k8s-authenticator under /login path while I managed to get Dex working under /dex. It seems like a good way to make the URL clean and neat. However, when the pod spins up with Nginx ingress rule, the authenticator page loads with no styling at all. My guess is, it is not able to see that the context path should now be /login. Is there a way to fix this?

global:
  deployEnv: test

replicaCount: 1

image:
  repository: mintel/dex-k8s-authenticator
  tag: latest
  pullPolicy: Always

dexK8sAuthenticator:
  port: 5555
  debug: false
  logoUrl: https://cluster.domain.com/logo/small.png
  clusters:
  - name: test-cluster
    short_description: "Test Cluster"
    description: "Test Kubernetes Cluster"
    client_secret: pUBnBOY80SnXgjibTYM9ZWNzY2xreNGQok
    issuer: https://cluster.domain.com/dex
    k8s_master_uri: https://cluster.docmagic.com
    client_id: test-cluster
    redirect_uri: https://cluster.domain.com/login/callback
    k8s_ca_uri: https://cluster.domain.com/k8s/atlas-ca.crt

service:
  type: ClusterIP
  port: 5555

ingress:
  enabled: true
  annotations:
    kubernetes.io/ingress.class: nginx
  path: /login
  hosts:
    - cluster.domain.com
  tls:
    - secretName: domain-tls-cert
      hosts:
        - cluster.domain.com

resources: {}

nodeSelector: {}

tolerations: []

affinity: {}

Add apiVersion override for helm-chart components

apiVersion is hardcoded at the moment, but should be configurable.

Retry connection to provider instead of exiting straight away

2018/02/10 21:00:57 Failed to query provider "http://127.0.0.1:5556": Get http://127.0.0.1:5556/.well-known/openid-configuration: dial tcp 127.0.0.1:5556: getsockopt: connection refused