Lens: Cannot connect to cluster using OIDC

Created on 4 Oct 2019 · 15Comments · Source: lensapp/lens

Describe the bug
When connecting to a cluster that has OIDC enabled, Kontena says that the cluster is offline.

To Reproduce
Steps to reproduce the behavior:

Open Kontena
Select a cluster with OIDC authentication
Message is given stating 'Cluster is offline'

Expected behavior
Kontena should pass the login message through to the user so that they can authenticate. A retry button should be available after that completes.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

Lens Version:
OS: Windows
Installation method (e.g. snap or AppImage in Linux): Installer

Logs:
When you run the application executable from command line you will see some logging output. Please paste them here:

 info: Checking for update
info: initializing server for kubernetes.docker.internal:6443 on port 9600
info: initializing server for kubernetes.docker.internal:6443 on port 9601
info: initializing server for kube-api-p-rg-api-productio-b7d5a5-ffeac4a7.hcp.westus.azmk8s.io:443 on port 9602
info: initializing server for kube-api-s-rg-api-staging-319a50-ae3ee23b.hcp.westus.azmk8s.io:443 on port 9603
info: Update for version 2.0.9 is not available (latest version: 2.0.9, downgrade is disallowed).

Kubeconfig:
Quite often the problems are caused by malformed kubeconfig which the application tries to load. Please share your kubeconfig, remember to remove any secret and sensitive information.

your kubeconfig here

Additional context
Add any other context about the problem here.

bug

Source

cwoolum

👍1

Most helpful comment

That works! I'm able to connect to my cluster.

cwoolum on 13 Nov 2019

🎉2

All 15 comments

OIDC kubeconfig is not directly supported yet but it's possible to use https://github.com/int128/kubelogin .

Root cause: missing OIDC support in kubernetes typescript library. Should be fixed in next release where we use latest kubernetes client version.

jakolehm on 5 Oct 2019

Lens 2.1.0-beta.3 should have working OIDC support, could you test it?

https://kontena-lens-desktop.s3-eu-west-1.amazonaws.com/Lens%20Setup%202.1.0-beta.3.exe

jakolehm on 5 Oct 2019

That one says 'Connecting...' now but I'm not able to see the message to
sign in so I cannot authorize the connection.

On Sat, Oct 5, 2019 at 6:27 AM Jari Kolehmainen notifications@github.com
wrote:

Lens 2.1.0-beta.3 should have working OIDC support, could you test it?

https://kontena-lens-desktop.s3-eu-west-1.amazonaws.com/Lens%20Setup%202.1.0-beta.3.exe

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kontena/lens/issues/45?email_source=notifications&email_token=AAHGCT25N24CZXOJY4GBEK3QNCI5ZA5CNFSM4I5TGJP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANSJRQ#issuecomment-538649798,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHGCT36JOBJKJPAYOKXIKDQNCI5ZANCNFSM4I5TGJPQ
.

cwoolum on 6 Oct 2019

Workaround (using kubelogin):

- name: oidc-example
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - oidc-login
      - get-token
      - --oidc-issuer-url=https://idp.example.com
      - --oidc-client-id=<client-id>
      - --oidc-client-secret=<secret>
      command: kubectl

jakolehm on 6 Oct 2019

I don't think AKS works that way. They have their own built in process. The flow goes like this:

Add cluster from their CLI
Run kubectl proxy
A message is shown with a link and a code.
Click the link, sign in with your domain credentials, enter the code.
Authorization is routed back to kubectl and the portal is opened

cwoolum on 6 Oct 2019

@cwoolum Lens v2.1.4 has OIDC related fixes. Could you test if it fixes your use case?

jakolehm on 16 Oct 2019

Definitely making progress but got a 401. The add cluster process makes debugging much easier! Here's my kubeconfig and the error returned.

apiVersion: v1
kind: Config
preferences: {}
current-context: kube-api-staging
clusters:
  - name: kube-api-staging
    cluster:
      certificate-authority-data: >-
        {Redacted}
      server: >-
        https://server.hcp.westus.azmk8s.io:443
      insecure-skip-tls-verify: false
contexts:
  - name: kube-api-staging
    context:
      cluster: kube-api-staging
      user: my_user_account
users:
  - name: my_user_account
    user:
      auth-provider:
        config:
          access-token: >-
            {Redacted}
          tenant-id: 3b******-e6f7-4a4e-9fc6-f0********83
        name: azure

{ "response": { "statusCode": 401, "body": { "kind": "Status", "apiVersion": "v1", "metadata": {}, "status": "Failure", "message": "Unauthorized", "reason": "Unauthorized", "code": 401 }, "headers": { "audit-id": "9a6a109b-7b2f-4902-89c1-e4fa64fc2664", "content-type": "application/json", "date": "Wed, 16 Oct 2019 15:54:22 GMT", "content-length": "129", "connection": "close" }, "request": { "uri": { "protocol": "https:", "slashes": true, "auth": null, "host": "server.hcp.westus.azmk8s.io:443", "port": "443", "hostname": "server.hcp.westus.azmk8s.io", "hash": null, "search": null, "query": null, "pathname": "/version/", "path": "/version/", "href": "https://server.hcp.westus.azmk8s.io:443/version/" }, "method": "GET", "headers": { "authorization": "", "Authorization": "Bearer *Redacted*", "accept": "application/json" } } }, "body": {} }

cwoolum on 16 Oct 2019

@cwoolum Did you manage to get this working with AKS?

chelnak on 9 Nov 2019

No, because of the way that AKS wraps all of the auth pieces, I think the only way to make it work is to surface the login message.

cwoolum on 9 Nov 2019

😞 Thought that might be the case!

Great tool to use with the cluster admin context but I'd want people using their AAD accounts to login.

Maybe it's something that will come soon! Thanks for replying.

chelnak on 9 Nov 2019

update: this will be fixed in upcoming 2.6.0 release where we do complete re-write for the auth "proxy" we use within the app. We're gonna ditch the k8s JS client for that as it has some serious bugs & shortcomings for many cases, not only this Azure AAD case. The potential prompt for user will be surfaced in the initial connection to the cluster.