I'm currently setting up a Kubeflow environment in Azure using AKS. Everything is set up and working (users are able to log into the kubeflow platform using Azure AZ credentials and start notebook pods in their own namespace). I'm assuming these AD credentials are embedded somewhere in the container creation process, and I'm wondering if it's possible to tap into these credentials for other services that are AD integrated?
Use case:
A user is working in a Jupyter notebook started from the Kubeflow platform. The user wishes to access data in an Azure storage blob. Instead of having to login to Azure from their notebook session, the container already has their credentials stored.
It sounds reasonable but I'm unsure if it can actually be done in a secure way.
Assuming you're following the instructions in Authentication using OIDC in Azure: no, this isn't possible using the default configuration.
The way OIDC works is by giving back a token with a given audience (who it should be used with) and grants (what it says you should be able to do). The token that's being issued to Kubeflow is valid for the Kubeflow service principal audience only; in other words, you can't then take that same token and use it with Azure APIs. This is by design, and is one of the key factors in OIDC security. Allowing Kubeflow to have the permissions to issue more tokens (typically via the user_impersonation grant) opens a fairly major security issue - now anyone who manages to compromise that application secret can get powerful tokens, instead of limited scope tokens as normally designed.
If the resources they need to access aren't specific to the users in question, aad-pod-identity could be used to grant an access token to the pods the users are running instead of requiring them to log in again.