Skip to content
New issue

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

[FEATURE_REQUEST] EnvVar ValueFrom checks #705

Open
josegomezr opened this issue Jan 29, 2024 · 0 comments
Open

[FEATURE_REQUEST] EnvVar ValueFrom checks #705

josegomezr opened this issue Jan 29, 2024 · 0 comments

Comments

@josegomezr
Copy link

Description of the problem/feature request

A check to detect containers referring to configmaps/secret keys that do not exist in the current release via valueFrom (v1.EnvVarSource)

Description of the existing behavior vs. expected behavior

In some of our workloads we have containers with environment variables defined as:

# [...] clipped for brevity
- name: AIRBRAKE_PROJECT_KEY
  valueFrom:
    secretKeyRef:
      name: secrets
      key: airbrake-project-key
# [...] clipped for brevity

But it has happened a couple of times that a typo in the key slips and we notice it at the very last moment when the helm release fails to complete.

Additional context

The minimum reproduceable manifest could be something like:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
  namespace: example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: example-container
        image: internal.container.registry/an-image:v1
        env:
          - name: MY_DANGLING_ENV
            valueFrom:
              secretKeyRef:
                name: existing-secret
                key: with-a-typo # <-- notice here
---
apiVersion: v1
kind: Secret
metadata:
  name: example-deployment
  namespace: example
type: Opaque
data:
  without-a-typo: "YmFzZTY0Li4uCg=="

And the output should indicate which deployment or the container (whatever is more comfy) is referring to an unknown secret/config-map.

Currently there's no output of this, I do have a draft in a fork I can contribute to. I'm missing some tests but it sort-of works (golang is not my native speak):

main...josegomezr:kube-linter:env_source_check

@josegomezr josegomezr changed the title [FEATURE_REQUEST] [FEATURE_REQUEST] EnvVar ValueFrom checks Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant