The intention of runtime security is to detect and prevent malicious activities in running containers to ensure the security of containers. This topic describes how to use secure computing (seccomp) to enhance the security of containerized applications.

Use seccomp to prevent containerized applications from making specific syscalls to the kernel of the underlying host operating system

  • Configure a container or a pod to use the default seccomp profile by adding an annotation

    The Linux operating system provides hundreds of syscalls, but most of the syscalls are not required to run containers. To get started with seccomp, use strace to generate a stack trace and check which syscalls your application is making. Then, use a tool such as syscall2seccomp to create a seccomp profile from the data collected from the trace. For more information, see strace and syscall2seccomp.

    Unlike SELinux, seccomp is not designed to isolate containers. However, seccomp can protect the host kernel against unauthorized syscalls. seccomp intercepts syscalls and allows only syscalls that are included in the whitelist. Docker has a default seccomp profile, which is suitable for most general-purpose workloads. For more information, see Default seccomp profile.

    You can configure a container or a pod to use the default seccomp profile by adding the following annotation to the specifications of the container or pod:

    • Versions earlier than Kubernetes 1.19:
      annotations:
        seccomp.security.alpha.kubernetes.io/pod: "runtime/default"
    • Kubernetes 1.19 and later versions:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
  • Create profiles for applications that require additional privileges

    seccomp profiles are provided by Kubelet alpha. If you want to use seccomp profiles, you must add the --seccomp-profile-root flag to the Kubelet arguments.

    AppArmor is similar to seccomp. AppArmor limits the capabilities of a container, including the accessing parts of the file system, to ensure the security of the container runtime. AppArmor can run in enforcement or complain mode. For more information about how to create AppArmor profiles, see bane.

    Apparmor applies only to Ubuntu and Debian distributions of Linux.

    Kubernetes does not provide mechanisms for loading AppArmor or seccomp profiles onto Nodes. You must manually load AppArmor or seccomp profiles or install them onto Nodes when the nodes are bootstrapped. You must perform these operations before your pods are created because the Kubernetes scheduler is unaware of which nodes have profiles.

Suggestions on how to use seccomp

  • Use a third-party solution to maintain seccomp and AppArmor profiles

    Creating and managing seccomp and AppArmor profiles can be difficult if you are not familiar with Linux security. If you cannot maintain seccomp and AppArmor profiles on your own, you can choose to use a commercial solution provided by a third party. These third-party solutions use machine learning to block or alert abnormal activities, which provide better protection than static profiles such as Apparmor and seccomp.

  • Add or remove Linux capabilities before you configure seccomp policies

    Capabilities involve various checks on kernel functions that are reachable through syscalls. In most cases, if a kernel function fails the check, the syscall returns an error. The check can be performed at the beginning of a specific syscall, or in areas of the kernel that may be reachable through different syscalls, such as writing to a specific privileged file. Seccomp is also a syscall filter, which is applied to all syscalls before the syscalls are run. A process can set up a filter, which allows seccomp to revoke the permissions to run specific syscalls or specific arguments for specific syscalls.

    Before you get started with seccomp, you must consider whether you can gain control over applications by adding or removing Linux capabilities. For more information, see Set capabilities for a container.

  • Check whether you can secure container runtimes by using PodSecurityPolicy (PSP)

    PSP provides various methods to improve the security posture of your clusters without increasing complexity. Before you create seccomp and AppArmor profiles, you can check whether the options in pod security policies meet your business requirements.

    PSP is deprecated in Kubernetes 1.21. We recommend the users that use the PSP feature to find an alternative feature before the feature is removed in Kubernetes 1.25. The Kubernetes community is developing a built-in admission controller to replace PSP. ACK will provide policy governance solutions that use the Open Policy Agent (OPA) to replace the PSP feature in later versions.

  • Use Alibaba Cloud Security Center

    You can use Security Center to detect and block threats in runtimes of cloud-native applications. This secures the runtime of each pod. Security Center can automatically obtain information about threats in cloud-native applications and use the information to analyze the threats, identify the sources of the threats, generate suitable responses, and handle the threats. Security Center also associates different types of logs, analyzes contexts, and detects risks in real time, such as malicious code or command execution, SQL injections, and data breaches. This can help prevent intrusions and identify vulnerabilities in your business systems. Security Center can audit actions and identify risks in real time based on Kubernetes logs and operations logs. This helps you mitigate the risks of container escapes, AccessKey breaches, and unauthorized access in ACK and other orchestration platforms. For more information, see What is Security Center?.