You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was deploying on Kubernetes a self hosted instance using the helm chart 1.4.0 and the image v0.102.0-postgres using integrated Redis but external Postgres.
I tested multiple times my Postgres URI and it works with psql so I know my URI is good.
I used kubectl exec -- env on the schema migration pod before it got to error and my secrets were put in env properly.
When doing pod logs, the error said bad URI.
I was wondering what I was doing wrong until I saw that I used the character # in the password of the URI.
Therefore I can tell that at some point there might be some shell interpretation somewhere after reading the env var making the # be considered as a comment.
I tried putting the secret between quotes with the same effect.
I don't have the exact pod logs output anymore, as I finally deployed using a password without this special character.
Should work if that's the database credentials or at least document how vars must be escaped.
Additional context
I wonder if there wouldn't be a way to exploit such a thing security wise
The text was updated successfully, but these errors were encountered:
naguam
changed the title
DB_CONNECTION_URI and special characters in password.
K8S helm standalone infisical-secrets DB_CONNECTION_URI and special characters in password.
Jan 15, 2025
naguam
changed the title
K8S helm standalone infisical-secrets DB_CONNECTION_URI and special characters in password.
K8s helm standalone infisical-secrets DB_CONNECTION_URI and special characters in password.
Jan 15, 2025
Describe the bug
Hi,
I was deploying on Kubernetes a self hosted instance using the helm chart 1.4.0 and the image v0.102.0-postgres using integrated Redis but external Postgres.
I tested multiple times my Postgres URI and it works with
psql
so I know my URI is good.I used
kubectl exec -- env
on the schema migration pod before it got to error and my secrets were put in env properly.When doing pod logs, the error said bad URI.
I was wondering what I was doing wrong until I saw that I used the character # in the password of the URI.
Therefore I can tell that at some point there might be some shell interpretation somewhere after reading the env var making the # be considered as a comment.
I tried putting the secret between quotes with the same effect.
I don't have the exact pod logs output anymore, as I finally deployed using a password without this special character.
But I think this is something to be investigated.
To Reproduce
Secret infisical-secrets with:
Expected behavior
Should work if that's the database credentials or at least document how vars must be escaped.
Additional context
I wonder if there wouldn't be a way to exploit such a thing security wise
The text was updated successfully, but these errors were encountered: