Hi,
Starting today both me and a colleague are seeing app armor denied messages for cri-containerd which I believe is used within the MicroK8s Snap. The denials look like the below,
audit: type=1400 audit(1753175951.207:157044): apparmor="DENIED" operation="create" class="net" profile="cri-containerd.apparmor.d" pid=32906 comm="hostpath-provis" family="inet" sock_type="stream" protocol=0 requested="create" denied="create"
I previously had a running Juju controller in MicroK8s that is now in a crash-loop with the error cannot run daemon: when trying to listen on /var/lib/pebble/default/.pebble.socket: listen unix /var/lib/pebble/default/.pebble.socket: socket: permission denied. I’m also seeing similar errors in other pods with socket: permission denied.
Trying to bootstrap a new Juju controller in K8s is also hanging.
Creating a regular Ubuntu pod with microk8s kubectl apply works fine, so I suspect the issue is with any pods that use statefulsets that in turn use the hostpath-provisioner which keeps getting denied.
Looking at the offending process
ps aux | grep 32906
root 32906 0.0 0.0 1265560 9536 ? Ssl Jul21 0:17 /hostpath-provisioner
I was able to find the binary inside the MicroK8s snap,
$ sudo find / -type f -name hostpath-provisioner 2>/dev/null
/var/snap/microk8s/common/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/44/fs/hostpath-provisioner
Would appreciate any help in determining what has suddenly gone wrong.
Microk8s info:
$ snap info microk8s
tracking: 1.32-strict/stable
refresh-date: 7 days ago, at 14:19 SAST
Snapd info:
$ snap info snapd
tracking: latest/stable
refresh-date: 13 days ago, at 16:36 SAST