Apiext pod Azure policies non compliant

[BChancusi]

When installing Emissary on AKS with the AKS related polcies enabled, including the Azure provided policy initative "Kubernetes cluster pod security restricted standards for Linux-based workloads", pods are non-compliant:

emissary-system/emissary-apiext pod:

• Kubernetes cluster pods and containers should only run with approved user and group IDs
• Kubernetes clusters should not allow container privilege escalation
• Kubernetes cluster containers should run with a read only root file system
• Kubernetes cluster containers should only use allowed seccomp profiles
• Kubernetes clusters should disable automounting API credentials

emissary/emissary-ingress pod:

• Kubernetes clusters should disable automounting API credentials

The apiext pod should possibly have the same default security context as the main ingress pod when installed through helm. E.g. "runAsUser:8888" etc.

Credentials auto mount should be resolvable by specifying our own service account and volume through helm param but yet to try.

To Reproduce Steps to reproduce the behavior:

1. Enable the Azure AKS initiative and policies listed above. (Can be set to audit rather then deny pod creation for ease of debugging)
2. Ensure polcies are enabled on the AKS, e.g by checking contrainst template "kubectl get constraintemplates"
3. Install Emissary
4. Trigger a policy scan on Azure, e.g. through azure "az" cli
5. See non compliant pods in the azure portal policies page.

Versions:

• Emissary: Tested on 3.3.0 and 3.5.1
• AKS: 1.25

[cindymullins-dw]

Thanks, @BChancusi for raising these issues. Wonder if you have interest in contributing to any of the issues mentioned? We do have a monthly contributor's meeting you're welcome to join even if just to discuss.

[carlin-q-scott]

I was looking into the k8s API token security finding myself and wondering if both containers needed access to the k8s API, or if maybe only the emissary-apiext container does. Does anyone know?