FairwindsOps / polaris

Validation of best practices in your Kubernetes clusters
https://www.fairwinds.com/polaris
Apache License 2.0
3.14k stars 210 forks source link

sensitiveContainerEnvVar flags a danger when using envFrom/secretRef and key/value #1046

Closed arthurzenika closed 2 days ago

arthurzenika commented 2 months ago

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 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 :

---
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]

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

arthurzenika commented 2 months ago

workaround is using the following annotation :

  annotations:
    polaris.fairwinds.com/sensitiveContainerEnvVar-exempt: "true"
sudermanjr commented 2 months ago

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