Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespaces list does not work after update to 7.9.0 #9591

Closed
vittoriocanilli opened this issue Oct 24, 2024 · 7 comments · Fixed by #9599
Closed

Namespaces list does not work after update to 7.9.0 #9591

vittoriocanilli opened this issue Oct 24, 2024 · 7 comments · Fixed by #9599
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.

Comments

@vittoriocanilli
Copy link

What happened?

After updating the Helm chart from 7.8.0 to 7.9.0 the namespaces lists on the upper left corner does not show all namespaces for authenticated user as happened before. It should be granted by this cluster role:

---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: oidc-list-all-namespaces
rules:
  - apiGroups: [""]
    resources: ["namespaces"]
    verbs: ["get", "list", "watch"]

and this cluster role binding:

---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: oidc-authenticated-user-list-all-namespaces
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: oidc-list-all-namespaces
  apiGroup: rbac.authorization.k8s.io

The namespaces are shown at the first load, but after a page refresh or a selection of a namespace, the list only shows the default namespace.
The namespaces can only be accessed via URLs like: https://dashboard.cluster.company.com/workloads?namespace=my-namespace

What did you expect to happen?

I expect that all namespaces are shown and the authenticated users can scroll the list and then only be able to access the namespaces' resources, as they are granted by other roles and role bindings.

Users with admin cluster roles (all API groups, all resources, all verbs are allowed) are not affected by the issue and they can still scroll the namespaces list as before.

How can we reproduce it (as minimally and precisely as possible)?

Here I am sharing the values that I am overwriting:

app:
  annotations:
    kubectl.kubernetes.io/default-container: kubernetes-dashboard
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
  priorityClassName: "system-cluster-critical"
  security:
    networkPolicy:
      enabled: true
  ingress:
    enabled: true
    ingressClassName: nginx
    issuer:
      name: letsencrypt-production
      scope: cluster
    tls:
      secretName: le-kubernetes-dashboard-tls
    annotations:
      nginx.ingress.kubernetes.io/proxy-buffer-size: 32k
  settings:
    global:
      clusterName: "cluster.company.com"
      itemsPerPage: 50
      labelsLimit: 10
      logsAutoRefreshTimeInterval: 1
      resourceAutoRefreshTimeInterval: 0
      disableAccessDeniedNotifications: false
      defaultNamespace: "kube-infrastructure"
      namespaceFallbackList: []
    pinnedResources:
      - kind: customresourcedefinition
        name: certificates.cert-manager.io
        displayName: "Certificates"
        namespaced: true
      - kind: customresourcedefinition
        name: certificaterequests.cert-manager.io
        displayName: "Certificate Requests"
        namespaced: true
      - kind: customresourcedefinition
        name: challenges.acme.cert-manager.io
        displayName: "Challenges"
        namespaced: true
      - kind: customresourcedefinition
        name: orders.acme.cert-manager.io
        displayName: "Orders"
        namespaced: true
      - kind: customresourcedefinition
        name: helmreleases.helm.toolkit.fluxcd.io
        displayName: "Helm Releases"
        namespaced: true
      - kind: customresourcedefinition
        name: secretproviderclasses.secrets-store.csi.x-k8s.io
        displayName: "Secret Provider Classes"
        namespaced: true
auth:
  nodeSelector:
    node-selector-key: system
api:
  nodeSelector:
    node-selector-key: system
  containers:
    args:
      - --v=0 # number for the log level verbosity (default 1)
      - --sidecar-host=http://kubernetes-dashboard-metrics-scraper.kube-infrastructure:8000 # memory and cpu are not shown without this
web:
  nodeSelector:
    node-selector-key: system
metricsScraper:
  nodeSelector:
    node-selector-key: system
  enabled: true
  containers:
    args:
      - --v=0 # number for the log level verbosity
      - --metric-duration=30m0s
metrics-server:
  enabled: false
kong:
  env:
    nginx_http_large_client_header_buffers: "8 24k"
  tolerations:
    - key: CriticalAddonsOnly
      operator: Exists
  nodeSelector:
    node-selector-key: system
cert-manager:
  enabled: false
nginx:
  enabled: false

Additionally I am overwriting resources (requests and limits) and the annotations and hosts of app.ingress, but they should not matter, I think.
As you can see I am overwriting both defaultNamespace and namespaceFallbackList, but it looks like the default values are taken instead.

Anything else we need to know?

The only way I have found to have the 7.9.0 Helm chart working fine is by overwriting the tag of the API component with the one used by 7.8.0 as follows:

api:
  image:
    tag: 1.9.0
  nodeSelector:
    node-selector-key: system
  containers:
    args:
      - --v=0 # number for the log level verbosity (default 1)
      - --sidecar-host=http://kubernetes-dashboard-metrics-scraper.kube-infrastructure:8000 # memory and cpu are not shown without this

So I think that the problem could be in the API component.

What browsers are you seeing the problem on?

Chrome

Kubernetes Dashboard version

7.9.0

Kubernetes version

1.29.5

Dev environment

No response

@vittoriocanilli vittoriocanilli added the kind/bug Categorizes issue or PR as related to a bug. label Oct 24, 2024
@floreks
Copy link
Member

floreks commented Oct 24, 2024

I will try to reproduce that. For the time being you can also set cache-enabled flag on the api container to false.

@vittoriocanilli
Copy link
Author

The workaround with the --cache-enabled=false flag on the API let the namespaces drop down menu works correctly again. So it must be something related to the cache. I look forward to new insights from you.

@floreks
Copy link
Member

floreks commented Oct 25, 2024

I suspect it's just a frontend glitch where we do not have a proper loading state for the initial namespace list call. Possibly if you try to reload the page and namespaces will already be cached it will work. I will check that.

@vittoriocanilli
Copy link
Author

Actually it works the other way around when I enable the cache again:

  1. I open the page and I can see the dropdown menu showing the kube-infrastructure namespace, that is the default one
  2. I click on the dropdown menu and I briefly see all namespaces
  3. the namespaces quickly disappear and I can only see the default one in the list
  4. I refresh the page and the same happens as described from step 1 to step 3
  5. by following page refreshes I simple see the default namespace in the dropdown menu

I hope it helps.

@floreks floreks added the priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now. label Oct 27, 2024
@floreks floreks self-assigned this Oct 27, 2024
@vittoriocanilli
Copy link
Author

@floreks I have seen that you have released new versions for 3 components and if I use them with the 7.9.0 Helm version as follows:

auth:
  image:
    tag: 1.2.2
api:
  image:
    tag: 1.10.1
web:
  image:
    tag: 1.5.2

the dropdown menu shows all namespaces correctly. Are you going to release a new version of the Helm chart that uses these tags any time soon? Thanks in advance

@floreks
Copy link
Member

floreks commented Oct 29, 2024

Ye, we will do the release this week. I just wanted to squish some other things into the release before we do it.

@vittoriocanilli
Copy link
Author

Cool, thank you! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. priority/critical-urgent Highest priority. Must be actively worked on as someone's top priority right now.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants