Search code examples
kubernetesazure-devopspermissionskubectlazure-aks

Permission denied while reading file as root in Azure AKS container


I have AKS cluster deployed(version 1.19) on Azure, part of the deployment in kube-system namespace there are 2 azure-cni-networkmonitor pods, when opening a bash in one of the pods using:

kubectl exec -t -i -n kube-system azure-cni-networkmonitor-th6pv -- bash

I've noticed that although I'm running as root in the container:

uid=0(root) gid=0(root) groups=0(root)

There are some files that I can't open for reading, read commands are resulting in permission denied error, for example:

cat: /run/containerd/io.containerd.runtime.v1.linux/k8s.io/c3bd2dfc2ad242e1a706eb3f42be67710630d314cfeb4b96ec35f35869264830/rootfs/sys/module/zswap/uevent: Permission denied

File stat:

Access: (0200/--w-------)  Uid: (    0/    root)   Gid: (    0/   root)

Linux distribution running on container:

Common Base Linux Delridge

Although the file is non-readable, I shouldn't have a problem to read it as root right?
Any idea why would this happen? I don't see there any SELinux enabled.


Solution

  • /proc and /sys are special filesystems created and maintained by the kernel to provide interfaces into settings and events in the system. The uevent files are used to access information about the devices or send events.

    If a given subsystem implements functionality to expose information via that interface, you can cat the file:

    [root@home sys]# cat /sys/devices/system/cpu/cpu0/uevent
    DRIVER=processor
    MODALIAS=cpu:type:x86,ven0000fam0006mod003F:feature:,0000,0001,0002,0003,0004,0005,0006,0007,0008,0009,000B,000C,000D,000E,000F,0010,0011,0013,0017,0018,0019,001A,001B,001C,002B,0034,003A,003B,003D,0068,006F,0070,0072,0074,0075,0076,0079,0080,0081,0089,008C,008D,0091,0093,0094,0096,0097,0099,009A,009B,009C,009D,009E,009F,00C0,00C5,00E7,00EB,00EC,00F0,00F1,00F3,00F5,00F6,00F9,00FA,00FB,00FD,00FF,0120,0123,0125,0127,0128,0129,012A,012D,0140,0165,024A,025A,025B,025C,025D,025F
    

    But if that subsystem doesn't expose that interface, you just get permission denied - even root can't call kernel code that's not there.