Securing Oauth Env Variables to Avoid Prisma Scan Flags

Ashish G. · 2025-04-25T16:16:36.329Z

Heyyy guys, We've deployed the Arize phoenix in our AKS with Oauth We've created a kubernetes secret and put all the required variables in that and in the department yaml we're referring these secrets as env variables Now in PRISMA scan it was flagged that we're exposing secrets as plain text, is there any way to pass the Oauth env variables? So that PRISMA does not flag these?

Securing Oauth Env Variables to Avoid Prisma Scan Flags | Arize AI Community

10 comments

· Sorted by Oldest

Xander S.
·
Hi Ashish G., can you help me understand where exactly Prisma is flagging a security concern? It sounds like you have some kind of YAML file that stores the secrets in plain text, but I'm not clear why that is necessary if you have set up a Kubernetes secret.
Ashish G.
·
This is what we are doing
Create kubernetes secret and stores phoenix api key, phoenix oauth microsoft client id and so on...
In the phoenix deployment yaml use this secret to inject the above variables as env variable
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
Xander S.
·
Thanks Ashish G.. It would help to share the deployment YAML for reference
Ashish G.
·
++ 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
Xander S.
·
Hey Ashish G., at the moment, there is not another mechanism for setting secrets in Phoenix other than environment variables. In my understanding, using environment variables for this purpose is fairly standard. Can you help me under the exact security concern you are running into?
Ashish G.
·
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.
Xander S.
·
It sounds like the issue is with the use of environment variables themselves.
Xander S.
·
If we provided a way to pass a path to a volume-mounted dot env file instead, would that alleviate the concern?
Ashish G.
·
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
Ashish G.
·
Thank you so much!

Xander S.
·
Hi Ashish G., can you help me understand where exactly Prisma is flagging a security concern? It sounds like you have some kind of YAML file that stores the secrets in plain text, but I'm not clear why that is necessary if you have set up a Kubernetes secret.
Ashish G.
·
This is what we are doing
Create kubernetes secret and stores phoenix api key, phoenix oauth microsoft client id and so on...
In the phoenix deployment yaml use this secret to inject the above variables as env variable
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
Xander S.
·
Thanks Ashish G.. It would help to share the deployment YAML for reference
Ashish G.
·
++ 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
Xander S.
·
Hey Ashish G., at the moment, there is not another mechanism for setting secrets in Phoenix other than environment variables. In my understanding, using environment variables for this purpose is fairly standard. Can you help me under the exact security concern you are running into?
Ashish G.
·
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.
Xander S.
·
It sounds like the issue is with the use of environment variables themselves.
Xander S.
·
If we provided a way to pass a path to a volume-mounted dot env file instead, would that alleviate the concern?
Ashish G.
·
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
Ashish G.
·
Thank you so much!