3、k8s容器运行环境安全加固

Linux：系统调用列表.pdf

Linux：系统调用列表.pdf

4.1 最小特权原则（POLP）

最小特权原则 (Principle of least privilege，POLP) ：是一种信息安全概念，即为用户提供执行其工作职责所需的最小权限等级或许可。

最小特权原则被广泛认为是网络安全的最佳实践，也是保护高价值数据和资产的特权访问的基本方式。

最小特权原则 (POLP) 重要性：

• 减少网络攻击面：当今，大多数高级攻击都依赖于利用特权凭证。通过限制超级用户和管理员权限，最小权限执行有助于减少总体网络攻击面。

• 阻止恶意软件的传播： 通过在服务器或者在应用系统上执行最小权限，恶意软件攻击（例如SQL注入攻击）将很难提权来增加访问权限并横向移动破坏其他软件、设备。

• 有助于简化合规性和审核：许多内部政策和法规要求都要求组织对特权帐户实施最小权限原则，以防止对关键业务系统的恶意破坏。最小权限执行可以帮助组织证明对特权活动的完整审核跟踪的合规性。

在团队中实施最小特权原则 (POLP) ：

• 在所有服务器、业务系统中，审核整个环境以查找特权帐户（例如SSH账号、管理后台账号、跳板机账号）；

• 减少不必要的管理员权限，并确保所有用户和工具执行工作时所需的权限；

• 定期更改管理员账号密码；

• 监控管理员账号操作行为，告警通知异常活动。

4.2 AppArmor限制容器对资源访问

AppArmor（Application Armor） 是一个 Linux 内核安全模块，可用于限制主机操作系统上运行的进程的功能。每个进程都可以拥有自己的安全配置文件。安全配置文件用来允许或禁止特定功能，例如网络访问、文件读/写/执行权限等。

Linux发行版内置：Ubuntu、Debian

Apparmor两种工作模式：

• Enforcement（强制模式） ：在这种模式下，配置文件里列出的限制条件都会得到执行，并且对于违反这些限制条 件的程序会进行日志记录。

• Complain（投诉模式）：在这种模式下，配置文件里的限制条件不会得到执行，Apparmor只是对程序的行为进行 记录。一般用于调试。

常用命令：

• apparmor_status：查看AppArmor配置文件的当前状态的

• apparmor_parser：将AppArmor配置文件加载到内核中

- apparmor_parser <profile># 加载到内核中
- apparmor_parser -r <profile># 重新加载配置
- apparmor_parser -R <profile># 删除配置

• aa-complain：将AppArmor配置文件设置为投诉模式，需要安装apparmor-utils软件包

• aa-enforce：将AppArmor配置文件设置为强制模式，需要安装apparmor-utils软件包

K8s使用AppArmor的先决条件：

• K8s版本v1.4+，检查是否支持：kubectl describe node |grep AppArmor

• Linux内核已启用AppArmor，查看 cat /sys/module/apparmor/parameters/enabled

• 容器运行时需要支持AppArmor，目前Docker已支持

实例说明

vi k8s-apparmor-example
#include <tunables/global>
# k8s-apparmor-example-deny-write对应的注解中的名称
profile k8s-apparmor-example-deny-write flags=(attach_disconnected) {
  #include <abstractions/base>
  file,
  # Deny all file writes.
  deny /** w,
}

cd /etc/apparmor.d
# 加载
apparmor_parser k8s-apparmor-example
apparmor_status | grep k8s

vi hello-apparmor-example.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
    # container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
    # <container_name>：容器名称
    # <profile_ref>：对应的apparmor_status查询到的相关规则名称
spec:
  containers:
  - name: hello # 对应上面注解的名称
    image: busybox
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

案例

案例请查看

4.3 Seccomp限制容器进程系统调用

对于 Linux 来说，用户层一切资源相关操作都需要通过系统调用来完成；系统调用实现技术层次上解耦，内核只关心系统调用API的实现，而不必关心谁调用的。

架构图：

Seccomp（Secure computing mode） 是一个 Linux 内核安全模块，可用于应用进程允许使用的系统调用。

容器实际上是宿主机上运行的一个进程，共享宿主机内核，如果所有容器都具有任何系统调用的能力，那么容器如果被入侵，就很轻松绕过容器隔离更改宿主机系统权限或者进入宿主机。

这就可以使用Seccomp机制限制容器系统调用，有效减少攻击面。

Linux发行版内置：CentOS、Ubuntu

大多数容器运行时都提供一组允许或不允许的默认系统调用。通过使用 runtime/default 注释 或将Pod 或容器的安全上下文中的 seccomp 类型设置为 RuntimeDefault，可以轻松地在 Kubernetes 中应用默认值。

Docker默认配置说明：https://docs.docker.com/engine/security/seccomp/

实例说明：（使用nginx镜像测试chmod失败）

mkdir /var/lib/kubelet/seccomp/profiles
vi /var/lib/kubelet/seccomp/profiles/chmod.json
{
    "defaultAction": "SCMP_ACT_ALLOW",
    "syscalls": [
        {
            "names": [
                "chmod"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}

vi  ~/cks/test/seccomp/hello-seccomp.yml 
apiVersion: v1
kind: Pod
metadata:
  name: hello-seccomp
spec:
  nodeName: k8s-node-1
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/chmod.json
  containers:
  - name: test
    image: busybox
    command:
      - sleep
      - 12h

kubectl create -f hello-seccomp.yml

使用nginx镜像测试mkdir

vi  ~/cks/test/seccomp/hello-seccomp-nginx.yml 
apiVersion: v1
kind: Pod
metadata:
  name: hello-seccomp-nginx
spec:
  nodeName: k8s-node-1
  securityContext:
    seccompProfile:
      type: Localhost
      localhostProfile: profiles/chmod.json
  containers:
  - name: web
    image: nginx

{
    "defaultAction": "SCMP_ACT_ALLOW",
    "syscalls": [
        {
            "names": [
                "chmod",
                "mkdir"
            ],
            "action": "SCMP_ACT_ERRNO"
        }
    ]
}