Runtime安全

Linux操作系统有几百个系统调用，但其中大部分不是运行容器所必需的。要开始使用Seccomp，请使用Strace生成堆栈跟踪以查看您的应用程序正在进行哪些系统调用，然后使用诸如Syscall2seccomp之类的工具根据从Strace收集的数据创建Seccomp配置文件。更多信息，请参见strace和syscall2seccomp。

与SELinux不同，Seccomp并非旨在将容器彼此隔离，而是保护主机内核免受未经授权的系统调用。工作原理是拦截系统调用并只对列入白名单的系统调用放行。Docker有一个默认的Seccomp配置文件，适用于大多数通用工作负载。更多信息，请参见默认的seccomp配置文件。

您可以通过向容器或PodSpec添加以下注释来配置容器或Pod以使用此配置文件。

• Kubernetes 1.19之前版本：

  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

• Kubernetes 1.19及之后版本：

  securityContext:
    seccompProfile:
      type: RuntimeDefault

Seccomp配置文件是Kubelet Alpha功能。您需要将--seccomp-profile-root标志添加到Kubelet启动参数中才能使用此功能。

AppArmor和Seccomp类似，只是通过限制了包括访问部分文件系统的容器的Capabilities来达到防护容器运行时安全的目的。可以在强制或告警模式下运行。关于构建AppArmor配置文件，请参见bane。

Apparmor仅适用于Ubuntu/Debian发行版的Linux系统。

Kubernetes目前不提供将AppArmor或Seccomp配置文件自动加载到节点上的功能，需要手动加载或者在安装系统引导程序时安装到节点上。这些操作必须在创建Pod之前完成，因为K8s调度器不知道哪些节点具有这些配置。

如果您对Linux安全不熟悉，那么创建和管理Seccomp和Apparmor配置文件将会很困难。如果您没有资源自行维护这些配置文件，请考虑使用商业解决方案。这些三方的解决方案中有许多比Apparmor和Seccomp等静态配置防护更加优越，已经开始使用机器学习来对异常活动进行阻断或告警。

Capabilities涉及对系统调用可访问的内核函数的各种检查。如果检查失败，系统调用通常会返回错误。检查可以在特定系统调用开始时进行，也可以在内核中多个不同系统调用（例如写入特定特权文件）可访问的区域中进行。另一方面，Seccomp是一个系统调用过滤器，在运行之前应用于所有系统调用。一个进程可以设置一个过滤器，这允许Seccomp撤销运行某些系统调用或某些系统调用的特定参数的权限。

在使用Seccomp之前，请考虑添加/删除Linux capabilities是否能正确控制应用程序的行为。更多信息，请参见Set capabilities for a Container。

Pod安全策略提供了许多不同的方式来改善集群的安全状况，而不会引入过多的复杂性。在尝试构建Seccomp和Apparmor配置文件之前，请先探索PSP中的配置项是否能满足需求。

PSP在Kubernetes1.21版本中被设置为Deprecated状态，在使用中的用户可以在1.25版本前有一个替换的缓冲期。社区正在计划通过新的内置准入控制器方案来取代PSP，ACK容器服务也将通过基于OPA的策略治理方案逐步替换正在使用的PSP。

在云原生应用运行阶段，可实现基于云安全中心的应用运行时威胁检测与阻断，实时保障每个应用Pod的安全运行。云安全中心基于云原生的部署能力，实现威胁的数据自动化采集、识别、分析、响应、处置和统一的安全管控。利用多日志关联和上下文分析方案，实时检测命令执行、代码执行、SQL注入、数据泄露等风险，覆盖业务漏洞入侵场景。结合K8s日志和云平台操作日志实时进行行为审计和风险识别，实现容器服务和编排平台存在的容器逃逸、AccessKey泄露、未授权访问风险。更多信息，请参见什么是云安全中心。