tektoncd/dashboard

Tekton windows localhost OAuth setup failed

tppalani opened this issue · 12 comments

Expected behavior

I'm running latest version of tekton dashboard which is running kind cluster. As per the documentation i have configured all yaml files inclusing helm provider.

When i'm seeing ingress and pod all are up and running but not able to see the any UI page from the browser as per instructions.

Actual behavior

Not able to access Tekton Dashboard as well oauth sync page.

Steps to reproduce the bug

  1. values.yaml
config:
  clientID: my-id-from-github
  clientSecret: my-secret-github

extraArgs:
  provider: github
  whitelist-domain: .127.0.0.1.nip.io
  cookie-domain: .127.0.0.1.nip.io
  redirect-url: http://auth.127.0.0.1.nip.io/oauth2/callback
  cookie-secure: 'false'

ingress:
  enabled: true
  path: /
  hosts:
    - auth.127.0.0.1.nip.io
  1. ingress-tekton.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  namespace: tekton-pipelines
  annotations:
    nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.tools.svc.cluster.local/oauth2/auth
    nginx.ingress.kubernetes.io/auth-signin: http://auth.127.0.0.1.nip.io/oauth2/sign_in?rd=http://\$host\$request_uri
spec:
  rules:
  - host: tekton-dashboard.127.0.0.1.nip.io
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

Additional info

  • Kubernetes version:
  **Output of `kubectl version`:**
Client Version: v1.26.2-eks-a59e1f0
Kustomize Version: v4.5.7
Server Version: v1.27.1
  • Tekton versions:

    Output of tkn version or

    kubectl get deploy tekton-pipelines-controller -n tekton-pipelines -o=jsonpath="{\"Pipeline version: \"}{.metadata.labels.version}{\"\n\"}"
    

Pipeline version: v0.50.0

kubectl get deploy tekton-triggers-controller -n tekton-pipelines -o=jsonpath="{"Triggers version: "}{.metadata.labels.version}{"\n"}"

NA

kubectl get deploy tekton-dashboard -n tekton-pipelines -o=jsonpath="{"Dashboard version: "}{.metadata.labels.version}{"\n"}"

Dashboard version: v0.38.0
$ kubectl get ingress -A
NAMESPACE          NAME               CLASS    HOSTS                               ADDRESS     PORTS   AGE
tekton-pipelines   tekton-dashboard   <none>   tekton-dashboard.127.0.0.1.nip.io   localhost   80      11m
tools              oauth2-proxy       <none>   auth.127.0.0.1.nip.io               localhost   80      17m


Name:             tekton-dashboard
Labels:           <none>
Namespace:        tekton-pipelines
Address:          localhost
Ingress Class:    <none>
Default backend:  <default>
Rules:
Host                               Path  Backends
----                               ----  --------
tekton-dashboard.127.0.0.1.nip.io
                                      tekton-dashboard:9097 (10.244.0.95:9097)
Annotations:                         nginx.ingress.kubernetes.io/auth-signin: http://auth.127.0.0.1.nip.io/oauth2/sign_in?rd=http://\$host\$request_uri
                                   nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.tools.svc.cluster.local/oauth2/auth
Events:
Type    Reason  Age                From                      Message
----    ------  ----               ----                      -------
Normal  Sync    11m (x2 over 12m)  nginx-ingress-controller  Scheduled for sync

 kubectl describe ingress -n tools
Name:             oauth2-proxy
Labels:           app=oauth2-proxy
                  app.kubernetes.io/component=authentication-proxy
                  app.kubernetes.io/instance=oauth2-proxy
                  app.kubernetes.io/managed-by=Helm
                  app.kubernetes.io/name=oauth2-proxy
                  app.kubernetes.io/part-of=oauth2-proxy
                  app.kubernetes.io/version=7.2.1
                  helm.sh/chart=oauth2-proxy-6.2.1
Namespace:        tools
Address:          localhost
Ingress Class:    <none>
Default backend:  <default>
Rules:
  Host                   Path  Backends
  ----                   ----  --------
  auth.127.0.0.1.nip.io
                         /   oauth2-proxy:80 (10.244.0.100:4180)
Annotations:             meta.helm.sh/release-name: oauth2-proxy
                         meta.helm.sh/release-namespace: tools
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    18m (x2 over 18m)  nginx-ingress-controller  Scheduled for sync

Hi @tppalani, can you share some more information about your issue?

As per the documentation i have configured all yaml files inclusing helm provider.

Which documentation are you referring to? Can you provide a link please?

