I (still) don't work here anymore. This is their forum, if they want to reply they will.
• If you're a customer, you can ask your rep about adding this. But realistically TBH, they will either say no outright or it will never get prioritized into a release:
◦ It's not a small change
◦ Rancher/SUSE has no use for the information
◦ Most/all users have no use for it either
◦ For some providers it requires adding friction by asking the user for extra permissions
◦ It's PII, so country-specific compliance headache implications
• If you have/are a programmer, what I said before is roughly what you need on what to go do:
◦ Add a field in the principal and/or user type definition to hold it
◦ For each auth provider you want to support:
▪︎ Request extra permissions in the UI or backend to make it available, if needed. They're mostly all different. And in some of them there isn't even the concept of an email. I linked to exactly to where this is for GitHub above.
▪︎ Figure out how to get the email out of their API responses and/or make extra API calls to fetch it.
▪︎ Do that on login and/or identity fetch in the
provider
▪︎ (Though not really exposed much today, users can have multiple identities, which might be tied to unrelated emails, so it should really go on the identity, not the actual top-level user)
◦ Package all that up into your own release and run that
◦ Maintain a patch and release process to do this forever as new versions are shipped
• If you aren't and don't have a programmer, then your answer is email addresses are not captured. The information you want does not exist in Rancher, full stop.