Whenever an application tries to do anything beyond simple numeric computations, the application must make what is called a kernel call. Examples of kernel calls include everything from opening sockets to accessing files to checking the current system time. Under the hood, your application essentially makes a call to the operating systems’ kernel (usually the Linux Kernal) which then performs whatever action you have requested.
That is, it performs the kernel call IF your application has permissions to make such a call. The root user can, by definition, essentially perform any kernel call, but your applications have a limited set of kernel calls they are allowed to make.
By default, there may already be a limited set of syscalls available to your application (which are usually OK), but it is a good idea in highly secure environments to explicitly set them and/or use a tool like AppArmor to listen and build profiles for individual apps. This makes it so that even if an application is compromised, it has the least privileges required to run and the compromised application cannot do as much harm.
Configuring Manually in the Security Context
You can configure what linux capabilities each individual container is given when creating pods. This is less than ideal since it would be difficult to maintain on many pods, so AppArmor or Secomp profiles are preferred, but it bares mentioning since it helps you understand what AppArmor or Secomp profiles are doing under the hood.
Using AppArmor to limit Syscalls
To enable an App Armor profile for pod, all you have to do is add an annotation referencing the AppArmor profile that you want to bind to the pod:
Then, if that profile has been setup on server, it will bind the container(s) specified to the corresponding AppArmor profiles.
Note that before you can use AppArmor profiles, they will have to be registered in the server. You can do it manually through the command line, but most of the time you would register each of your AppArmor profiles as part of whatever automated pipeline/tools you are using to deploy your Kubernetes cluster so that you can ensure all nodes are setup the same way and all new nodes have your app armor profiles.
Using Secomp to limit Syscalls
Secomp works in much of the same principal as AppArmor and, for further clarification, I’ll refer you to the official kubernetes documentation.