All env variables are required in anyNotIn rule

[kravciak]

Based on https://suse.slack.com/archives/C02DBSK7HC1/p1732694471848839

Kubewarden Enivronment variables Policy

Background

According to the example in environment-variable-policy doc.

In the following example, only resources that have the envvar3 or envvar2 defined will be allowed:

settings:
  rules:
    - reject: anyNotIn
      environmentVariables:
        - name: "envvar2"
          value: "envvar2_value"
        - name: "envvar3"

However, I observed different results in my experiment. It seems both envvar3 and envvar2 are required for access to be allowed.

Resource	Result
Resource 1 uses envvar2 and envvar3	accepted ✔️
Resource 2 uses envvar2	rejected ❌
Resource 3 uses envvar3	rejected ❌

Policy and Resources

Kubewarden Policy using anyNotIn

neuvector@ubuntu2204-F:~/kubewarden/test_env$ kubectl get cap
NAME   POLICY SERVER   MUTATING   BACKGROUNDAUDIT   MODE      OBSERVED MODE   STATUS   AGE
env1   default         false      true              protect   protect         active   8m18s

neuvector@ubuntu2204-F:~/kubewarden/test_env$ kubectl get cap env1 -oyaml
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
  ....
spec:
  backgroundAudit: true
  mode: protect
  module: ghcr.io/kubewarden/policies/environment-variable-policy:v0.1.7
  mutating: false
  policyServer: default
  rules:
     ...
  settings:
    rules:
    - environmentVariables:
      - name: envvar2
        value: envvar2_value
      - name: envvar3
      reject: anyNotIn
  timeoutSeconds: 10

The following are the resources and their execution results:

Resource 1 uses both `envvar2` and `envvar3` environment variables, and its evaluation result is allowed.

# resource using both envvar2 and envvar3
neuvector@ubuntu2204-F:~/kubewarden/test_env$ cat 1_deploy-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
    ...
spec:
  template:
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: envvar2
          value: envvar2_value
        - name: envvar3
          value: aaaaaa
status: {}

# deploy -> allowed
neuvector@ubuntu2204-F:~/kubewarden/test_env$ kubectl apply -f 1_deploy-env.yaml
deployment.apps/my-dep created

Resource 2 uses only `envvar2` environment variable, and its evaluation result is denied.

# resource using envvar2
neuvector@ubuntu2204-F:~/kubewarden/test_env$ cat 1_deploy-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
    ...
spec:
  template:
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: envvar2
          value: envvar2_value
status: {}

# deploy -> denied
neuvector@ubuntu2204-F:~/kubewarden/test_env$ kubectl apply -f 1_deploy-env.yaml
Error from server: error when creating "1_deploy-env.yaml": admission webhook "clusterwide-env1.kubewarden.admission" denied the request: Resource should define at least one of the environment variables from the rule. Invalid environment variables found: envvar3

Resource 3 uses only `envvar3` environment variable, and its evaluation result is denied.

# resource using envvar3
neuvector@ubuntu2204-F:~/kubewarden/test_env$ cat 1_deploy-env.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
    ...
spec:
    ...
  template:
    spec:
      containers:
      - image: nginx
        name: nginx
        env:
        - name: envvar3
          value: envvar3_value
status: {}

# deploy -> denied
neuvector@ubuntu2204-F:~/kubewarden/test_env$ kubectl apply -f 1_deploy-env.yaml
Error from server: error when creating "1_deploy-env.yaml": admission webhook "clusterwide-env1.kubewarden.admission" denied the request: Resource should define at least one of the environment variables from the rule. Invalid environment variables found: envvar2

[jvanz]

I think the policy documentation is not clear enough and the example is wrong. Which caused confusion.

I believe the appropriated rule to be used in the given example is notAllAreUsed. Which the description is rejects if all of the environmentVariables are **missing** in the resource. But during my tests I've found a bug in the rule which I've fixed in #57.

[jvanz]

While I was working on this, I've discussed this issue with the team. Because of that we decided to refactor this policy. It's too much confusing now and need a good enhancement. Therefore, we open the #60 issue to address what we believe it's necessary.