Are you following the walk-through? https://github.com/tektoncd/dashboard/blob/main/docs/walkthrough/walkthrough-oauth2-proxy.md

If so, I just followed it from start to finish, creating a clean kind cluster as described, and it worked as expected.

Can you reproduce your issue using kind or minikube or similar?

not able to see the any UI page from the browser

Have you verified the Dashboard is installed and running correctly by accessing it via one of the other methods described in the documentation? i.e. kubectl port-forward or kubectl proxy, see the docs for details: https://github.com/tektoncd/dashboard/blob/main/docs/install.md#accessing-the-dashboard

Do you get an error in the browser or just a completely blank page? Is there anything in the browser dev tools such as a console error or a network error that might explain the issue?

When i'm seeing ingress and pod all are up and running

Have you checked the logs for the ingress controller and any other pods that might be involved?

HI @AlanGreene

Thanks for the quick response.

  1. Document followed https://github.com/tektoncd/dashboard/blob/main/docs/walkthrough/walkthrough-oauth2-proxy.md
  2. kind cluster is up and running.
  3. Tekton Dashboard running as ingress able to access using localhost address.

Before going to install OAuth, i have tested with tekton Dashboard alone, here the status of ingress.

$ kubectl describe ingress -A
Name:             tekton-dashboard
Labels:           <none>
Namespace:        tekton-pipelines
Address:          localhost
Ingress Class:    <none>
Default backend:  <default>
Rules:
  Host                               Path  Backends
  ----                               ----  --------
  tekton-dashboard.127.0.0.1.nip.io
                                        tekton-dashboard:9097 (10.20.0.17:9097)
Annotations:                         <none>
Events:
  Type    Reason  Age                 From                      Message
  ----    ------  ----                ----                      -------
  Normal  Sync    75s (x2 over 108s)  nginx-ingress-controller  Scheduled for sync
http://tekton-dashboard.127.0.0.1.nip.io/#/about
  1. Step 4, create a OAuth App on your GitHub account
  2. captured client id and secret from the step 4 and i run the values.yaml file
helm upgrade --install --wait --create-namespace --namespace tools oauth2-proxy oauth2-proxy/oauth2-proxy --version 6.2.1 --values values.yaml
Release "oauth2-proxy" has been upgraded. Happy Helming!
NAME: oauth2-proxy
LAST DEPLOYED: Mon Aug 14 23:02:11 2023
NAMESPACE: tools
STATUS: deployed
REVISION: 5
TEST SUITE: None
NOTES:
To verify that oauth2-proxy has started, run:

  kubectl --namespace=tools get pods -l "app=oauth2-proxy"
NAME                            READY   STATUS    RESTARTS   AGE
oauth2-proxy-75cd548bf4-8c7hj   1/1     Running   0          8h
  1. Setting up Dashboard Ingress rule for authentication
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
  annotations:
    nginx.ingress.kubernetes.io/auth-url: "http://oauth2-proxy.tools.svc.cluster.local/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "http://auth.127.0.0.1.nip.io/oauth2/sign_in?rd=http://\$host\$request_uri"
spec:
  rules:
  - host: tekton-dashboard.127.0.0.1.nip.io
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

After applying annotation to ingress yaml file not able to access tekton-dashboard

$ kubectl describe ingress -A
Name:             tekton-dashboard
Labels:           <none>
Namespace:        tekton-pipelines
Address:          localhost
Ingress Class:    <none>
Default backend:  <default>
Rules:
  Host                               Path  Backends
  ----                               ----  --------
  tekton-dashboard.127.0.0.1.nip.io
                                        tekton-dashboard:9097 (10.20.0.17:9097)
Annotations:                         nginx.ingress.kubernetes.io/auth-signin: http://auth.127.0.0.1.nip.io/oauth2/sign_in?rd=http://\$host\$request_uri
                                     nginx.ingress.kubernetes.io/auth-url: http://oauth2-proxy.tools.svc.cluster.local/oauth2/auth
Events:
  Type    Reason  Age                  From                      Message
  ----    ------  ----                 ----                      -------
  Normal  Sync    6m23s (x3 over 19m)  nginx-ingress-controller  Scheduled for sync

Browser Error message

This site can’t be reachedtekton-dashboard.127.0.0.1.nip.i0’s server IP address could not be found.

Hi @AlanGreene

Can you please help me, after this POC we are going to implement same thing EKS cluster.

HI @AlanGreene

