Unable to patch initContainer onto inject-policy for OPA Envoy sidecar container

[bvamshidhar]

I'm trying to add an initContainer add it to the spec using patch operation in the inject-policy.yaml. I'm adding this initContainer to fetch the data of the other 2 configmaps opa-isito-config and opa-policy from a files stored in a dir /config.

For example: opa-istio-config.yaml contains
plugins:
envoy_ext_authz_grpc:
addr: :9191
path: istio/authz/allow
decision_logs:
console: true

The main purpose of this is to to deploy these two configmaps in opa-istio namespace instead of default namespace.

patch = [{
"op": "add",
"path": "/spec/initContainers/-",
"value": init_container,
}, {
"op": "add",
"path": "/spec/containers/-",
"value": opa_container,
}, {
"op": "add",
"path": "/spec/volumes/-",
"value": new_volumes,
}]

init_container = {
  "name": "config-fetch"
  "image": "busybox"
  "command": [
    "wget",
    "-P",
    "/config-dir",
    "https://config/opa-istio-config.yaml";,
    "https://config/policy.rego";,
  ],
  "volumeMounts":[{
    "name": "configdir",
    "mountPath": "/config-dir",
  }]
}

opa_container{
...
}

# I removed the individual volumes for the configmap and added a new one
new_volumes {
 ...
}

While adding the initContainer, I get an error:
Error creating: Internal error occurred: add operation does not apply: doc is missing path: "/spec/initContainers/-": missing value

Can you please help me on this issue?
Thank you.

[charlieegan3]

I think you will need to patch the spec taking into account any existing init containers and including them in the patch if there are any set.

[charlieegan3]

So you have some of the policy being loaded from cloud storage, and some loaded from a config map?

[bvamshidhar]

Yes, I'm trying to load the opa-isito-config and opa-policy from cloud so as to remove both the files from the default namespace. I left the inject-policy configmap as is.

[charlieegan3]

Right I see, and just so that I understand, is this because they're different in different environments? Or for some other reason? It seems like it would be easier to load them from configmaps.

[bvamshidhar]

If they are in a different namspace, I need to deploy them once in every namespace. I have multiple namespaces. I would be easier to deploy and maintain, if all files could be in one namespace.

[charlieegan3]

Perhaps something like https://github.com/mittwald/kubernetes-replicator would be easier?

OPA is designed to load policy from http endpoints when policy is bundled, rather than plain files. You can also use the Discovery API to load in config for the OPA itself from a remote bundle. That might be something to consider too.