Unable to match on name

[stephen-sourced]

What steps did you take and what happened: [A clear and concise description of what the bug is.] Trying to use a constraint with match on name. Can't seem to match with generateName or Name of the pod/container

What did you expect to happen: Mutation to be applied manfiest.txt constraint.txt

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

• Gatekeeper version: 6aad7b6f49a6f0f16fbe4313ccfa1b5a251e94bb (Google Anthos Config Management version 1.15.3)
• Kubernetes version: (use kubectl version): v1.28.1

[acpana]

hey @stephen-sourced i think this may be fixed in https://github.com/open-policy-agent/gatekeeper/commit/6c38e80d899372509f7dd68e6b30d65681e54a07

@JaydipGabani fyi

[JaydipGabani]

@stephen-sourced Can you confirm if you have the expansion template feature enabled and if an appropriate expansion template is created for the mutation to be applied on pods created by deployment? For more details on the expansion template, please look here.

[stephen-sourced]

I've read through the expansion template docs and have applied the example but it doesn't seem to do anything. With or without the expansion template, the match on name doesn't work. When I remove the match for name and just filter on namespace the mutation does work, with and without the expansion template. `apiVersion: expansion.gatekeeper.sh/v1alpha1 kind: ExpansionTemplate metadata: name: expand-deployments spec: applyTo:

• groups: ["apps"] kinds: ["Deployment"] versions: ["v1"] templateSource: "spec.template" generatedGVK: kind: "Pod" group: "" version: "v1"`

I am using image: openpolicyagent/gatekeeper:v3.13.0-beta.1

[stephen-sourced]

I've tested on openpolicyagent/gatekeeper:v3.14.0-beta.0 and it is fixed. I am able to filter on name: without the expansion template

[JaydipGabani]

@stephen-sourced I tested the below with openpolicy/gatekeeper:3.13.0 and it worked.

mutation policy

apiVersion: mutations.gatekeeper.sh/v1
kind: Assign
metadata:
  name: allowedcapabilities-dynakube
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  location: "spec.containers[name:*].securityContext.capabilities.add"
  match:
    namespaces: 
    - "nginx"  
    name: nginx-*
  parameters:
    assign:
      value: # default add capability
      - CHOWN
      - DAC_OVERRIDE
      - DAC_READ_SEARCH
      - FOWNER
      - FSETID
      - KILL
      - NET_ADMIN
      - NET_RAW
      - SETFCAP
      - SETGID
      - SETUID
      - SYS_ADMIN
      - SYS_CHROOT
      - SYS_PTRACE
      - SYS_RESOURCE

creating pod with kubectl run nginx-b --image=nginx -n nginx, and pod gets mutated with appropriate capabilities

spec:
  containers:
    - image: nginx
      imagePullPolicy: Always
      name: nginx-b
      resources: {}
      securityContext:
        capabilities:
          add:
            - CHOWN
            - DAC_OVERRIDE
            - DAC_READ_SEARCH
            - FOWNER
            - FSETID
            - KILL
            - NET_ADMIN
            - NET_RAW
            - SETFCAP
            - SETGID
            - SETUID
            - SYS_ADMIN
            - SYS_CHROOT
            - SYS_PTRACE
            - SYS_RESOURCE

[stephen-sourced]

@JaydipGabani Have you tried a deployment, not just a pod?

[maxsmythe]

@stephen-sourced copy/pasting your mutator/source just to be sure we have the same thing.

Mutator:

apiVersion: mutations.gatekeeper.sh/v1
kind: Assign
metadata:
  name: allowedcapabilities-dynakube
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  location: "spec.containers[name:*].securityContext.capabilities.add"
  match:
    namespaces: 
    - "dynatrace-system"  
    name: dynakube-oneagent-*
  parameters:
    assign:
      value: # default add capability
      - CHOWN
      - DAC_OVERRIDE
      - DAC_READ_SEARCH
      - FOWNER
      - FSETID
      - KILL
      - NET_ADMIN
      - NET_RAW
      - SETFCAP
      - SETGID
      - SETUID
      - SYS_ADMIN
      - SYS_CHROOT
      - SYS_PTRACE
      - SYS_RESOURCE

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dynakube-oneagent
  labels:
    app.kubernetes.io/created-by: dynakube
    app.kubernetes.io/name: oneagent
    app: sleep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sleep
  template:
    metadata:
      labels:
        app: sleep
    spec:
      securityContext:
        fsGroup: 2000
      containers:
      - name: ubuntu
        image: ubuntu
        # Just spin & wait forever
        command: [ "/bin/sh", "-c", "--" ]
        args: [ "while true; do sleep 30; done;" ]
        securityContext:
          allowPrivilegeEscalation: true
          runAsUser: 1000

It looks like the mutator only matches against the "dynatrace-system" namespace, but the deployment has no namespace listed, so would be created in the "default" namespace. If you do one of:

1) Add metadata.namespace = dynatrace-system to the deployment 2) Remove the namespace matcher and/or change it to "default" in the mutator

Does it work?

[stephen-sourced]

I was using this to test in multiple namespaces so I was applying with

kubectl apply -f filename.yaml -n namespace

[maxsmythe]

Gotcha.

Looking back, it sounds like this was fixed by https://github.com/open-policy-agent/gatekeeper/commit/6c38e80d899372509f7dd68e6b30d65681e54a07 .

I wouldn't expect this mutator to work as-written on any object that uses generateName (such as pods created by deployments) in versions of Gatekeeper prior to the fix. It looks like you've been able to verify the mutator works post-fix.

I also would not expect expansion templates to help, as they are more about mocking out downstream results of a given request in order to fail fast (e.g. reject when a deployment would create an invalid pod). Expansion templates may be able to help paper over this issue with constraints, but not mutators. Also, I'd expect the expansion template solution to only work with generator resources (Deployments, StatefulSets, etc.), and not pods.

Given that the patched versions are working for you, do the above clarifications settle your questions?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.