Unauthenticated response in GetPackageRepositorySummaries

[tomaszstachRA]

Describe the bug I am using Dex (LDAP, redis) with PinnipedProxy. I can successfully login to kubeapps, do any actions with not involve using the Catalog. When I click on catalog it redirects me to the login page. The below logs are from kubeappapi container.

I1214 13:23:57.149140 1 server.go:466] "+helm GetInstalledPackageSummaries" cluster="default" namespace="" I1214 13:23:57.728953 1 server.go:62] OK 580.060076ms /kubeappsapis.core.packages.v1alpha1.PackagesService/GetInstalledPackageSummaries I1214 13:24:05.564226 1 repositories.go:116] "+core GetPackageRepositorySummaries" cluster="" namespace="" I1214 13:24:05.564274 1 server.go:1134] +helm GetPackageRepositorySummaries [context:{}] I1214 13:24:05.564684 1 repositories_resources.go:30] +helm getPkgRepositoryResource [&{0xc00011bd50 {kubeapps.com v1alpha1 apprepositories}}] I1214 13:24:05.667652 1 server.go:62] Unauthenticated 103.415029ms /kubeappsapis.core.packages.v1alpha1.RepositoriesService/GetPackageRepositorySummaries

To Reproduce Steps to reproduce the behavior:

1. Login to kubeapps using Dex and pinniped-proxy
2. Click on Catalog
3. See not expected behaviour

Expected behavior Catalog loading successfully

Desktop (please complete the following information):

• Kubeapps Chart Version - 14.1.0
• Kubernetes version - 1.26.6
• helm

Additional context Add any other context about the problem here.

[antgamdia]

Hi @tomaszstachRA, thanks for creating the issue. Just FTR, there is additional information on this public Slack thread.

I have just tested a brand new local environment with these values:

ingress:
  enabled: true
  hostname: localhost # set the hostname according to your needs
  tls: true
  selfSigned: true # as it is just for my local dev environment, I don't want to deal with certificates

authProxy:
  extraFlags:
    - --oidc-issuer-url=<my issuer>
  # If you are using a different ingress config, you might need to tweak these flags. More info in the "oauth2-proxy" official docs
  clientID: <my client id>
  clientSecret: <my client secret>
  cookieSecret: bm90LWdvb2Qtc2VjcmV0Cg==
  enabled: true
  provider: oidc

pinnipedProxy:
  enabled: true # if using Pinniped, you'll need to enable this option here

clusters:
  - name: default
    pinnipedConfig:
      enabled: true # if using Pinniped, you'll need to enable this option here

Plus a JWT authenticator:

apiVersion: authentication.concierge.pinniped.dev/v1alpha1
kind: JWTAuthenticator
metadata:
  name: jwt-authenticator
spec:
  audience: <my client id>
  claims:
    groups: groups
    username: email
  issuer: <my issuer>

Plus the proper RBAC, in this case, granting enough perms using the kubeapps-operator ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubeapps-operator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: <my email>

All the requests are being served seamlessly, so I'm currently unable to reproduce the issue. I'm not using Dex, but another OIDC provider (Auth0)... but all our CI pipelines are using Dex.

I assume there is something wrong with the RBAC configuration then. This guide might be helpful to debug OIDC issues: https://kubeapps.dev/docs/latest/reference/developer/pinniped-proxy/#troubleshooting

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.