Here the Observation,

  1. Able to access tekton dashboard using (https and http) http://tekton-dashboard.127.0.0.1.nip.io/#/about
  2. After installing Dashboard logout URL, i can able to logout from Tekton Dashboard UI page
  3. When i'm clicking logout button from Tekton Dashboard its going back to http://auth.127.0.0.1.nip.io/ (OAuth2 proxy) I hope this is normal behaviour.
  4. When i'm clicking sign-in using http://auth.127.0.0.1.nip.io/ getting error (404 page not found)

image

I'm not sure if this is just a typo or if you copy/pasted the actual error message:

This site can’t be reachedtekton-dashboard.127.0.0.1.nip.i0’s server IP address could not be found.

It says nip.i0 but it should be nip.io

Removing the bug label since it's not a bug with the Dashboard itself as you mentioned the Dashboard is working.

@AlanGreene

Its typo only just ignore it (nip.i0)

Still i have one question, After logout from tetkon dashboard landing into http://auth.127.0.0.1.nip.io/ but when i'm clicking sign in with github button I'm getting error, can you please help me out on this.

http://auth.127.0.0.1.nip.io/
404 page not found

image

image

OK so the initial login is successful and redirects to the Dashboard as expected?
After you logout, and click on the sign in button again from the resulting page you get a 404?

If so, that's expected and is the default behaviour for the oauth proxy. Since you've just started the login process from auth.127.0.0.1.nip.io it doesn't know that you want to go to the Dashboard. By default you always need to start the login process from the Dashboard URL, tekton-dashboard.127.0.0.1.nip.io, so that the oauth proxy knows where to send you on successful login.

If you want to redirect somewhere else after logout you might be able to use the param described in https://oauth2-proxy.github.io/oauth2-proxy/docs/features/endpoints#sign-out although that's not its intended purpose. I'm not sure if oauth2-proxy allows for customisation of the logout URL otherwise.

tekton-dashboard.127.0.0.1.nip.io

You mean user always should use address to login tekton dashboard http://tekton-dashboard.127.0.0.1.nip.io/#/about, when we click logout it will re-direct to http://auth.127.0.0.1.nip.io/ page.

When the new user trying to login first time they need use http://auth.127.0.0.1.nip.io/oauth2/sign_in?rd=http://\tekton-dashboard.127.0.0.1.nip.io\/#/about, so that it will ask authentication ?

Users should always visit a URL on the tekton-dashboard.127.0.0.1.nip.io domain to access the Dashboard, regardless of whether they're currently logged in or not.

If they're already authenticated they will get access to the Dashboard, if they're not authenticated the oauth2-proxy will redirect them to login first and redirect them back to the Dashboard on success.

Users should not be manually visiting auth.127.0.0.1.nip.io directly, they should only see this as part of the login / logout process.

Once logged out, they will need to access tekton-dashboard.127.0.0.1.nip.io again to login / access the Dashboard again.

@AlanGreene,

May be this my last question, we have already running tekton in test environment we need use same method oauth2 proxy configuration so far our team accessing the tekton page using default ALB ingress controller url which provided AWS lets say http://default-aws-proivder-internal-url.

Now the question what the process to secure the tekton, what parameter we need pass inside the ingress.
Can you please help what kind of annotations we need add?

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tekton-dashboard
 annotations:
    alb.ingress.kubernetes.io/scheme: internal
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: http://default-aws-proivder-internal-url
    http:
      paths:
      - pathType: ImplementationSpecific
        backend:
          service:
            name: tekton-dashboard
            port:
              number: 9097

The configuration depends on your ingress controller and possibly your ALB so you would need to reference their documentation for the correct annotations or other config that's required.

If you have an existing auth setup for other apps already in place it may be better to work with the people who own or configure that rather than setting up your own oauth2-proxy just for the Dashboard.

The Dashboard OAuth2 Proxy walk-through is provided as an example of the general concepts and flow, and how to integrate this with the Dashboard application (i.e. the logout functionality). It is not intended to be a comprehensive guide to setting up auth in production environments. If you're using different tools you'll need to adapt the steps and configuration to suit.

The configuration depends on your ingress controller and possibly your ALB so you would need to reference their documentation for the correct annotations or other config that's required.

If you have an existing auth setup for other apps already in place it may be better to work with the people who own or configure that rather than setting up your own oauth2-proxy just for the Dashboard.

The Dashboard OAuth2 Proxy walk-through is provided as an example of the general concepts and flow, and how to integrate this with the Dashboard application (i.e. the logout functionality). It is not intended to be a comprehensive guide to setting up auth in production environments. If you're using different tools you'll need to adapt the steps and configuration to suit.

Thanks for your support and help, you can resolve the ticket now.