Mutation: Cannot reference ports in a pod

[maxsmythe]

What steps did you take and what happened:

Ports in pods have an integer-type keyfield. Because our location spec assume stings, we cannot match against this, and wind up creating a duplicate port.

Repro steps:

take the following mutator:

apiVersion: mutations.gatekeeper.sh/v1alpha1
kind: Assign
metadata:
  name: set-port-name
spec:
  applyTo:
  - groups: [""]
    kinds: ["Pod"]
    versions: ["v1"]
  location: 'spec.containers[name: opa].ports[containerPort: "8888"].name'
  parameters:
    assign:
      value: "modified"

and create the following object:

apiVersion: v1
kind: Pod
metadata:
  name: opa
  namespace: production
  labels:
    owner: me.agilebank.demo
spec:
  containers:
    - name: opa
      image: openpolicyagent/opa:0.9.2
      args:
        - "run"
        - "--server"
        - "--addr=localhost:8080"
      resources:
        limits:
          cpu: "100m"
          memory: "30Mi"
      ports:
        - containerPort: 8888
          name: unchanged

We get the following error:

Error from server (InternalError): error when creating "opa.yaml": Internal error occurred: v1.Pod.Spec: v1.PodSpec.Containers: []v1.Container: v1.Container.Ports: []v1.ContainerPort: v1.ContainerPort.ContainerPort: readUint32: unexpected character: �, error found in #10 byte of ...|nerPort":"8888","nam|..., bigger context ...|nerPort":8888,"protocol":"TCP"},{"containerPort":"8888","name":"modified"}],"resources":{"limits":{"|...

Which has two issues:

• We are attempting to create a field of the wrong type
• We are writing out two ports instead of modifying the existing port

What did you expect to happen:

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

Environment:

• Gatekeeper version:
• Kubernetes version: (use kubectl version):

[shomron]

@maxsmythe for the first issue, we can consider adding numeric token support to our parser and exposing this to the matching logic. Specifically this is about numeric support in List nodes' KeyValue - I think reworking that to be interface{} will fit in with how we are utilizing it in mutatorState - are there other places this would be relevant?

Regarding the second issue seems closely related, I see assumptions around string types in setListElementToValue and createMissingElement.

[maxsmythe]

The only other thing we use location for is to build the implicit schema. We haven't been using the type of keyValue there for anything. I think we can continue to ignore it.

One thing that's interesting is whether we can use integers to identify the field of a resource (e.g. spec.1234.hello). Maybe we just disallow numeric types there to avoid opening that kettle-o-fish unless we have to?

[shomron]

One thing that's interesting is whether we can use integers to identify the field of a resource (e.g. spec.1234.hello). Maybe we just disallow numeric types there to avoid opening that kettle-o-fish unless we have to?

I've made it so that non-quoted identifiers can no longer start with a number - let me know what you think!

[maxsmythe]

I'm liking it!