{"id":627,"date":"2025-04-01T13:37:59","date_gmt":"2025-04-01T13:37:59","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=627"},"modified":"2025-04-01T13:37:59","modified_gmt":"2025-04-01T13:37:59","slug":"seccomp-in-kubernetes","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=627","title":{"rendered":"Seccomp in Kubernetes: What It Is and How to Use It"},"content":{"rendered":"

In this blog, you will learn what Seccomp is and explore practical examples of using custom Seccomp profiles with Kubernetes.<\/p>\n

By the end of this blog, you will know:<\/p>\n

    \n
  1. What is seccomp<\/li>\n
  2. What is a seccomp profile<\/li>\n
  3. How to use seccomp with Docker<\/li>\n
  4. How to use seccomp with Kubernetes pods<\/li>\n<\/ol>\n

    What is Seccomp?<\/h2>\n

    System calls are how user-space programs interact with the Linux kernel.<\/p>\n

    Seccomp (Secure Computing Model) is a security layer in the Linux kernel introduced in 2005 that restricts the system calls<\/strong> a process can make (pre-container era).<\/p>\n

    It may sound similar to Linux capabilities. However, Seccomp is more flexible as it allows filtering individual system calls. (Usually, both are used)<\/p>\n

    It essentially creates a sandbox that limits what actions a program can perform.<\/p>\n

    A common example where Seccomp is used is in container runtimes (e.g., containerd, CRI-O, etc.).<\/p>\n

    For example, Docker<\/a>, by default, applies a Seccomp filter to containers, which blocks a significant number of system calls not necessary for typical container operations.<\/p>\n

    How does Seccomp work?<\/h2>\n

    Seccomp uses Linux\u2019s seccomp-bpf<\/strong> (Berkeley Packet Filter) mechanism that filters syscalls using predefined rules.<\/p>\n

    \n
    \ud83d\udca1<\/div>\n
    BPF : <\/strong><\/b>Originally used for network packet filtering, BPF is now a general-purpose filtering mechanism in the Linux kernel.<\/div>\n<\/div>\n
    \"Seccomp<\/figure>\n
      \n
    1. The container makes syscalls directly to the kernel entry point<\/li>\n
    2. The container runtime translates the seccomp profile JSON into a BPF program<\/li>\n
    3. The runtime attaches this BPF program to the container’s process during container creation<\/li>\n
    4. When the container makes syscalls, they get filtered by the seccomp BPF program<\/li>\n
    5. Allowed syscalls proceed to kernel execution, while blocked ones return an error<\/li>\n<\/ol>\n

      Seccomp Profile<\/h2>\n

      To create a predefined seccomp<\/strong> rule, you need to define a seccomp profile<\/strong> in a JSON file.<\/p>\n

      For example, here is a simple seccomp profile that allows read<\/code>, write<\/code>, and exit<\/code> syscalls but blocks chmod<\/code> syscall with a “Permission denied” error.<\/p>\n

      \"\"<\/figure>\n

      Why Deny Everything by Default?<\/p>\n

      It\u2019s safer to start by denying everything and explicitly allow only what is needed (whitelist approach). This reduces the risk of accidentally letting a dangerous syscall.<\/p>\n

      Seccomp & Contianers<\/h2>\n

      As you all know, the container is basically a sandboxed process, and seccomp plays a key role in that sandboxing.<\/p>\n

      Container runtimes like containerd & crio apply a default seccomp profile that blocks around 40+ system calls (e.g., mount, ptrace, reboot) unless explicitly disabled.<\/p>\n

      Refer to this detailed seccomp profile used by Docker<\/a>.<\/p>\n

      While default profiles provide basic security, you can also apply custom seccomp profiles<\/strong> based on your use case. <\/p>\n

      Let\u2019s see how to do that.<\/p>\n

      The following profile (block-mkdir.json<\/code><\/strong>) blocks the mkdirat<\/strong><\/code> syscall (the syscall used for the mkdir<\/code> command).<\/p>\n

      {\n  \"defaultAction\": \"SCMP_ACT_ALLOW\",\n  \"syscalls\": [\n    {\n      \"names\": [\"mkdirat\"],\n      \"action\": \"SCMP_ACT_ERRNO\"\n    }\n  ]\n}<\/code><\/pre>\n
      If I run a docker container using this seccomp profile, I will not be able to create a directory using the mkdir command. Here is an example<\/p>\n
      $ docker run --rm -it --security-opt seccomp=block-mkdir.json busybox sh\n\n\/ # mkdir test\nmkdir: can't create directory 'test': Operation not permitted<\/code><\/pre>\n
      Kubernetes Pod & Seccomp<\/h2>\n
      Now lets look at how to use Seccomp with Kubernetes.<\/p>\n
      If you want to restrict or apply a specific profile to a container inside a Kubernetes pod, you can do so using securityContext<\/strong>.<\/p>\n
      Kubernetes comes with a RuntimeDefault<\/code><\/strong> profile built into the cluster. It tells Kubernetes to use the default profile provided by the container runtime.<\/p>\n
      For example,<\/p>\n
      \"\"<\/figure>\n
      You can implement custom seccomp profiles<\/strong> as well.<\/p>\n
      For this, the profile should be present on all the worker nodes at the \/var\/lib\/kubelet\/seccomp\/<\/code> location.<\/p>\n
      Kubernetes does not provide any native mechanism to add seccomp profiles to the worker nodes. You need to add them to the nodes manually.<\/p>\n
      For example, I have added the following profile to my worker nodes at \/var\/lib\/kubelet\/seccomp\/block-mkdir.json<\/code>.<\/p>\n
      This profile primarily blocks the mkdir<\/code> syscall, similar to what we tried with Docker.<\/p>\n
      {\n  \"defaultAction\": \"SCMP_ACT_ALLOW\",\n  \"architectures\": [\n    \"SCMP_ARCH_X86_64\"\n  ],\n  \"syscalls\": [\n    {\n      \"names\": [\n        \"mkdir\",\n        \"mkdirat\"\n      ],\n      \"action\": \"SCMP_ACT_KILL\"\n    }\n  ]\n}<\/code><\/pre>\n
      Now, you can implement this seccomp profile in a pod under the securityContext<\/strong> using type: Localhost<\/code> and the profile path as shown below.<\/p>\n
      apiVersion: v1\nkind: Pod\nmetadata:\n  name: custom-seccomp-pod\nspec:\n  securityContext:\n    seccompProfile:\n      type: Localhost\n      localhostProfile: block-mkdir.json\n  containers:\n  - name: busybox\n    image: busybox\n    command: [ \"sh\", \"-c\", \"sleep 3600\" ]<\/code><\/pre>\n
      This configuration applies the custom seccomp profile located at \/var\/lib\/kubelet\/seccomp\/block-mkdir.json<\/code> to the container, blocking the mkdir<\/code> syscall.<\/p>\n
      Now, if you deploy the pod and try to create a directory from within the pod, you will get an error, as shown below.<\/p>\n
      $ k exec -it custom-seccomp-pod -- sh\n\n\/ # mkdir logs\nBad system call (core dumped)\n\/ # <\/code><\/pre>\n
      “Bad system call (core dumped)”<\/strong> error happens because the applied seccomp profile blocks the mkdir<\/code> syscall, preventing directory creation within the pod.<\/p>\n
      Note<\/strong>: You can’t apply a seccomp profile to containers that run in Privileged mode. The Privileged flag essentially disables most security constraints, including seccomp filters.<\/p><\/blockquote>\n
      Conclusion<\/h2>\n
      Seccomp is a powerful security mechanism that helps restrict system calls in Linux-based containers, enhancing security in Docker and Kubernetes. <\/p>\n
      Using default or custom seccomp profiles, you can customize syscall access and reduce security risks. <\/p>\n
      Implementing seccomp effectively requires careful planning, but it significantly strengthens container security. <\/p>\n
      If you have any questions, feel free to leave a comment!<\/p>\n
      Want to Stay Ahead in DevOps & Cloud? Join the Free Newsletter Below.<\/p>\n

      \n