Ashish G.

Thank you so much!

So that does make sense and I was also thinking along the same lines. I can provide rationale that even though I'm mentioning them in . env they just contain the path to those sensitive values, they don't contain the value itself

So what they're saying is for setting up SSO you're injecting service principal's client id, client secret and config url We explained that config url and client id are not that sensitive and they somehow agreed but they're not willing to budge for client secret So we're trying to figure out a way to use client secret without injecting as env variables Does it make sense? - Xander S.

++ Anthony P. / Mikyo Xander S. So, it might be difficult to share a deployment file But let me rephrase my question: Is there any alternative way to fetch this value Like instead of fetching from env variables maybe directly from key vault? https://github.com/Arize-ai/phoenix/blob/main/src%2Fphoenix%2Fconfig.py#L592

This is what we are doing

Now PRISMA is flagging that inside the arize phoenix container sensitive value like PHOENIX_SECRET, PHOENIX_OAUTH_MICROSOFT_CLIENT_ID is stored as plain text What the team is suggesting is to use key vault for fetching the secrets or create a secret manager class and mount it to the deployment and use paths to access variables I'll try to share the deployment yaml for reference

Thank you so much, will give it a try!!!

I tried to open the link but it redirects to a new workspace Is it shared internally with your team only?

Oh okayyy! A retention feature will definitely do the trick! Can you give me a little bit information on the graphql api part? Do you mean call the graphql API to do the cleanup?