We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hi, thanks for polaris, it's an awesome tool and it helps us a lot on many use cases.
We think we might have an special case that is a false positive.
We are using envFrom with secretRef and then using a bunch of variables for secrets (as described in https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables ) and using env to rename and combine some variables :
envFrom
secretRef
--- apiVersion: apps/v1 kind: Deployment [snip] spec: template: spec: containers: - name: airflow-scheduler [snip] envFrom: - secretRef: name: airflow-env [snip] env: - name: AIRFLOW_VAR_GITLAB_PRIVATE_TOKEN value: $(GITLAB_PRIVATE_TOKEN) - name: AIRFLOW_VAR_PROMETHEUS_PASSWORD value: $(PROMETHEUS_PASSWORD)
and polaris detects the following :
sensitiveContainerEnvVar ❌ Danger Security - The container sets potentially sensitive environment variables
Which doesn't seem to be the case when a syntax like the following is used :
[snip] env: - name: POSTGRES_PASSWORD valueFrom: secretKeyRef: name: postgres-airflow-secret key: POSTGRES_PASSWORD [snip]
For polaris to detect that a variable from a secret is being used and to consider this as safe.
If the snippet above is not sufficient to discuss this issue we can probably share a complete deployment/secret.
7.3.2
No response
The text was updated successfully, but these errors were encountered:
workaround is using the following annotation :
annotations: polaris.fairwinds.com/sensitiveContainerEnvVar-exempt: "true"
Sorry, something went wrong.
I am pretty sure you don't need to repeat env vars that are pulled in via envFrom in the env section of the spec.
Polaris is picking up the words TOKEN and SECRET I believe. We're fairly limited in what we can check with JSON Schema for this.
Your workaround is probably best, or to disable that check entirely in your configuration
No branches or pull requests
What happened?
Hi, thanks for polaris, it's an awesome tool and it helps us a lot on many use cases.
We think we might have an special case that is a false positive.
We are using
envFrom
withsecretRef
and then using a bunch of variables for secrets (as described in https://kubernetes.io/docs/tasks/inject-data-application/distribute-credentials-secure/#configure-all-key-value-pairs-in-a-secret-as-container-environment-variables ) and using env to rename and combine some variables :and polaris detects the following :
Which doesn't seem to be the case when a syntax like the following is used :
What did you expect to happen?
For polaris to detect that a variable from a secret is being used and to consider this as safe.
How can we reproduce this?
If the snippet above is not sufficient to discuss this issue we can probably share a complete deployment/secret.
Version
7.3.2
Search
Code of Conduct
Additional context
No response
The text was updated successfully, but these errors were encountered: