Add user details when login with OIDC

[marcocaberletti]

What would you like to be added?

Hi, I've done the following setup:

• Okta OIDC provider (IDP);
• AWS ALB with SSL termination;
• oauth2-proxy for authentication (Helm chart v7.4.1);
• Kubernetes dashboard with auth header (Helm chart v7.3.2).

The authentication flow works as expected: the IDP issues tokens with the groups claim, groups are mapped in aws-auth ConfigMap, I can login in the dashboard and operate.
The question is the following: if a user is member of multiple groups in the IDP, how can I see the user details? How can I understand to which group is mapped?

From the dashboard, the only thing I can see is the following:

Is it possible add some user details in the dropdown?

Thanks

Why is this needed?

Better visibility about the logged user

[floreks]

We can try to extract the user name from the token but that's it. We do it for the service account token. It would need to be some kind of standardized way though, either via commonly known claims or something else that is embedded inside the token. We definitely won't do that for anything custom.

https://github.com/kubernetes/dashboard/blob/master/modules/auth/pkg/routes/me/me.go

[marcocaberletti]

I guess name, email, iss and maybe groups are standard claims. I think they can be enough.

[psibi]

@floreks I see the same behavior with User impersonation. Pre 7.0.0 (https://github.com/kubernetes/dashboard/releases/tag/kubernetes-dashboard-7.0.0) version, this was not the case. Do you want me to open separate issue for it or track it as part of this ?

[floreks]

Respecting impersonation header username will be a part of this. It is indeed ignored right now.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[psibi]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Smuger]

@marcocaberletti

This isn't related to your issue but is there any chance you can share your ALB oauth2-proxy config?

I've been trying to set it up properly for few days now. I'm a bit lost on how to get the Auth header configured. All I'm getting from oauth2-proxy is the OAuth cookie

[marcocaberletti]

@Smuger the configuration is something like the following.

Kubernetes ingress:

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetes-dashboard
  namespace: admin
  annotations:
    <redacted>
spec:
  ingressClassName: alb
  rules:
  - host: <redacted>
    http:
      paths:
      - backend:
          service:
            name: oauth2-proxy
            port:
              number: 80
        path: /
        pathType: Prefix

oauth2-proxy relevant Helm values:

config:
  existingSecret: oauth2-secrets
  configFile: |-
    email_domains = [ "<redacted>" ]
    upstreams = [ "http://kubernetes-dashboard-kong-proxy/" ]
ingress:
  enabled: false
extraArgs:
  cookie-refresh: 15m
  email-domain: "<redacted>"
  oidc-issuer-url: <redacted>
  pass-access-token: "true"
  pass-authorization-header: "true"
  pass-host-header: "true"
  pass-user-headers: "true"
  provider-display-name: "Okta"
  provider: oidc
  reverse-proxy: "true"
  scope: "openid email profile groups"
  set-authorization-header: "true"
  set-xauthrequest: "true"
  silence-ping-logging: "true"
  skip-jwt-bearer-tokens: "true"
  skip-provider-button: "true"

I hope this can be helpful